Cloudflare published the post “Agents aren’t humans (but they kinda are),” which formulates the “intermediation principle”: when a personal AI agent, such as Meta’s Muse or OpenAI’s dots, acts on behalf of a user, the website sees not a human, but an intermediary, and loses data for identification, reputation, and accountability. The company lists 14 problems this creates for site owners and announces the Trusted Agent Delegation (TAD) coalition, which gathers existing open standards into a common trust delegation framework. Some of the necessary tools are already built into Cloudflare products, so agent traffic can be restructured right now.

image
image

What happened

On November 5, 2026, Cloudflare released the post “Agents aren’t humans (but they kinda are)” on its corporate blog. Its central thesis is called the “intermediation principle,” and the company builds a list of 14 problems for site owners on it, including account sharing, friendly fraud, and traffic commingling. According to the authors, CAPTCHA and human-in-the-loop approaches, as well as narrow scope permissions, do not cover this class of tasks. As a response, the Trusted Agent Delegation (TAD) coalition was announced, relying on existing standards and drafts: Web Bot Auth for cryptographic signing of requests by an agent, the internet draft MOLE (Moderation of unLinkable Endorsements) for rate limiting without identity binding, the x402 payment protocol, as well as OAuth and the IETF AIPREF working group, where site preferences regarding agents are discussed.

Context

Standard website protection distinguishes bots from humans by behavioral signals, but a delegated agent moves the task beyond this scheme: a sanction against an intermediary inevitably affects all its users, so the conversation about blocks turns into a conversation about identity delegation. The solution seeks to connect the website, user, agent, and operator into a single chain of trust, where each participant is identifiable and accountable for their actions. The declared stack consists of existing mechanisms, and the novelty of the post is not in individual components, but in their arrangement for the “agent acts on behalf of a user” scenario: this is an engineering formulation of a new system task, not a scientific result. The authors consider the “agent as human” model non-functional and expect that websites will begin to require explicit identification and operator accountability from agents.

Why this matters for the industry

For the industry, the post means a shift in framework: agent traffic is proposed to be regulated through open standards rather than blocked, and this potentially changes the economics of web traffic, anti-fraud models, and API requirements, because the cost of agent errors falls on websites, not agent operators. Identification, reputation, and accountability of AI agents are transforming from a bot management function into an independent product layer. The Trusted Agent Delegation coalition and work in IETF may become the basis for a de facto agent identification standard, which agent developers, payment providers, and site owners will have to take into account. In a horizon of approximately six months, with the recruitment of participants, draft delegation specifications, first production integrations and SDKs, and “signed agent or access denied” format requirements are expected. In a horizon of about two years, the scenario of agent identity as “robots.txt 2.0” is discussed: websites distinguish between user, agent, and operator, sanctions shift from the agent level to the user account level, and delegated payments and agent reputation form a market for infrastructure products.

Why this matters for users

For a reader who builds agents or manages a website, the post is useful primarily for the list of already available tools. Cloudflare site owners have access to widgets in Security Analytics with the “Personal Assistants” category for segmenting agent traffic, AI Crawler and Agent access policies for managing access to individual agents, and Account Abuse Protection with Hashed User ID, which blocks a specific account within a common agent, not the entire agent. Agent developers can already implement cryptographic signing of requests according to Web Bot Auth and build support for rate limiting and payment of agent actions into their architecture. Individual solutions, including Account Abuse Protection, are distributed in early access, so it is worth familiarizing with them with an eye on changing terms. This is already enough to enable and test per-agent policies and check how agent traffic is segmented on a real website.

What is still unknown / limitations

The material lacks measurable evidence of effectiveness: the share of agent traffic is unknown, false positive rates of blocks and metrics for reducing friendly fraud, account sharing, or commingling are not measured, and there is no comparison with the baseline before and after the implementation of Web Bot Auth and MOLE. The Trusted Agent Delegation coalition remains an announcement: participants and membership terms are not disclosed, and MOLE exists as an internet draft draft-jms-mole-architecture and may change or not advance in IETF. Account Abuse Protection is available in early access without public pricing, terms may change, and privacy guarantees of the scheme with Hashed User ID are not disclosed in the source. Forecasts about the first delegation specifications in a six-month horizon and about agent identity in the spirit of “robots.txt 2.0” in a two-year horizon are low-confidence interpretations, as is the expectation of the first public attacks on the WBA and MOLE combination, including relay scenarios.

Sources

Author

Look at AI, editorial team