Three settings per agent
The policy side expands the AI bot policies Cloudflare introduced this summer, which separated Search, Training and Agent behavior. The Agents policy now carries per-agent choices, and the setting is renamed AI Crawler and Agent access policies. An owner sets one overall Agents policy, then can choose Allow (do not block), Block on pages with ads or Block for each top personal agent. Cloudflare's own example is a site that blocks agents on ad pages generally but allows one named agent through. Search and Training policies remain separate. Each policy applies to verified bots with the corresponding behavior and matching unverified bots, so allowing a personal agent under the Agents policy does not automatically allow training crawlers.
Two details in the documentation narrow the announcement. The first is coverage: granular control applies to the top personal agents, in the blog's wording "supported personal agents." Cloudflare does not publish, in the announcement, which agents are on that list or how many. Agents outside the supported list remain subject to the overall Agents policy. Cloudflare does not publish figures showing how much personal-agent traffic the granular controls currently cover. The second is persistence. The documentation states that personal agents inherit the Agents policy by default, and that changing the Agents policy updates each personal agent, after which the owner can choose individual actions again. An exception set today does not survive a later change to the parent policy unless someone sets it again. Cloudflare recommends Allow for personal agents.
Knowing the agent is not knowing the customer
Account-level identification is a separate capability, and it is not generally available. Cloudflare describes Account Abuse Protection as currently in early access. Within that feature, owners can see which user an agent represents; login and sign-up events can identify personal-agent requests, and account overviews can list associated agents. A fraud analyst who spots an attacker working through an agent can apply a WAF rule to that account's Hashed User ID without blocking the agent for everyone else.
Cloudflare is unusually direct about what is still missing. Its announcement says a site may recognize the agent while lacking the context it would otherwise have about the user: whether they are an existing customer, what they authorized the agent to do, whether they hold a subscription, or which protections should apply. Carrying that context through the agent, assessing reputation and establishing accountability when something goes wrong are listed as the next goals, not as shipped features. So the control launched today adds a way to identify supported personal agents through Cloudflare's verified bot directory. It does not establish who authorized the request or what that person intended.
For publishers, the practical read is narrower than the headline and still useful. Agent traffic that was previously grouped under the Automated category can now be examined by identified agent. Publishers can use the available controls to make different access decisions for supported agents, including allowing access generally while blocking requests on pages with ads. What it is not is a consent system for the agent era, and Cloudflare, to its credit, says so in its own post.
Sources
- [1] Cloudflare, "See the agents, set the terms: new visibility and control for personal agents", Cloudflare Blog, November 4, 2026 (read first-hand at Gate 1; analytics, policy options, Account Abuse Protection early access, and the "agent identity is only part of the story" limits)Read source
- [2] Cloudflare documentation, "AI Crawler and Agent access policies" (read first-hand at Gate 1; "customize access for the top Personal Agents", inheritance and reset behavior, verified and matching unverified bots, Allow defaults for new domains, Allow recommendation)Read source