Cloudflare Adds Per-Agent AI Assistant Controls | Zeniteq
Loading
Loading article
Zeniteq is now available on mobile for iPhone, iPad and Apple Watch.Download nowLearn more
Cloudflare Adds Per-Agent AI Assistant Controls
Cloudflare’s new analytics and access policies let site owners treat supported personal agents individually, while user-level attribution remains an early-access feature.
Cloudflare launched new analytics and access controls on November 4, 2026, allowing website owners to identify and manage traffic from specific supported AI personal assistants.
The update adds a Personal Assistants category to Security Analytics, providing widgets to inspect request paths, response codes, and originating networks for individual agents. Under Security Settings, users can now apply granular access policies—choosing to allow, block, or restrict agents on ad-supported pages—while a separate Account Abuse Protection feature for user-level attribution remains in early access.
Cloudflare launched new personal-agent analytics and access controls on November 4, 2026, giving website owners a way to identify supported AI assistants in their traffic and make separate access decisions for each one.
The update adds a Personal Assistants category to Security Analytics, along with a widget showing which agents visit a site and how many requests they send. Site owners can filter those requests to inspect paths, response codes and originating networks. In Security Settings, they can apply an overall Agents policy and make exceptions for individual supported assistants, according to Cloudflare’s announcement.
The main launch covers traffic analytics and policy controls. Connecting an agent’s login or signup activity to a particular user belongs to Account Abuse Protection, which Cloudflare identifies as early access.
That split determines what a security team can do: investigate and control an assistant across a site, or investigate its activity on a specific account.
Find Personal Assistants in Security Analytics
Cloudflare defines personal agents as intermediaries that turn a person’s instructions into website requests and actions. A shopper might ask one to compare products, find support information or complete a purchase. Each task produces automated traffic, but the business value and risk can differ considerably.
In Security Analytics, the Bot Analysis chart now places Personal Assistants alongside these existing categories:
Verified Bot
Likely Human
Likely Automated
Automated
Selecting Personal Assistants isolates that category’s traffic over time. Under Top statistics, a new Personal Assistants widget lists identified agents and their request counts. Selecting one agent filters the other widgets to its requested paths, received status codes and originating networks, Cloudflare says.
A practical inspection sequence looks like this:
Select Personal Assistants to see the overall pattern of agent traffic.
Choose an individual agent in Top statistics.
Inspect requested paths to see which parts of the site it reaches.
Compare response codes to find successful responses and error patterns.
Like this article (0 likes)
Save article
Review originating networks for additional context about those requests.
The useful change is the connection between identity and behavior. A request count says how active an assistant is; the filtered paths and responses help explain what that activity involves.
For example, requests concentrated on product pages suggest a different workflow from repeated requests to login or checkout paths. Errors concentrated on a particular route could give a site team somewhere specific to investigate.
Those are investigative signals, not proof of intent or task completion. Reaching a checkout path does not prove a purchase succeeded, and repeated errors alone do not prove abuse. The dashboard can help locate a problem, but the site’s own application and transaction records still matter when deciding what happened.
I’d start with those path-and-response patterns before changing access. A high-volume assistant may be performing useful customer-directed work; an assistant sending fewer requests could still be repeatedly failing at a critical step.
Set an Overall Policy, Then Make Agent Exceptions
Cloudflare has renamed Configure AI bot policies to AI Crawler and Agent access policies. Its November 4 changelog gives the configuration path:
Security > Settings > AI Crawler and Agent access policies
The existing Agents policy now supports individual choices for supported personal agents. Site owners set the overall policy, then choose a different action for an assistant when needed.
Do not block the supported agent through this policy
Welcome an assistant whose access fits the site’s needs
Block on pages with ads
Restrict the agent on ad-supported pages
Apply an access boundary tied to advertising
Block
Block the supported agent through this policy
Deny that assistant access
Cloudflare’s example uses Block on pages with ads as the overall Agents policy, with an Allow (do not block) exception for one supported personal agent. Existing Search and Training policies remain unchanged, according to the announcement.
That separation matters. A site can make a new decision about assistants acting for users without also changing its policies for search-oriented or training-oriented AI traffic.
The controls also appear when adding a new Cloudflare zone. During onboarding, Cloudflare asks whether the site monetizes pages with ads and adjusts its recommended policies to that answer. Owners can revisit those choices later in Security Settings.
Match the Policy’s Scope to the Evidence
The three choices cover different access preferences, but they are not a general-purpose menu of every possible restriction. The announced per-agent options do not include a custom request quota or an arbitrary list of permitted routes.
Cloudflare’s opened announcement also does not explain how it determines which pages contain ads. Site owners considering that middle option should check the applicable configuration details before treating it as an exact map of their monetized content.
My view is that per-agent exceptions are the most useful part of this update. They let a site maintain a broad default while making a narrower decision when the analytics justify it. A publisher could restrict agents on ad-supported pages yet welcome one supported assistant; another business could choose a different balance based on how customers use its site.
An Allow selection should still be read according to its label: this policy will not block the agent. It is not a statement that every request is safe or that the person behind it is authorized to perform every action.
The feature also has a defined recognition boundary. Cloudflare describes controls for supported personal agents, and the opened sources do not enumerate that set or claim universal identification of all agent traffic. Plan-specific availability and identification accuracy are not detailed in those sources.
Account Abuse Protection Adds User-Level Context in Early Access
Account Abuse Protection addresses a different question: which user account is associated with an agent’s activity?
Cloudflare says its early-access product adds several views for site owners and fraud teams:
Population overview: shows which personal agents are active across users and how many accounts use them.
Login and signup events: indicate whether a personal agent made the request and identify the agent.
Account filters: let analysts filter by AI-assistant events or number of AI assistants.
Individual account overview: shows the agents associated with a particular account.
Those views support a more focused investigation. Cloudflare gives the example of comparing an agent that a customer has used for weeks with one appearing on the account for the first time.
A newly observed assistant is a reason to investigate, not a verdict. The useful addition is account history: an analyst can consider the assistant’s appearance alongside the account’s other activity.
If the investigation points to misuse, Cloudflare says an analyst can mitigate the account with a web application firewall rule targeting its Hashed User ID. That creates an account-specific response without blocking the assistant for everyone else who uses it, as described in the launch post.
This is the sharpest operational distinction in the announcement:
Decision
Relevant scope
Change access for a supported assistant across the site
Per-agent access policy
Investigate which account an assistant represents
Account Abuse Protection, early access
Mitigate suspected abuse tied to one account
WAF rule targeting that account’s Hashed User ID
The sources do not specify early-access eligibility or a general-release date. Teams without Account Abuse Protection should not assume that identifying an assistant in Security Analytics also reveals the customer behind it.
Agent Identity Still Leaves Authorization Unresolved
Cloudflare acknowledges that recognizing an agent leaves important user context missing. A website may know which assistant made a request while lacking information about whether the represented person is an existing customer, holds a subscription or authorized a particular action.
The company describes preserving that context as its next goal. Its proposed work involves privacy-aware ways to carry user context through agents, assess reputation and establish accountability when something goes wrong, according to the announcement.
Those are future goals, not capabilities to assume from this release.
Even the early-access account association answers a narrower question than authorization. Knowing that an assistant is associated with an account does not, by itself, explain whether its user approved a purchase, a profile change or another sensitive action.
The practical contribution of this update is a more precise decision process. Site owners can first identify a supported assistant, inspect its request patterns and then choose an access policy at the agent level. Eligible fraud teams can go further and investigate account-specific activity.
That makes the scope of the response important. Evidence that an assistant consistently fails on a site may justify an agent-level decision. Evidence of suspicious activity on one account calls for a narrower investigation where the account tooling is available. Treating those as separate problems helps avoid turning a single account incident into a block affecting every customer who uses the same assistant.
Frequently Asked Questions
4 questions
1
Where Are Cloudflare’s New Agent Controls?
They are under Security > Settings > AI Crawler and Agent access policies. The analytics appear in Security Analytics through the Personal Assistants category and widget.
2
Can Site Owners Set Different Rules for Each Assistant?
Yes, for supported personal agents. The choices are Allow, Block on pages with ads, or Block, with individual selections alongside an overall Agents policy.
3
Can Security Analytics Identify the User Behind an Agent?
The announced Security Analytics views identify agents and their traffic. User-to-agent attribution is part of Account Abuse Protection, which is in early access.
4
Does This Change Search and Training Policies?
No. Cloudflare says existing Search and Training policies remain unchanged when configuring the expanded personal-agent controls.
