Cloudflare wants AI agents to stop being anonymous: here's its proposal for identifying them without tracking you

When an AI agent comes into your site to buy something, compare prices or log in, your server sees the agent, not the person who sent it. On November 5, Cloudflare published a long document, "Agents aren't humans (but they kinda are)", that puts a name to that problem and proposes how to solve it without blocking every agent or forcing them to pass as humans. It also announced a coalition, Trusted Agent Delegation (TAD), to take the topic to open standards at the IETF. It's not a new product: it's the roadmap for how Cloudflare thinks access control on the web is going to change. If you run a store, an API with a free tier, a login or a bot that browses other people's sites, this is going to affect you.

The problem: the site only sees the middleman

Cloudflare defines "personal AI agents" as automations that take instructions from a person and accomplish a goal by controlling a computer or a cloud browser. They are normally run by a company, which the document calls the operator, as part of a service. It gives Meta's Muse and OpenAI's dots as examples.

The central point is that these agents are intermediaries, just like a VPN, a proxy or a cloud browser. The difference, according to Cloudflare, is scale: agent traffic is growing fast and "could soon surpass" traditional human browsing. Before, a site could block intermediary traffic and ask people to turn off their VPN. When most traffic comes from agents, that way out stops working.

To explain it, the text uses an analogy. Ezra is a personal assistant to four clients and runs their errands. The shopkeeper on the corner no longer knows what each person likes, because he only sees Ezra. If a client asks for an iPhone and later says they never authorized it, the store can't prove anything, because the only person it saw was Ezra. And if another client gives Ezra a list of passwords to "try which one it was", the bank can only ban Ezra, which also shuts out the other three.

From this comes what Cloudflare calls the principle of intermediation: the business relationship between the user and the site, and each party's security responsibilities, must be preserved even when there's an intermediary in the middle.

Fourteen headaches, and the site pays for almost all of them

The document lists fourteen problems that were previously solved and that agents reopen. Some of the ones that will sound most familiar to anyone who runs a system:

Mixed traffic. If a user uses a shared agent to test stolen passwords, scrape content or test cards, the site can only block the whole agent, along with all its legitimate users.
Friendly fraud. Someone approves a purchase by their agent and then disowns it. Before, the store won the dispute with circumstantial evidence (same device, same IP, same address), but the agent buys from the operator's infrastructure and that evidence doesn't exist.
Resource exhaustion. Agents query prices and inventory nonstop, hit expensive endpoints like search or support chat, and use up free trials and promotions.
Impersonation. An attacker copies the user agent of a known agent to get the same permissions.
Consumption without compensation. The agent reads the article or the product page to answer the user somewhere else. The site pays to serve it and gets no visit, ad impression or purchase.
Broken risk-based authentication. Systems that expect the device and location to match the user see a "weird" agent every time, because it runs in the cloud.

The text's conclusion is blunt: in almost every case the main cost is absorbed by the site.

Why the "hand the CAPTCHA to the human" approach isn't enough

Cloudflare rules out two solutions that are often proposed. The first is for the agent to pass the CAPTCHA to its user to solve. According to the document, that only proves a human is present at that moment, not who they are or who the agent is acting for the rest of the time. Besides, agents exist to remove friction, so operators have incentives to skip that step.

The second is limiting the agent's permissions with very tight scopes. The problem, says Cloudflare, is that agents are built to do everything their user would do, so in practice they ask for permission for everything. And even if the scope were narrow, it doesn't answer the question the site really cares about: who steps up when the agent gets it wrong.

What it proposes: identity, reputation and accountability

The proposal is not to invent a single protocol, but to combine pieces that already exist or are being written. Cloudflare lays them out like this:

Agent identity. Its preferred method is Web Bot Auth: the agent signs its HTTP requests with an Ed25519 key and publishes its public keys in a /.well-known/http-message-signatures-directory directory. That identifies the agent and, along the way, its operator. Chains are still unresolved: when agent A uses agent B inside browser C, the site should be able to know.
Reputation without tracking. MOLE (Moderation of unLinkable Endorsements) is an IETF draft published on November 3, 2026 and signed by authors from Google, Mozilla and Cloudflare. A third party that already knows the client (an "anchor") vouches for them, and the site gives them a credential that lets it rate-limit them or withdraw trust without knowing who they are. Cloudflare presents it as the successor to Private Access Tokens and explained in another post how it plans to make it resistant to quantum computers.
Payments. The x402 protocol aims to enable payments on the web while preserving privacy.
Specific facts about the person. Some actions need a concrete fact, like being over 18 or being the cardholder. Cloudflare says mechanisms are needed for the site to ask for it and for the operator or a third party to confirm it, without handing over everything else.
Machine-readable rules. Today an agent discovers a site's rules by trial and error, especially when it gets blocked. robots.txt says where a crawler can go, but not what an agent can do. The IETF's AI Preferences group is working on usage preferences (training, inference, search), but, according to Cloudflare, there's still no group dedicated to the broader need.

Diagram with the four identity levels Cloudflare proposes (none, session, account and unique) and the protocols that answer each question: Web Bot Auth, MOLE, OAuth, x402 and AIPREF

Identity, in addition, is framed as a spectrum with four levels. In the first, the user hands over no identifier. In the second, a session is tied to an agent, as the session ID of Poppy does. In the third there is a stable account identifier, which would allow you to "link your account on the site with your account on the agent". In the fourth there is a unique identifier per person, which spans operators and agents, for high-risk actions or compliance obligations, such as an official ID or a third-party verification. The idea is that each site asks only for what the action requires.

The TAD coalition and what's left out

Cloudflare announced the Trusted Agent Delegation coalition to bring together agent operators, identity verifiers, payment providers, merchants, media outlets, proxies and cloud browser companies. The plan is to discuss the problem, review the protocols that already exist and take well-defined problems to the IETF, with side meetings and workshops. The announcement doesn't name the participants.

There's an important limit: the document covers agents hosted by an operator. Local agents that run on your own machine, and it cites OpenClaw as an example, are outside the initial scope. Cloudflare acknowledges that these agents "look like automation" and have no single party to hold accountable. One of the ways out it mentions is requiring a unique identifier from them, but it doesn't develop it.

What you can do today

What's already in production came out on November 4 and we covered it here. In short, if your site is behind Cloudflare, according to that week's announcement:

Security Analytics separates "Personal Assistants" as their own traffic category and shows which agents visit you, how many requests they make, which paths they hit and which errors they get.
In Security Settings → AI Crawler and Agent access policies you can allow, block only on pages with ads, or block each supported agent individually, without touching your search and training policies.
With Account Abuse Protection (still in early access) you see which agent did each login or sign-up, and you can mitigate a single account with a WAF rule on its Hashed User ID without blocking the agent for everyone else.

I haven't tested these features. The above comes from Cloudflare's official documentation and announcements.

My take

For those who run sites, the message is that blocking all agents is going to get more and more expensive, because behind many of them are real customers. For those who build agents or bots that browse other people's sites, signing requests with Web Bot Auth is on its way to being the bare minimum so you don't get treated like an anonymous scraper.

It also has to be read with a critical eye. Cloudflare sits in the middle of a huge share of web traffic, proposes the standards, co-writes several of them and sells the tools to enforce them. The fact that the work is going to the IETF and that MOLE carries signatures from Google and Mozilla helps, but we have yet to see who else sits at the TAD table and whether the big agent operators agree to identify themselves. Until that happens, the agent is still Ezra: friendly, helpful and anonymous.