On November 4, Cloudflare launched a set of analytics and controls aimed at personal agent traffic. Site owners can now see, in their dashboard, the agents that compare prices, look up information and place orders on behalf of users, and set an access policy for each one separately.
This kind of traffic has been awkward to handle. A real user stands behind every agent, so blocking them all could cost customers, while letting them all through leaves site owners unable to see what the agents are doing. Cloudflare's approach this time is to separate them from other automated traffic first, and leave the access rules to the site owner.
“Better visibility into agent activity allows you to decide what access makes sense for your site.”
What is new in the dashboard
Analytics. The Bot Analysis chart in Security Analytics has a new Personal Assistants category, listed alongside Verified Bot, Likely Human, Likely Automated and Automated. The Top statistics view also gains a component that lists the agents visiting the site and their request counts. Once you filter on one agent, the other components update to show the paths it requested, the status codes it received and the source networks.
Account level. Sites with Account Abuse Protection enabled can also see which user an agent is acting for. Login and sign-up events indicate whether a personal agent initiated them and which one it was, so fraud teams can filter accounts by agent events or volume. If an attacker takes over an account through an agent, a WAF rule can be written against the Hashed User ID to act on that single account, leaving other users who rely on the same agent unaffected. This capability is still in early access.
Policy. The existing AI bot policy had three categories: Search, Training and Agents. Agents now extends to supported personal agents, and the setting has been renamed AI Crawler and Agent access policies. Each agent gets three options:
- Allow, which does not block;
- Block on pages with ads, which blocks only on pages that carry ads;
- Block, which blocks outright.
The Search and Training policies are unchanged. When a new site is onboarded, the setup flow asks whether it earns money from advertising and recommends a policy accordingly.
The second option best shows what the feature is for. When an agent reads a page for a person, nobody sees the ads, so a site that lives on advertising loses impression revenue. The same agent visiting a product page to place an order for someone is good news for that site. Blocking by page type fits what site owners actually need better than a blanket decision by identity.
What the blog post leaves out
The post does not list the supported agents, saying only that the specific options are visible in the dashboard. It also does not say which plans include these features, or which category an unrecognized agent falls into. On how agents are identified, it mentions only that Cloudflare maintains the largest directory of verified bots, without explaining what an agent has to do to get into that directory.
These gaps bear directly on how well the feature works. An agent that does not identify itself and keeps blending into ordinary traffic is out of reach of the three policy tiers. When Amazon blocked Meta's Muse in September, one of its stated reasons was exactly this: the agent did not disclose its identity while browsing.
Cloudflare says it plans to do three things next: pass user context in a privacy-preserving way, help assess reputation, and make accountability clear when something goes wrong. It has given no details or timetable.
What it means for sites in China
Sites using Cloudflare's Chinese-language dashboard can check this setting under Security Settings right away. It is safer to watch the data for a while before changing anything: content sites can start by trying “block only on pages with ads”, while e-commerce and tool sites that find agents bringing sign-ups and orders will do better to let them in.
Mobile devices in China are heading down a similar path. When ByteDance released the consumer edition of its Doubao phone assistant in September, it also published the SAEP protocol, which lets third-party apps declare whether the assistant may automate their screens. The two work at different layers, one at the network entrance and one on the device screen, but the idea is the same: the party being accessed now has a clear switch.
With switches in site owners' hands, agent vendors face a new situation in which the same assistant can do more and more different things on different sites. Who users will blame when a task fails is a question that has no answer yet.
Sources: Cloudflare official blog, CocoLoop; feature scope follows Cloudflare's announcement, and the Doubao and Amazon background comes from public reports.