Agents aren’t humans (but they kinda are)

Cloudflare argues that websites need a way to see past AI agents to the people they act for, and it is starting an industry group to work out standards for that (Cloudflare's post). The post is about personal agents: software that takes instructions from a person and pursues a goal by controlling a cloud computer or browser, run by a company Cloudflare calls the Operator, such as Muse from Meta or dots from OpenAI. To a website such an agent is an intermediary, like a VPN or a hosted browser. The site sees the agent, not the user, and loses the information it normally uses to recognize customers, judge whether they are trustworthy and decide who answers when something goes wrong.

Cloudflare illustrates the problem with Ezra, a personal assistant who runs errands for four clients. The grocer can no longer tell whose preferences are whose. When one client buys an iPhone through her and later denies authorizing the charge, the store has to prove a request from someone it never saw. When another hands her a list of passwords to try at his bank, the bank can see an attack but can only ban Ezra, which also cuts off her other three clients. In each case the business bears the cost. Sites could once block intermediaries and tell users to switch them off, but Cloudflare expects agent traffic to keep growing and possibly overtake human browsing, at which point blocking stops being viable. It also rejects two common fixes: passing a CAPTCHA to the user proves only that some human was present at that moment, and narrow permissions say what an agent may do but not who is accountable when it gets something wrong.

Its proposed answer is a set of mostly existing or emerging standards. Web Bot Auth lets an agent cryptographically sign its requests, identifying the agent and implicitly its Operator, though Cloudflare says it still needs to handle chains where one agent runs inside another inside a browser. Beyond that, Cloudflare describes user identity as a spectrum a site can ask for as needed: nothing, a session that links requests together, an account that persists across visits, or a unique per-person identifier for high-risk actions. Privacy-preserving methods such as Privacy Pass and MOLE, an upcoming protocol for rate limiting without user-specific identifiers, aim to tell a site whether to trust a visitor without saying who they are. Sites would also need ways to request facts such as being over 18, and a machine-readable way to say what agents may do, which robots.txt and the IETF's AI Preferences work do not fully cover.

Only part of this exists. The Trusted Agent Delegation coalition is a forum for discussion that intends to bring well-defined problems to the IETF, and agents running on a user's own device, such as OpenClaw, are outside its initial focus. What Cloudflare customers can use now are three product features, described in more detail in a companion post (visibility and control for personal agents): a Personal Assistants traffic category that shows which agents visit a site and what they request, per-agent access policies, and, in early-access Account Abuse Protection, a record of which logins and sign-ups came through which agent. That last feature lets a site act against one abusive account behind a shared agent through a rule on a hashed user ID, without blocking the agent for everyone else, which Cloudflare calls a first concrete answer to the problem Ezra illustrates. These are Cloudflare's own products and proposals; the post offers no data on how well they work.