CAPTCHAs cannot solve the AI agent problem because they answer the wrong question. A CAPTCHA asks whether a visitor can complete a challenge that appears human, usually once, at the start of a session. The AI agent problem asks something broader: who or what is acting throughout a meaningful interaction, whether a human is in control, whether AI is involved, and, if an agent is acting, who authorised it and what it is allowed to do. No single challenge, however well designed, can establish all of that.
This is not an argument that CAPTCHAs are useless or that bot management is obsolete. Both remain important for reducing unwanted automation at scale. The argument is that the internet now contains actors that challenges were never designed to classify: humans assisted by AI, and AI agents acting legitimately on someone's behalf. Searching for a better CAPTCHA alternative is a reasonable instinct. It is also, on its own, an incomplete one.
What a CAPTCHA was designed to do
CAPTCHA stands for "Completely Automated Public Turing test to tell Computers and Humans Apart". The design goal is in the name: present a task that humans find easy and automated programs find hard, then admit visitors who succeed.
That model worked because of two assumptions:
- Automation was the adversary. Any visitor that was not a human was assumed to be unwanted: scrapers, spammers, credential-stuffing tools.
- Passing once was enough. If a human passed the challenge, the session that followed was assumed to be that human's.
For years, these assumptions were reasonable approximations. Both are now weakening.
What a service actually needs to know
Consider the questions a modern service increasingly has to answer when someone or something interacts with it:
- Is a real human here?
- Is that human actually present during this interaction, not just at login?
- Is the same actor continuing throughout the session?
- Is that human controlling what happens?
- Is AI materially participating?
- If an AI agent is acting, who authorised it?
- What is it allowed to do, and is this action inside that authority?
- For a consequential action, did a human explicitly intend it?
Now compare what each mechanism addresses:
| Question | CAPTCHA | Bot management | What is actually needed |
|---|---|---|---|
| Does this visitor appear human at a point in time? | Yes | Often | Personhood and presence evidence |
| Is a human present throughout the interaction? | No | Partially | Continuous presence |
| Is it the same actor from start to finish? | No | Partially | Actor continuity |
| Is the human controlling the interaction? | No | No | Human control evidence |
| Is AI materially involved? | No | Not designed for this | AI participation signal |
| Who authorised this agent, and for what? | No | Identifies some known agents | Delegation and scope of authority |
| Is this action inside the agent's mandate? | No | No | Action-level authorisation |
| Did a human intend this specific action? | No | No | Explicit intent |
A CAPTCHA addresses the first row. Bot management addresses more, particularly at the traffic level. The remaining rows describe a different layer of trust altogether.
Why one challenge at session start cannot establish trust
It is a snapshot, not a record
A challenge establishes something about one moment. Everything that happens afterwards inherits that result. But a human can pass a challenge and then hand the session to an AI agent, a remote operator or another person. The challenge result remains "human" while the actor has changed. This is the same gap we describe in Authentication Is No Longer Enough: passing a gate does not tell you who walks through the rest of the building.
It cannot see control
A human who is present is not necessarily the one directing the interaction. A person can solve a challenge and then let an AI system fill in an application, answer an assessment or approve a transaction. The challenge says nothing about who was in control afterwards. That is the domain of Proof of Control, and we set out the concept in What Is Human Control Verification?.
It cannot see AI involvement
AI assistance is now part of ordinary work. Much of it is fine. But some contexts, such as a hiring assessment, need to know whether the human performed the task or whether AI materially did it. A challenge that admits a human at the start cannot distinguish a human working alone from a human relaying AI output.
It cannot carry authority
Most importantly for agents, a challenge has no concept of delegation. It cannot express "this is an AI agent acting for a verified person, authorised to spend up to 500 dollars". It can only ask the agent to look human. That leads directly to the next problem.
Legitimate agents should not have to pretend to be human
When the only way through a door is to appear human, every legitimate agent is pushed toward imitation. An agent booking a restaurant for its user, comparing insurance quotes or completing a purchase it was explicitly asked to make faces a choice: be blocked, or behave like a human.
That outcome is bad for everyone:
- Services lose visibility. Agents that succeed in imitating humans become indistinguishable from humans, which makes agency invisible rather than accountable.
- Users lose useful tools. People who delegate tasks to agents find those agents arbitrarily blocked.
- Agent builders face the wrong incentive. Investment flows toward appearing human rather than toward proving legitimacy.
- Challenges get harder for humans. As automated systems get better at solving challenges, the challenges tend to become more demanding, which adds friction and can create accessibility barriers.
The better model is for legitimate agents to declare themselves and prove their authority, so services can decide how to treat them. As we put it at Proof of Actor: AI does not need to disappear from digital interactions. It needs to become attributable.
Verified bots and Web Bot Auth: a step in the right direction
The industry is already moving toward letting automated clients identify themselves rather than disguise themselves. The idea of "verified bots", where known crawlers and services are recognised and treated accordingly, has been part of bot management for some time.
A more recent and promising development is Web Bot Auth, work within the IETF to let automated clients cryptographically sign their HTTP requests. It builds on HTTP Message Signatures (RFC 9421): an operator publishes public keys, signs requests, and the receiving site can check that a request really comes from that operator. Cloudflare, among others, supports this approach as a way of recognising verified bots and signed agents.
This is meaningful progress. It replaces "does this look like a bot?" with "this is a signed request from a known operator". But it is worth being clear about what a signature establishes. It identifies the operator of the agent. It does not, by itself, establish:
- which human or organisation the agent is acting for in this instance
- what that principal authorised it to do
- whether the current action is inside that authority
- whether the authority is still valid
- who is accountable if the action is disputed
Authenticating the operator is the foundation. Authorising the action is a separate decision, and it is the one that services such as merchants, banks and marketplaces actually need to make. That is the gap Proof of Authority is designed to address, and we explore it further in The Missing Trust Layer for AI Agents.
The role CAPTCHAs and bot management still play
Being fair to existing tools matters. CAPTCHAs and bot management remain useful for:
- reducing high-volume abuse such as spam, scraping and credential stuffing
- adding friction to low-value, high-frequency actions such as sign-ups and comment forms
- giving services a baseline signal about traffic
Proof of Actor is not designed to replace these tools, and we do not position it as a better CAPTCHA. They operate at the level of traffic and access. The Actor layer operates at the level of meaningful interactions: an assessment, an approval, a purchase, a review, a conversation. Most services will reasonably use both.
From challenges to evidence
The shift we are describing is from a single gate to contextual evidence. Instead of asking "did this visitor pass a challenge?", a service asks "what does this specific action require, and what evidence do we have?".
A forum comment may need very little. A verified review may need evidence of a unique real human. A hiring assessment may need continuous presence and human control. A large payment initiated by an agent may need a verified principal, a valid mandate and explicit human intent above a threshold.
In Proof of Actor's architecture, the result is an Actor Attestation, and the service expresses its requirements as a policy. The following is a Proposed API sketch, illustrative only and not available today:
// Proposed API - illustrative only, design is evolving
policy.allow({
actor: ["human", "authorized_agent"],
agentAuthority: { required: true }
});
Compare that with a CAPTCHA. The challenge produces one bit about one moment. A policy like this can admit a human, admit an authorised agent acting within its mandate, and treat an unverified actor according to the service's own rules. In our model, "Unverified Actor" means the trust relationship is unknown, not that the actor is malicious.
Privacy remains central. A service asking "is this a unique human?" should not need a name or a passport. A merchant asking "is this agent authorised to spend 200 dollars?" should not need the principal's address. We set out our approach on privacy and security.
Frequently asked questions
What is the best CAPTCHA alternative?
It depends on the question you need answered. For reducing high-volume automated abuse, modern bot management and lower-friction challenges are reasonable options. If you need to know whether a human is in control throughout an interaction, or whether an AI agent is authorised to act, you need a different kind of evidence than any challenge provides.
Can AI agents solve CAPTCHAs?
Automated systems have become increasingly capable at many kinds of challenges, which is one reason challenges alone are a weakening signal. More importantly, legitimate agents should not need to solve them. They should be able to identify themselves and prove their authority.
What is the difference between bot detection and verifying AI agents?
Bot detection asks whether traffic appears automated, usually to reduce unwanted activity. Verifying AI agents asks which agent is acting, who it represents, what it is authorised to do and whether a specific action is inside that authority. The first manages automation. The second makes legitimate automation accountable.
What is Web Bot Auth?
Web Bot Auth is an approach being developed within the IETF for automated clients to cryptographically sign their HTTP requests, based on HTTP Message Signatures. It lets a website check which operator sent a request. It identifies the operator, while decisions about what that agent is authorised to do remain separate.
Will Proof of Actor replace CAPTCHAs?
No. Proof of Actor is not designed to be a better CAPTCHA. It is being built as trust infrastructure for meaningful interactions, establishing who or what is acting, whether a human is in control and who authorised an agent. Bot management and challenges remain useful for traffic-level abuse.
Moving beyond the challenge
CAPTCHAs answered an important question for an internet where automation was mostly unwanted. The internet now includes humans, humans working with AI and agents acting on behalf of people and organisations. Serving all of them well requires evidence about actors, control and authority, not just a test at the door. Proof of Actor is building that trust infrastructure, described on how it works and across our use cases. We are in development and working with early design partners, and we would welcome you to join the Developer Preview or become a design partner.
