When a remotely hosted agent acts as an intermediary between a user and a website, the site often interacts with the agent rather than the human user. This shift creates a fundamental governance challenge: how to recognize, serve, and hold operators accountable while maintaining privacy. To navigate this, operators must distinguish between three distinct layers of agent identity: access permission, agent or operator verification, and user or account attribution. These layers are not interchangeable, and current tools are designed to address specific, limited functions rather than providing a singular, unified identity solution.
On November 5, 2026, Cloudflare announced the Trusted Agent Delegation (TAD) coalition. The coalition is not a technical standard itself. Cloudflare says its goal is to bring ecosystem representatives together to examine existing protocols and take well-defined problems to the IETF as needed. The TAD site highlights the central tension in this work: the need for sites to gain enough context to recognize and serve users and ensure accountability, while ensuring users share only the context an interaction requires, without enabling cross-site tracking.
Cloudflare’s policy documentation distinguishes between Search, Agent, and Training behaviors. Within this framework, an “Agent” is defined as automated activity acting in real time for a person. Site operators can set policies to allow, block, or block on pages with ads. Furthermore, individual policy settings are available for top Personal Agents, while others inherit the general Agent policy by default. These policies apply to both verified bots that exhibit these behaviors and matching unverified bots, providing a broad mechanism for managing access.
It is important to recognize that an Agent policy controls whether matching traffic is allowed, but it does not by itself establish user account identity or who authorized the specific action. The policy acts as a gatekeeper for the connection, determining if the agent is permitted to interact with the site’s resources. Because the policy operates at the traffic level, it cannot verify the intent or the authorization status of the human user behind the request. Therefore, any assumption that a permitted agent request implies a verified user action is an inference, not a technical certainty.
Beyond policy enforcement, Cloudflare’s Security Analytics provides visibility into these interactions. The tool allows operators to identify Personal Assistants as a specific category, showing request counts, paths, and errors. These controls do not establish the identity of the end user. They provide a mechanism for observing traffic patterns, but do not bridge the gap between the agent and the human operator or individual user behind the request.
The Web Bot Auth (WBA) protocol uses cryptographic signatures to verify the identity of the agent or operator. Crucially, this signature authenticates the agent or bot identity; it does not verify the identity of the human user. Cloudflare’s model treats these as distinct, and a mechanism to support multiple intermediaries—where an agent might pass through several services—remains undefined. WBA identifies the tool, not the human.
For user-level visibility, Cloudflare’s Account Abuse Protection (AAP) is currently in Early Access. When the system recognizes an assistant making a login or sign-up request, it records that assistant against a zone-specific Hashed User ID. This visibility is limited to recognized login and sign-up events, allowing operators to mitigate an individual account without blocking an assistant for all its users. Because the identifier is zone-specific and the signal appears only on recognized login or sign-up events, AAP provides a narrow account-level response path rather than a universal identity record.
Access permission, agent verification, and user attribution answer different questions. As an analytical implication, operators should map each control to its job instead of treating one as proof of the others. The distinction also captures TAD’s privacy tension: sites need enough context to act responsibly, while users should not have to expose a portable identity across sites for every interaction. Cloudflare’s current controls cover parts of that problem; the coalition’s stated work is to examine protocols and define the remaining gaps.
