The default detectors — Inconsistent hardware readings for device, known CAPTCHA-solver services, Synthetic interaction timings, HTTP header fingerprint mismatches and dozens of others — catch the bulk of bots automatically, without any configuration. Access Rules are the customer-authored layer on top: policy that reflects a specific pattern your team has observed on your own traffic, or a business decision (stricter checks for a high-risk region, whitelist for a partner IP range, block for a specific ASN pattern).
Access Control — the Customer-Authored Layer
Access Control is the customer-authored rules layer of the Prosopo platform. Prosopo's named-detector library — the layer that catches Inconsistent hardware readings for device, known CAPTCHA-solver services, Synthetic interaction timings and dozens of other patterns automatically — stops the bulk of bots by default. Access Rules are what you add on top when the defaults don't yet cover a specific pattern your team has spotted. Block a specific ASN pattern, challenge visitors from a high-risk country, whitelist a partner IP range on your API. Rules match on IP, ASN, country, User-Agent, JA4 TLS fingerprint, header hashes and more; they take effect the moment they're saved.
How Access Rules fit the three-layer stack
Named detectors do the heavy lifting. Access Rules layer on top for policy the defaults don't yet cover. In Protect, ML intent scoring adds a third layer for the human / agent / bot boundary.
- 01
Layer 1: named-detector library (default)
The Prosopo detector library catches the bulk of bots on pattern-match — behavioural, device, TLS and network signals — and returns a readable reason on every block. Most of the bot-stopping happens here.
- 02
Layer 2: your Access Rules (this page)
Layer your own rules on top when the default detectors don't yet cover a specific pattern. Block, restrict, or step up to a puzzle / image / PoW challenge — globally, per site or per group.
- 03
Layer 3: ML intent scoring (Protect only)
In Prosopo Protect, an ML model scores request intent across the human / agent / bot boundary — the layer that decides whether an agentic browser is acting on behalf of a real customer or automating abuse.
Why teams use the customer-authored layer
Same explanation surface as the default detectors
When an Access Rule matches, the block cites the specific rule that fired — sitting alongside the plain-language reasons from the default library. Named block reasons throughout, not black-box scores, regardless of whether the trigger came from a default detector or a rule you added.
Match on the signals bots can't spoof cleanly
Rules match on IP, IP CIDR, ASN, country, User-Agent, device, JA4 TLS fingerprint, header hashes and more — mix and match in a single rule for surgical policy.
Rule changes are HTTP calls, not vendor tickets
Author, edit and delete rules from the portal or the API. Rules take effect the moment they're saved — no re-deploy, no SOC ticket to a vendor. Kasada, Arkose and DataDome all keep this workflow inside their own managed service.
Built-in expiry for incident response
Every rule carries an expiry. Drop in a short-lived rule during an active attack and it lapses on its own once the wave is over — no cleanup, no risk of forgotten overrides.
GDPR-native by construction
Human-authored rules produce blocks that are traceable to a specific named rule — a defensible answer to GDPR Article 22 (right not to be subject to solely automated decision-making) and EU AI Act Article 14 (meaningful human oversight).
How Prosopo Access Control works
An access rule combines one or more conditions with a policy. When a verification request matches every condition in a rule, the policy is applied instead of your site's default challenge. Rules are evaluated by specificity — a more precisely targeted rule always wins over a broader one — so you can layer broad defaults with surgical overrides.
Each rule has an expiry, so Access Control works just as well for short, sharp responses to live attacks as it does for long-running policy.
What you can match on
Conditions describe who the rule applies to. You can mix and match any of the fields below in a single rule.
| Field | What it matches | Example use |
|---|---|---|
| IP address | A single IPv4 address | Block a specific abuser |
| IP range (CIDR) | A subnet such as 192.168.1.0/24 | Restrict a VPN gateway or corporate network |
| ASN | An Autonomous System Number, i.e. a hosting provider, ISP or VPN network | Throttle traffic from a noisy cloud host without listing every IP it owns |
| Country | Standard two-letter country code | Apply tighter rules to regions seeing high abuse |
| User Agent | The browser or client string sent by the request | Block headless browsers and scripted clients |
| JA4 fingerprint | A TLS-level fingerprint of the client | Catch automation tooling that varies its User Agent but not its TLS stack |
| User ID | An identifier you pass through your integration | Apply per-user policies for known accounts |
What you can do when a rule matches
When a rule matches, you choose how to respond:
- Block — fail the verification outright. Use this for known-bad sources.
- Require an image or puzzle challenge — present an image or puzzle CAPTCHA with a configurable number of rounds. Useful for suspicious-but-not-confirmed traffic.
- Require Proof of Work — issue a computational challenge at a difficulty you choose. Slows automation down without asking the user to click anything.
Built for incident response and long-term policy
Because every rule carries an expiry, Access Control fits two very different jobs:
- Live incident response. When an attack starts, drop in a short-lived rule (minutes or hours) targeting the offending IP range, ASN or fingerprint. The rule lapses on its own once the wave is over — no cleanup, no risk of forgotten overrides.
- Standing policy. Long-running rules let you encode business decisions: stricter checks for high-risk regions, custom challenges for partner networks, allow-by-default for trusted user IDs.
How Prosopo Access Control compares
Full capability Partial / caveat Not available
| Capability | Prosopo Access Control | Traditional WAF rules | reCAPTCHA / hCaptcha |
|---|---|---|---|
| Block by ASN / hosting network | ● | ● Limited | ● |
| Block by TLS (JA4) fingerprint | ● | ● Rarely | ● |
| Per-rule custom challenge (image, puzzle, PoW difficulty) | ● | ● | ● |
| Rule expiry built in | ● | ● Manual cleanup | N/A |
| GDPR-compliant data handling | ● | ● Varies | ● |
| No DNS changes required | ● | ● DNS-routed | ● |
Common use cases
- Stop credential stuffing — block ASNs and TLS fingerprints associated with breached-credential replay.
- Prevent ticket scalping — throttle datacenter traffic during high-demand drops.
- Defend against scraping — escalate bot-like fingerprints to image or puzzle challenges.
- Stop account takeover — apply stricter challenges to traffic from high-risk regions.
Configuration reference
Detailed field formats, policy options and rule-matching behaviour are documented in the Access Control Rules reference.
See what's reaching your site
A Bot Exposure Assessment is a 30-minute call with an engineer. We look at your traffic, show where your current setup leaves gaps, and agree how a trial would be judged. Nothing to install first.
Questions
Something else? Ask an engineer.
How do Access Rules relate to Prosopo's default detectors?
What can I match on?
IP address, IP CIDR range, ASN, country, User-Agent, JA4 TLS fingerprint, header hashes, User ID. Mix and match any of these in a single rule.
Can I customize the Access Rules?
Yes. Authoring, editing and deleting rules is available through the portal or the API. Rule changes are HTTP calls — they take effect the moment they're saved, no re-deploy needed.
More from Prosopo
- Accessible CAPTCHA: verification that does not lock people out An accessible CAPTCHA alternative. Invisible for most users, proof of work rather than an image challenge as the first escalation, image challenges disableable per site, keyboard and screen reader support.
- Enterprise Bot Protection — the Prosopo Platform Enterprise bot protection from Prosopo. A widget for your forms (Procaptcha), or protection at the edge that learns your site's normal traffic (Prosopo Protect), with one dashboard for both. Every block comes with a reason, in plain words, rather than a black-box score.
- Invisible CAPTCHA Prosopo's Invisible CAPTCHA is the invisible-first mode of Procaptcha — real users see nothing, and every block on a suspected bot comes with a reason you can read.
- Procaptcha: the GDPR-compliant CAPTCHA widget Procaptcha is Prosopo's CAPTCHA widget — a drop-in reCAPTCHA and hCaptcha replacement, cookieless by default, GDPR-compliant, free for the first 10,000 requests a month.
- Prosopo Protect — Site-Wide and API Bot Protection Site-wide, API and form bot protection from Prosopo, sold as the Enterprise and Custom plans. Add it as a script tag on your forms, an edge worker (Cloudflare Workers or AWS Lambda@Edge), or both. Access Rules on every request, allow/block/challenge verdicts, branded interstitials on HTML pages, clean HTTP status + header on JSON APIs.
- Residential proxy detection How Prosopo detects residential proxies: TCP connection checks against the claimed device, live IP intelligence and a proxy exit-IP catalogue we build ourselves, with a readable reason on every block. Available from the Professional plan.