AI agent identity: knowing which agent is calling, and why that is only half the problem
Agent identity is becoming solvable: signed requests, published key directories, authorisation mandates. A verified agent can still buy all your inventory, so identity is the foundation and not the answer.
Agent identity is the part of this problem that is actually being solved. There is standards work, there are published key directories, and there are authorisation protocols that record what a person asked an agent to do. Within a couple of years, verifying which agent is calling you will be routine.
That progress makes it worth being precise about what it buys, because the answer is less than most of the discussion assumes.
What exists now
| Mechanism | What it proves | Status |
|---|---|---|
| User-agent string | Nothing. It is a claim | Universal, and useless for blocking |
| Published IP ranges | That the request came from the operator's infrastructure | Works today. OpenAI, Perplexity, DuckDuckGo and Google publish; Anthropic does not |
| Reverse DNS | The same, less precisely | Works for some agents |
| Web Bot Auth | That the request was signed by a key the operator published | IETF draft, built on HTTP Message Signatures |
| AP2 mandates | That a specific user authorised this agent to make this purchase | Live, Google-led with 60+ partners |
The jump from the second row to the fourth is the one that matters. An IP range tells you the request came from a particular company's servers, which is weak — it breaks the moment an agent runs on the user's own machine, which is exactly where agentic browsers run. A signature travels with the request regardless of where it originates.
The jump from the fourth row to the fifth is the one almost nobody discusses, and it is more important.
Who is building it, and the objection to that
Cloudflare is pushing hardest, and its signed-agents work is why Web Bot Auth has momentum. The mechanism is sound: per-request signatures using RFC 9421 HTTP Message Signatures, verified against a key the operator publishes at a well-known location. Open-source verifier middleware now exists for Node, Python and Workers, with a WordPress plugin, so an origin can check signatures itself rather than waiting for an edge vendor to offer it.
The criticism is not about the cryptography. The current implementation is built bot-first rather than agent-first, and it places one network as both arbiter and on-ramp — excellent for reliability inside that network, and a long way from an open agentic web. A registry curated by a single company is a gatekeeper whatever the standard underneath it says.
Our position: the signature is the right primitive and the registry is the part to watch. A scheme where anyone can publish a key directory is an open standard. One where a single network decides which keys count is an allow-list with extra steps.
There is also a perverse incentive to keep in view. If operators allow-list a few well-known agents and charge or restrict everything else, the rational move for a small well-behaved agent is to stop declaring itself — see x402 and agent payments for where that pressure comes from. Identity schemes work when declaring yourself is rewarded and decay when it is punished.
A verified agent can still buy all your stock
An agent credential answers "which agent is this". It does not answer "should this be allowed to happen".
Those are genuinely different questions, and the gap between them is where the commercial damage lives. A verified agent from a named operator, correctly signed, behaving exactly as documented, can still buy every unit of limited stock you have before your customers reach the page. Nothing about its identity is in question. The volume is the problem, and no credential describes volume.
This is why we keep arguing for per-flow policy rather than per-client policy. Identity lets you build an allow-list, which is genuinely useful — you can let a verified assistant browse, search and compare without friction. It does not tell you whether to let that same assistant complete a purchase, and that decision has to be made on what the action costs you if it happens ten thousand times.
Mandates: proof that a person asked
The more interesting development is mandates: a cryptographically signed record of what a user permitted an agent to do. AP2, the Agent Payments Protocol, is built around them, and the reason they matter is liability rather than security. When a purchase is disputed, the question is not which agent made it but whether a person authorised it, and a signed mandate is evidence that can be produced.
For a site owner that reframes the question usefully. Instead of "is this a bot", which agentic clients have made unanswerable, you can ask "is there a person accountable for this action" — and that question has a credential attached.
What we would do today
Nothing here is ready to be your only control, so the practical position:
- Verify by published IP range for the crawlers and assistants you want to allow, and treat user-agent strings as unreliable. Ours were wrong 53% of the time.
- Allow freely, restrict narrowly. Let agents read. Require evidence of a person on checkout, bulk export, account changes and anything a scalper would want to run at scale.
- Watch Web Bot Auth and be ready to accept signatures when operators start sending them. It is the right foundation for an allow-list and it will not arrive as a flag you switch on.
- Keep scoring behaviour. A credential tells you who; behavioural analysis and volume tell you what, and the second is what determines whether you can absorb it.
The summary we would offer: identity is necessary, nearly here, and not sufficient. Build for it, and do not wait for it.
Building an agent policy?
If you are deciding which automated clients to allow and on what terms, tell us which clients you are unsure about. We will tell you which can be verified today and how.
Frequently Asked Questions
What is AI agent identity?
A way for an automated client to prove which agent it is, rather than asserting it in a user-agent string that anyone can copy. The serious approaches are cryptographic: the client signs its requests with a key, and you verify the signature against a directory the operator publishes. Web Bot Auth, an IETF draft built on HTTP Message Signatures, is the main standards effort.
What does 'know your agent' mean?
It is a deliberate echo of know-your-customer in finance, and it means establishing who an automated client is and who it acts for before allowing it to transact. In practice it has two halves: identity, which is the agent's own credential, and authorisation, which is proof that a specific person asked it to do a specific thing. The second half is what protocols like AP2 address with signed mandates.
Why is a user-agent string not enough?
Because it is a claim, not a credential. In our own CDN logs over thirteen days we found that 53% of all requests presenting an AI crawler user-agent came from addresses belonging to none of the vendors named, and a large share of those were simultaneously probing for /.env and /.ssh/config. A user-agent is useful for allowing traffic you want and worthless for deciding what to block.
Does verifying an agent mean I can trust it?
No, and conflating the two is the main risk. Identity tells you which agent is calling. It says nothing about whether the task it was given is one you want performed — a verified, well-behaved, correctly signed agent can still buy every ticket you have. Identity is the basis for a policy; it is not a policy.
How do I verify a crawler or agent today?
By IP address against the ranges the operator publishes. OpenAI, Perplexity and DuckDuckGo publish per-crawler JSON range files, Google publishes its ranges, and some agents are verifiable by reverse DNS. Anthropic publishes no list, so the fallback is behavioural. This is the only method that works now; signature-based verification is the direction, not yet the default.
