The default detectors — Apple hardware spoofing, known CAPTCHA-solver services, synthetic mouse-event 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 Apple hardware spoofing, known CAPTCHA-solver services, synthetic mouse-event 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, gate a country on a checkout endpoint, 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.
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 technical detector name on every block. This is where most of the bot-stopping actually happens.
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 — per site, per group, per endpoint.
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 Prosopo
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 named-detector output 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, which makes Access Control just as useful for short, sharp responses to live attacks as it is 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.
Request a Demo of Prosopo Access Control
Access Control is part of our Enterprise product. Please contact our sales team who will be happy to provide you with a quote.
By the numbers
Trusted by companies of all sizes.
Active websites
0+
Monthly verifications
0+
Bots stopped per month
0+
Reviews
Our customers love us.
Hundreds of businesses have made the switch from reCAPTCHA and hCaptcha to Prosopo. Here's what they have to say.
Frequently Asked Questions
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
What else can Prosopo protect for you?
No matter the threat, we have a solution to keep your business safe.
Product
Access Control — the Customer-Authored Layer
Access Control is the customer-authored rules layer of the Prosopo platform — layered on top of the named-detector library that catches the bulk of bots by default.
Learn moreProduct
Enterprise Bot Protection — the Prosopo Platform
Enterprise bot protection from Prosopo. One detection engine, delivered as a widget (Procaptcha) or at the edge (Prosopo Protect), same dashboard for both. Every block names the specific detector that caught it — not a black-box score.
Learn moreProduct
Invisible CAPTCHA
Prosopo's Invisible CAPTCHA is the invisible-first mode of Procaptcha — real users see nothing, and every block on a suspected bot names the detector that caught it.
Learn more
Product
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 verifications per month.
Learn more
Product
Prosopo Protect — Site-Wide and API Bot Protection
Site-wide and API bot protection from Prosopo — deploy at the edge (Cloudflare Workers, AWS Lambda@Edge) or as a server-side integration (nginx, Caddy, custom reverse proxies). Access Rules on every request, allow/block/challenge verdicts, branded interstitials on HTML pages, clean HTTP status + header on JSON APIs.
Learn moreProduct
Residential proxy detection
How Prosopo detects residential proxies — TCP fingerprint interrogation, IP intelligence, and a self-maintained proxy-vendor catalogue. Available on the Enterprise plan.
Learn moreProduct
Spam Filter: Add-on for Procaptcha and Prosopo Protect
Spam Filter is a Procaptcha add-on that blocks fake signups, throwaway emails and abusive-network traffic during each verification — without you writing any extra integration code.
Learn more