I came across a bot detection benchmark on Discord a few days ago.
Proof of Human compared its product against reCAPTCHA, hCaptcha, Cloudflare Turnstile, and Cloudflare Bot Management. After running the experiment, they reached a reassuring conclusion: Proof of Human is much better than everyone else.
Their detector caught 99% of the tested bots.
To be fair, this is far from the first questionable benchmark published by an anti-bot vendor. There are plenty of them in the industry. Proof of Human is just going to take the hit for the others today.
Commenting on a benchmark that includes your own company is always a bit awkward. If the result isn't flattering, any criticism immediately sounds defensive.
In this case, Castle isn't even part of the comparison, which is actually convenient. I've wanted to write for a while about how anti-bot benchmarks can be misleading, and this gives me a good example to use without having to argue about Castle's own position in the chart.
It's also a useful example of how easy it is to build an artificial bot detection benchmark, obtain an impressive number, and then mention most of the reasons why that number should be treated carefully in the limitations section. Listing the limitations is obviously better than hiding them, but it doesn't magically fix the methodology.
More importantly, it raises a broader question: what does a benchmark like this actually measure, what does it miss, and what should companies really look at when evaluating an anti-bot product?
What exactly are we benchmarking?
Proof of Human created a five-question survey combining multiple-choice questions with open-ended responses. Five AI agents attempted the survey 20 times each, resulting in up to 100 automated sessions per detection system.
This isn't purely a browser fingerprinting test. The agents actually interact with the page, so depending on the product, the decision can include browser and device fingerprints, network information, mouse movements, clicks, scrolling, typing patterns, timing, and other client-side interactions.
So far, fair enough.
The first problem is what isn't in the experiment: there are no humans.
99% detection is easier when there are no humans
The benchmark measures how many automated sessions are detected, but it doesn't measure how many legitimate sessions would also be detected.
If false positives don't matter, I can build an anti-bot with an excellent detection rate:
if (request) {
return BOT;
}
100% detection. Hard to beat.
Obviously, nobody would deploy this exact rule. But less absurd versions of the same problem exist in real detection systems. You can aggressively flag uncommon hardware, VMs, unusual browser properties, strange mouse movements, rare WebGL configurations, or minor inconsistencies between signals.
If the benchmark only contains bots, being more aggressive can only help your score.
The difficulty starts when the same detection runs on real traffic. At scale, legitimate users are weird. They use old laptops, rare GPUs, corporate environments, accessibility tools, remote desktops, virtual machines, browser extensions, and configurations nobody on your research team thought existed. Their interactions can also look strange.
A good anti-bot doesn't only need to identify unusual sessions. It needs to separate automation from the very long tail of unusual legitimate users.
Proof of Human acknowledges this in the limitations:
"We measured detection rates for automated sessions but did not evaluate false-positive rates among human respondents."
That's a fairly important limitation in a benchmark whose main output is a detection percentage.
It also affects how much we can learn about their behavioral detection results. Some behavioral anomalies can be detected in absolute terms. If a mouse trajectory or typing pattern is completely unrealistic, you may not need much historical traffic to decide that something looks suspicious.
But a lot of useful behavioral detection is relative. You learn what normal behavior looks like for a specific page, endpoint, or population, and then detect sessions that deviate from that distribution.
Completing a form in seven seconds isn't necessarily suspicious. If most legitimate users take between 30 seconds and three minutes, while thousands of sessions from one population consistently complete it in seven seconds, then it becomes much more interesting.
That second type of detection needs traffic. A fresh survey with almost no legitimate traffic mostly removes this baseline. Products can still detect obvious behavioral anomalies, but they don't have much site-specific behavior to compare against.
Bot detection is a context problem
The same problem appears when we move from detecting one automated session to detecting an actual attack.
Being able to look at one request, fingerprint, or interaction sequence and confidently classify it as automated is valuable. And to be fair, if you could perfectly detect every bot independently, request by request, you would also stop distributed attacks.
Unfortunately, attackers spend a lot of effort making sure you can't do that.
Once the obvious version of an attack gets detected, they rotate residential proxies, randomize fingerprints, change browser configurations, modify behavior, spread traffic over time, and distribute activity across many devices or identities. The objective is precisely to make every individual session look less suspicious.
This is why anti-bot systems also have approaches designed to detect attacks across sessions. Maybe every residential IP looks legitimate independently, but 20,000 of them participate in the same account-creation pattern. Maybe every fingerprint is different, but the randomization introduces correlations. Maybe individual login attempts look normal, while the aggregate account-targeting pattern clearly looks like credential stuffing.
Context across time matters too. A system may build reputation around devices, networks, accounts, or previous sessions. Application context matters as well: a suspicious request on a public page isn't the same thing as a suspicious signup, login, password reset, or checkout.
None of this is really exercised by asking an AI agent to complete the same five-question survey 20 times.
The benchmark also acknowledges that they tested the product tiers available to them rather than necessarily the products customers deploy for serious bot protection:
"We evaluated the product tiers available to us rather than enterprise versions, which may incorporate additional signals or more advanced detection capabilities."
They also note that some systems may improve after observing more traffic.
Again, these are not small implementation details when the final result is presented as a ranking of anti-bot vendors.
At this point, we're already quite far from "which anti-bot product is best?"
What the benchmark really tells us is how some publicly accessible configurations reacted to a small number of isolated automated sessions on a new website with almost no historical traffic.
That's a valid experiment. It's just a much narrower conclusion than "we detect 99% of bots."
Did you detect the AI agent, or just a weird browser?
There is another question I would ask before reading too much into the AI-agent results: what exactly caused those agents to be classified as automated?
Imagine an AI browser runs inside a Linux VM, claims to be Windows, generates synthetic mouse movements, and gets classified as a bot.
Did the system detect the AI agent? Maybe.
But perhaps the WebGL renderer didn't match the claimed operating system. Maybe the VM exposed unusual hardware properties. Maybe several sessions had closely related fingerprints. Maybe the generated interactions looked artificial.
Those are all perfectly valid detection signals, but they don't support the same conclusion.
I had a quick look at Proof of Human's public client-side JavaScript. The client appears to collect fairly standard categories of browser and behavioral telemetry: hardware concurrency, device memory, WebGL information, canvas fingerprinting, browser properties, mouse movements, clicks, typing, scrolling, and similar signals.
I didn't see an obvious magical "this is Comet" or "this is Grok" signal.
So at least for some of these results, I would be careful about saying the system detected a particular AI agent. It may simply have detected something unusual about the environment in which that agent was running.
That's still useful detection. But the distinction matters, particularly now that "AI agent detection" is becoming a convenient marketing category.
Attackers don't have to play along
There is a bigger issue with the threat model.
The benchmark tests automated browsers that politely load the anti-bot JavaScript, expose their environment, send the expected telemetry, interact with the survey, and then wait to see whether they were detected.
Real attackers don't have to keep playing that game.
When I looked at Proof of Human's client, the JavaScript wasn't obfuscated. You can open it and fairly quickly understand what categories of information are being collected.
The fingerprinting payload is also sent in plaintext, so it's easy to inspect what the browser reports.
If I'm attacking this system, my first thought probably isn't "how do I make Playwright move the mouse more naturally?"
My first thought is: why am I running Playwright at all?
I can browse the website normally, collect valid reference payloads, understand which fields remain stable and which ones change, and start reproducing the protocol while modifying only what I need. At some point, I may not need an automated browser anymore. Sending requests directly is cheaper and much easier to scale.
To be clear, I'm not claiming that this is enough to bypass Proof of Human. I haven't tried, and there may be important server-side logic that isn't visible from the client.
The point is that benchmarking a collection of automated browsers can miss the bigger threat model.
Your adversary isn't Playwright, Comet, Grok, or whichever framework becomes popular next month. It's an attacker trying to get requests through your system as cheaply and reliably as possible.
If running a real browser becomes expensive, they will look for another path. That can mean forging the fingerprinting payload, replaying valid telemetry, calling the backend directly, finding an endpoint where the anti-bot isn't properly enforced, or reverse engineering enough of the protocol to reproduce it without the original client.
Obfuscation isn't a security boundary. Any JavaScript running on the attacker's machine can eventually be understood. But there is still a significant difference between "a motivated attacker can reverse engineer this" and giving them readable collection code and an immediately understandable payload format.
Good obfuscation, dynamic protocols, integrity mechanisms, and anti-replay protections don't make attacks impossible. They make building and maintaining a bypass more expensive.
In an adversarial system, that matters.
Before the cognitive AI, check the basics
Proof of Human concludes:
"Our results suggest that bot detection is entering a new phase."
I actually agree.
AI agents, better browser automation, residential proxies, and increasingly realistic anti-detect setups are changing the landscape.
But before getting too excited about "cognitive detection", "AI-powered behavioral intelligence", "agentic threats", "AI-native detection", or whatever term becomes fashionable next, I would check that the basic engineering is there.
Can an attacker easily understand the client-side collection? Can they forge or replay the telemetry? Can the system identify a distributed campaign even when individual sessions look normal? Does it understand account and application context? Can it adapt once attackers start reverse engineering it? And can it do all of this while maintaining an acceptable false-positive rate?
The same applies to another favorite anti-bot marketing metric: the number of signals collected.
One vendor collects 200 signals. Another collects 500. Eventually someone claims thousands.
But what exactly counts as one signal? If I record 500 mouse coordinates, did I collect 500 signals?
Signal quantity and diversity matter, but what matters more is what you do with them. A WebGL renderer, IP address, browser version, and mouse trajectory can all be useful. Their relationships are often more interesting: does the GPU make sense for the claimed OS? Has this device been associated with the account before? Are hundreds of residential proxies participating in the same attack? Is one device failing MFA against many unrelated accounts?
Machine learning doesn't remove this requirement either.
ML is useful for bot and fraud detection, but if your training bots happen to run mostly in Linux VMs while your legitimate population doesn't, your model can become very good at detecting Linux VMs.
It may score extremely well on another synthetic bot-only benchmark. Then you put it on a website used by developers.
Good telemetry, useful labels, context, multiple detection approaches, and continuous research still matter. Putting "AI" in front of the model doesn't change that.
What to evaluate instead
Unfortunately, I don't think there is one perfect benchmark for bot detection. Even establishing ground truth is difficult in fraud.
If you knew exactly which production requests were bots and which ones were humans, you would already have solved a large part of the problem.
For a company evaluating a vendor, I would start with something much less exciting than a leaderboard: deploy the product on your real traffic in monitoring or labeling mode.
See what it catches. Investigate the sessions it considers suspicious. If you already use another anti-bot or fraud system, compare the results. Where do they overlap? More importantly, where do they disagree?
Then look closely at false positives. Does the product overreact to particular browsers, countries, networks, devices, or uncommon environments? Does the detection still make sense once exposed to the long tail of your real legitimate traffic?
After that, attack it. Don't only launch default Playwright instances. Rotate proxies, randomize fingerprints, change behavior, spread the traffic over time, and distribute the attack. See whether the system can still understand the campaign once each individual session becomes cleaner.
Then assume the attacker knows how the product works. Inspect the JavaScript, study the protocol, try to replay telemetry, forge signals, call APIs directly, and find less protected paths.
Application context is another thing I would evaluate carefully. If you're protecting login, does the system know which account is targeted and whether authentication succeeded? Can it use MFA results, account history, or known devices? Can you apply different detection policies to signup, login, password reset, and checkout?
Finally, look at how usable the system is when the attack changes. You want enough explainability to understand what you're seeing, enough control to tune the response for different use cases, and the ability to ship detection changes quickly without turning every adjustment into a support ticket. Performance, latency, client-side overhead, and failure modes also matter.
There is no silver bullet here, and there is definitely no single percentage that captures all of this.
Benchmark what you actually care about
Synthetic benchmarks aren't inherently bad.
If the conclusion of this experiment were:
"Here is how the publicly accessible versions of these products reacted to 100 sessions from five AI agents on a new survey website."
I wouldn't have much to complain about.
That's what they tested.
The problem is using that experiment to support the much broader conclusion that one product detects 99% of bots and performs better than everyone else.
Bot detection is an adversarial problem. It involves false positives, historical context, application-specific signals, distributed attacks, reverse engineering, changing infrastructure, and attackers who actively modify their approach once they understand why they're being detected.
Measuring all of that is considerably harder than running 100 survey sessions.
Unfortunately, it also makes for a much worse bar chart.
