The challenge ladder — proof-of-work, then CAPTCHA, then verified-bot auth
Block and allow are too blunt for most traffic
A lot of traffic is not obviously good or obviously bad. It is suspicious — an unfamiliar automation fingerprint, a request pattern that is a little too regular, a client with a middling behavioral score. If you block it, you will sometimes block a real customer behind a corporate proxy or a privacy browser, and you will get the support ticket. If you allow it, you let through the scraper and the credential-stuffing bot you were worried about. Neither choice is right, because both treat a spectrum of confidence as a binary.
The answer is not a smarter yes/no. It is a graduated middle: make a doubtful client prove itself, with the cost of the proof scaled to how suspicious it is. That is the challenge ladder.
Rung one: proof-of-work
The lightest rung asks the client’s browser to solve a small computational puzzle before the request is answered. For a real browser loading a page once, this is invisible — a few milliseconds of math the user never notices. For an attacker trying to make thousands of requests, that same tiny cost multiplies into something that wrecks the economics of the attack. Proof-of-work is the cheapest possible friction: no third party, no image to squint at, no user interaction at all. It filters out the high-volume, low-sophistication automation that makes up the bulk of bad traffic.
Crucially, the puzzle is signed by the edge, so an attacker cannot pre-compute or replay a solution — each challenge is bound to its request.
Rung two: CAPTCHA
Some automation is willing to pay the compute cost. When a client clears proof-of-work but still looks wrong — the behavior score stays high, the pattern persists — the ladder escalates to a CAPTCHA. This is the rung that specifically separates human from headless: a person clears it in a couple of seconds, a scripted bot generally cannot. It is more friction than proof-of-work, which is exactly why it is the second rung and not the first. You only spend a user’s patience when the cheaper check was not enough. We support the mainstream providers, so the CAPTCHA is a familiar one, not a home-grown puzzle.
Rung three: verified-bot auth
Not every automated client is unwelcome. Search crawlers, AI indexers you actually want, and partner integrations are bots you would like to allow — but only if they are genuinely who they claim to be. The top rung, Web Bot Auth, verifies a cryptographic HTTP message signature the client attaches. A crawler that signs correctly against its published key is provably legitimate and passes; one wearing the name without the signature does not. This is what lets you allow good crawlers and block impostors without trusting a spoofable user-agent string.
The ladder is driven by confidence, not by luck
What decides which rung a client meets is not random and it is not a single crude signal. An ML entity score, built from a client’s behavior across its request history, places it on the ladder — and the same machinery drives rate limiting and false-positive tuning. Low suspicion, no challenge. Some doubt, proof-of-work. Persistent doubt, CAPTCHA. Confirmed malice at volume is dropped outright, below the WAF, at the kernel. The ladder means the response is always proportionate to the evidence.
What we don’t claim
No challenge is unbeatable. A determined adversary can pay humans to solve CAPTCHAs and can afford the compute for proof-of-work — we know that, and we design the ladder to make attacks uneconomical, not impossible. The honest goal is to raise the cost of abuse far above its payoff while keeping the cost to real users at or near zero. Every rung runs inline within our ≤5 ms design budget for the traffic that passes cleanly.
Set it up for your traffic
The right rung thresholds depend on who visits you and what you are protecting. Tell us your domain and we will tune the ladder with you, or read how it works first.