When AI Agents Hide the User, Sites Lose Their Footing

For the websites they visit, that creates a basic problem: the visitor on the other end may be one person carrying out a single task, or one automated system acting for a crowd of users. In both cases, the site loses the direct link to the person it has always served, and it's the site that absorbs the cost when something goes wrong. My read is that this is the central access question for the agentic web, and it's more about trust plumbing than about bot detection.

Why the agent is the problem

Cloudflare's argument starts from a simple claim. For a website, an agent can look like many things. Sometimes it's indistinguishable from a human completing a task. Other times it's one visitor that is really a front for many users. In either case, the site can't reliably recognize the people behind the agent, serve them appropriately, or hold them accountable.

The agents in question are what the company calls "Personal AI Agents." These are automations that take instructions from a human, the "User," and pursue a goal by controlling a cloud computer or a browser. An "Operator" usually hosts and maintains them as a managed service or consumer product. Meta's Muse and OpenAI's dots are cited as examples, and more launch regularly.

What makes these agents different from a scripted bot is that they can do anything their user could do, minus the limits that come with being human. They don't get tired, they run around the clock, they work in parallel, and they tolerate friction that would make a person quit. Much of the web's economics assumes those limits exist. Capacity planning, rate limits, pricing and even ad impressions all lean on the assumption that one visitor equals one person in one sitting.

Here's the thing: the agent isn't a new kind of problem so much as the newest kind of intermediary. An intermediary sits between a user and a site, so the site sees the intermediary instead of the person. Cloud browsers and proxies, including VPNs, already do this. Agents are simply the version that's growing fastest. Cloudflare argues that agentic traffic could eclipse traditional human browsing in the near future, and if that happens, blocking intermediaries stops being a practical option. A site can block a VPN it dislikes. It can't block the majority of its traffic.

The Ezra problem

The clearest way to see the issue is through an analogy the post uses. Ezra is a personal assistant who runs errands for four clients: Amy, Bob, Charlie and Debra. She buys groceries, books appointments, handles paperwork and arranges flights. To the shopkeepers she deals with, she blends into the crowd.

The corner grocer used to know Amy. He knew her habits and set aside things he thought she'd like. Now Ezra arrives carrying orders for four people, and he can't tell whose preferences are whose. He doesn't want to turn her away, because she brings a lot of business.

Then the failures start. Bob asks Ezra to buy him an iPhone, then calls the store a week later to say he never authorized it. To resolve the dispute, the store needs to prove Bob made the request. The only party it ever dealt with was Ezra. Next, Charlie hands Ezra a list of passwords, saying he forgot his and one of these must work. Ezra tries each one at Charlie's bank. The bank can see an attack unfolding, but the only account holder it can block is Ezra, and blocking her also cuts off Amy, Bob and Debra.

None of these businesses has a complaint about Ezra herself. Their problem is that they can only see the intermediary, not the person she's acting for. Swap Ezra for an AI agent and the shops for websites, and you have the web today. That, in Cloudflare's framing, is the Intermediation Principle: the business relationship between users and sites, and each party's security responsibilities, must hold regardless of whether an intermediary is involved.

The post lists specific failure modes that follow from this. Traffic commingling means a site can't separate one user's requests from another's when they share an agent. Policy circumvention means an agent can route around rules that were written with individual users in mind. Identity verification breaks when a check designed for a person is passed along a chain of automation. Friendly fraud gets harder to adjudicate when the person who disputes a purchase is not clearly the person who made it. Misalignment, where an agent does something the user didn't want, is also harder to trace.

Cloudflare's point is that in nearly all of these cases, the site carries the main cost. The business loses revenue, absorbs fraud, or spends engineering effort guessing at who a request belongs to. The agent's operator and the user don't pay that cost directly, which is part of why the problem has been slow to get fixed.

What the company wants instead

Cloudflare's stated goal is an internet where users have equal or greater access to websites than they had before agents arrived. The company is careful to say this doesn't require agents to behave like humans, or a human to approve every action. It requires that a site can obtain or require information about the user when it needs to hold that user accountable, whether or not an agent is involved.

Before agents, sites had a toolkit for this. They fingerprinted devices, tracked sessions and checked browsing history. Private browsing modes weakened some of those signals without eliminating the site's ability to make a judgment. The post's position is that agents should be able to use private modes too. But a bank, for instance, probably won't let an agent log in without additional verification, and that's a reasonable outcome, not a bug.

The question, as the post frames it, comes down to three things a site needs to answer. Is the entity acting truthful about who it is? Is it trustworthy? And who answers for the action? Those map onto identity, reputation and accountability, which have long been the backbone of security and fraud prevention. Agents don't make those questions obsolete. They make it harder for a site to answer them through the usual signals.

Why the obvious fixes fall short

The first common proposal is to have agents pass CAPTCHAs through to the user. That confirms a human is present at that moment, which the post calls "human in the loop," or HITL. Cloudflare's objection is that HITL is mainly a safeguard against misalignment between operator and user. It doesn't tell the site which user is behind a request when many share an agent. It says nothing about who the agent is acting for the rest of the time. And since agents exist to remove friction, operators have a strong incentive to remove or bypass HITL prompts for their users. A safeguard that users are motivated to skip doesn't add much.

The second proposal is tightly scoped access controls. The problem is that agents are built to do whatever their user can do, so in practice they request and receive broad permissions. A scope of "everything" tells the site nothing. Even a narrow scope only describes what the agent was allowed to do. It doesn't answer the question the site actually cares about: who is responsible when the agent gets something wrong?

Identity is a spectrum, not a switch

The more interesting part of the argument is the idea that identity should come in graduated levels, with data minimization as the guiding principle. The post describes four tiers.

At the first tier, nothing is disclosed. A user acts without bringing any identifiers. At the second, session, the site can link requests in the same session to a single agent, which lets it build reputation within that session. Poppy, a personal agent protocol, includes a session ID for this purpose. At the third tier, account, the site can attribute requests to the same user across sessions. This is the model behind a sentence like "bind your site account to your agent account." It usually involves a stable identifier assigned by an operator or third party. At the fourth tier, unique, a third-party identifier persists across operators, accounts, agents and sessions. That level suits high-risk actions, expensive resources, or sites with strict compliance obligations. The post cites government-issued identity documents, third-party identity verification and proof-of-personhood systems as examples that can supply it.

Cloudflare's view is that many cases don't require the top of that ladder at all. Privacy-preserving approaches can answer "can we trust you?" without first answering "who are you?" Private Access Tokens were an early attempt at this, and the company says MOLE, a proposed approach for rate limiting without user-specific identifiers, is meant to succeed it. The distinction matters. A site that only needs to know whether a requester has a good track record shouldn't have to collect a name to find out.

Protocols that already exist, and what's missing

Much of the proposed stack is built from work already in progress rather than from new inventions. Web Bot Auth, or WBA, lets an agent sign its requests, giving it a verifiable way to identify itself and, implicitly, its operator. Cloudflare calls WBA its preferred method for agent identity. But WBA on its own doesn't handle nesting well. If Agent A uses Agent B inside Browser C, the site needs to understand that chain to avoid policy circumvention. That multi-hop case is still an open design problem.

For reputation and rate limiting, MOLE is the approach the company is pursuing. For payments that stay privacy-preserving, it points to the x402 protocol, which aims to enable web payments while limiting the personal data exchanged. The broader strategy is to lean on existing protocols where they fit and design new ones where they don't. OAuth covers account identity. Other proposals cover related problems, including WIMSE, which the post names alongside the others.

Claims form a separate category. Some actions depend on a fact about a real person, such as being over 18 or being the cardholder on a payment method. Often the operator verified that fact at sign-up, or a third party already holds it. What's missing is a standard way for a site to request that specific fact and for an operator or third party to supply it without handing over everything else. That's a narrower, more tractable problem than full identity, and it may be where the earliest practical wins show up.

A machine-readable access policy

Today, an agent learns a site's rules by trying something and watching whether it gets blocked. That wastes compute on both sides, and it can make honest agents look malicious. Robots.txt tells crawlers where they may go, but the post argues it isn't well suited to express what agents may do.

Sites need a machine-readable way to publish which actions agents are allowed to take. The Internet Engineering Task Force's AI Preferences Working Group is developing preference-expression mechanisms, but its focus is on how content may be used, such as for training, inference and search. The broader need for expressing what agents may do on a site doesn't yet have a dedicated group. Cloudflare says it is working to bring that into the standards process.

Local agents are a different case

The post explicitly sets aside agents that run on a user's own device, or as locally hosted software such as OpenClaw. Those agents look like automation, and there is no single intermediary to build reputation with or hold accountable. A unique ID could help, and the company acknowledges several possible approaches. But it isn't the initial focus of the current effort. That scope choice matters: the framework described here is designed for hosted intermediaries, where an operator exists to stand behind the agent.

Where the work is going

Cloudflare says durable solutions won't come from fragmented, vendor-specific mechanisms. They need open, interoperable standards grounded in running code. The company says it has been working with major operators, identity verification firms, payment providers, merchants, publishers, proxy providers and cloud browser companies to align operational requirements with standards work at the IETF and elsewhere.

The company is also announcing the Trusted Agent Delegation (TAD) coalition. Its stated goal is to bring representatives from across the ecosystem together to discuss the problem set, review existing protocols, and then bring well-defined problems to the IETF. The coalition plans side meetings at the IETF and future workshops. Cloudflare is asking agent builders, runtime developers, edge and cloud platforms, and teams that manage commercial or compliance infrastructure to participate. Details are on the TAD site at trustedagentdelegation.org.

That's the forward-looking part, and it's the slow part. Standards take time, and the pieces are at different maturity levels. WBA and MOLE are further along than a multi-hop identity chain or a standard for agent-level access policy.

What's shipping now

Cloudflare is also pointing to features that customers can use today, without waiting for protocols to finalize. Three stand out.

First, visibility. Security Analytics now breaks out personal assistants as their own traffic category. A new widget lists every agent visiting a site, along with its request volume, the paths it hits and the errors it encounters. For teams that have been staring at unexplained automated traffic, that's a practical change. Enterprise Bot Management customers can also use Business Insights to compare how much each operator crawls against the traffic it sends back.

Second, per-agent access control. Through AI Crawler and Agent access policies, a site can allow an agent across the whole site, allow it only on certain pages, or block it entirely. Search and training policies remain independent of each other. That granularity is useful because the right answer for a shopping agent is often different from the right answer for a research crawler.

Third, attribution at login. For sites using Account Abuse Protection, which is in early access, every login and sign-up now shows whether a personal agent made the request, and which one. If an attacker abuses a shared agent to hit one account, the site can mitigate that account with a WAF rule on its Hashed User ID, without blocking the agent for every other legitimate user behind it. This is the most direct response so far to the traffic commingling problem: the site can see past the agent to the user and act on that user specifically.

Cloudflare describes these as the first building blocks of its vision, already in production, with more to come as standards mature. It also says it wants to hear from companies with more restrictive positions on agents, and it has invited direct contact at [email protected].

What to watch

The open question is whether the industry settles on a shared way to express what an agent is allowed to do on a site. Identity and reputation tools can be layered on later, but without a common access vocabulary, every site will keep reinventing the same negotiation with every agent. The second question is whether operators will keep HITL and similar checks in place when they cost users something. Agents are sold on removing friction, and any safeguard that adds friction will face pressure. The third is multi-hop identity. An agent that calls another agent inside a hosted browser is already a real pattern, and the protocols are still catching up to it.

For developers building agents, the practical takeaway is to expect sites to ask who is behind a request, and to plan for signed requests, session-level attribution and per-action permissions now rather than after a site starts blocking you. For site operators, the useful move is to start measuring agent traffic and deciding which agents you want, instead of waiting for a single standard to decide for you.