What bot detection is
Bot detection is the set of techniques used to tell automated traffic apart from human traffic. It has a long history in web security: stopping credential stuffing, scraping, fake signups, inventory hoarding and spam, all of which appear in the OWASP Automated Threats to Web Applications taxonomy. Typical inputs include IP reputation, request rates, header and protocol fingerprints, browser environment checks and interaction signals. Typical outputs are a score or a verdict, often wired directly to block, challenge or allow.
Why it was built that way
Classic bot detection grew up around one assumption: automated traffic is mostly adversarial, and the job is to keep it out. That assumption made a single bot score, enforced at the edge, a reasonable design. If a request looks automated, challenge it with a CAPTCHA or block it.
Why that model is no longer enough
Applications now receive a much wider mix of actors:
- people browsing normally,
- people working with AI assistants that read, draft or fill in on their behalf,
- legitimate agents and crawlers that identify themselves, sometimes with signed requests,
- autonomous agents completing tasks for users,
- unknown clients whose nature the evidence cannot establish.
A binary bot score does not describe this well. Our post Human, AI-assisted or agent: a practical taxonomy for application traffic sets out the alternative. Blocking every automated request turns away legitimate participants; allowing them all removes useful control. And a confident verdict on thin evidence produces false positives that land on real users.
How actor intelligence differs
Actor intelligence asks a broader question: what kind of actor is present, and what does the evidence actually show? It differs from classic bot detection in three ways:
- Richer categories. Human, Human + AI, Agent and Unknown, instead of human versus bot.
- Explicit basis. Each result says whether it rests on verified, declared or inferred evidence, or none, so a cryptographic check is never confused with a behavioral guess.
- Separate decisions. The result informs your application's policy rather than enforcing one by default. Teams observe first, then decide per route.
The two approaches can coexist. Major crawler operators already support checks beyond the user-agent string, such as Google's crawler verification by reverse DNS and IP range, and signed requests extend that idea to any operator. For signals you can use today, see how to tell if website traffic comes from AI agents. Abuse controls at the edge remain valuable; actor intelligence gives the application itself the context to design the right experience for each kind of interaction.
Common misconceptions
- "Agents are just bots." Some are abusive; many are legitimate users of your product acting on someone's behalf.
- "A bot score is a fact." It is an inference with error rates. Treat it as evidence with a confidence level, not a verdict.
- "Unknown means block." Unknown means the evidence is insufficient. What happens next should be an explicit, per-route choice (see fail open vs fail closed).
How Proof of Actor fits
Proof of Actor is actor intelligence for apps, websites, APIs and MCP servers. Detect gathers signals and separates verified assertions from inferences; Understand shows interaction types, trends and evidence; Route lets your own policies allow, adapt, challenge, review or limit specific interactions. Nothing is blocked by default.
Explore the product or apply for early access.
Sources
- OWASP Automated Threats to Web Applications: taxonomy of automated threats such as credential stuffing, scraping and account creation
- Google: Verifying Google's crawlers and fetchers: operator-published crawler verification