Can websites allow one personal AI agent while blocking another? Cloudflare now gives owners that choice
Cloudflare has added analytics for recognized personal-agent traffic and per-agent Allow, Block or Block-on-ad-pages settings. The controls are concrete, but the company reports no independent accuracy, adoption or user-outcome evidence, and unrecognized agents remain ordinary traffic.
The short version
- What happened
- Cloudflare says site owners can now see recognized personal-assistant traffic in Security Analytics, inspect requested paths and status codes, and override the overall Agents policy for each supported agent.
- Who it affects
- People who use assistants for accessibility, comparison or support may gain from selective access, but a block can also remove a legitimate route to a service.
- What remains unproven
- All evidence for the launch comes from Cloudflare; no independent identification test, adoption denominator or user-outcome study was published.
Keep in mind
All evidence for the launch comes from Cloudflare; no independent identification test, adoption denominator or user-outcome study was published.
Only supported and recognized agents receive the category and policy treatment; unrecognized assistants appear as ordinary traffic.
Account-level visibility is early access and limited to login and sign-up events in the current documentation.
Allowing or blocking an agent does not establish copyright permission, user authorization, task success or accountability for a mistaken action.
Multi-source analysis · 3 linked sources. Primary analysed source date: 4 November 2026. Earliest linked supporting source: 2 November 2026.
Keep following the evidence
Join The Impact Brief founding list for selected AI reports, their effect on people and the evidence limits. Read a sample first.
Read the full report · 10 min The evidence, methods, implications and limitations
The direct answer: yes for recognized agents on Cloudflare, with important limits
Cloudflare now lets a website operator apply a different access decision to each supported personal AI agent instead of treating all agent traffic the same. The owner sets an overall Agents policy, then can override it for a recognized agent with one of three actions: Allow, Block or Block on pages where Cloudflare detects advertising. The same launch adds a Personal Assistants category in Security Analytics so operators can inspect request volume, paths, status codes and source networks. Search crawlers and model-training crawlers remain separate policy categories.
This is a material change in web infrastructure because personal agents increasingly sit between a person and a site. Someone may ask an agent to compare products, retrieve support information or complete a purchase. A blanket block can stop abusive automation, but it can also stop a legitimate customer using an assistant. Per-agent control creates a more precise choice. It does not establish that Cloudflare always identifies the right actor, that supported agents faithfully represent user permission or that allowing them improves business or access outcomes. The evidence is a shipped control described by its provider, not an independent evaluation.[1][2]
What a site owner can see now
In Security Analytics, Cloudflare says the Bot Analysis chart now includes Personal Assistants alongside Verified Bot, Likely Human, Likely Automated and Automated. A site team can filter to personal-agent traffic over time. A new widget lists recognized agents and the number of requests each sends; selecting one updates the rest of the view to show which paths it requested, which status codes it received and which networks carried the requests. That can reveal whether an agent reaches product pages, checkout, login or error routes.
Request counts are not people, customers or successful tasks. One agent action may generate many requests, and a successful HTTP status does not show that the person obtained a correct answer or completed a purchase. Cloudflare provides no denominator for how much of its network traffic is classified as personal-agent activity, no false-positive or false-negative rate and no independent comparison with server logs or cryptographic agent identity. Operators should use the view as an observability signal and validate important decisions against their own logs, application events and user support reports.[1]
The distinction that matters
What Cloudflare’s new personal-agent controls do
The controls apply to traffic Cloudflare recognizes as a supported personal agent. They do not prove user authorization or identify every automated request.
Allow
Do not block matching agent requests
Site still needs authentication and transaction controls
Block
Reject matching requests across the zone
May also block legitimate customers using that assistant
Block on pages with ads
Reject on Cloudflare-detected ad pages
Aims to protect direct ad-supported visits
Analytics
Show recognized agents, paths and status codes
Counts requests, not people or successful tasks
Account view
Label recognized login and sign-up events
Early access; unrecognized agents look like ordinary traffic
The three access actions solve different problems
Allow means Cloudflare does not block matching requests through this policy. Block rejects matching agent traffic across the zone. Block on pages with ads aims to preserve direct page visits where advertising supports the publisher while allowing the agent elsewhere. Personal agents inherit the site’s overall Agents setting by default, and changing that overall setting updates the individual agents until the owner chooses overrides again. The documentation says new domains default to Allow for Search, Agents and Training, although earlier onboarding recommendations and managed settings can depend on configuration.
These actions are not equivalent to a contractual licence or a statement about copyright. They are technical edge controls over requests Cloudflare classifies as matching traffic. The Training category also offers a Disallow action that expresses a robots.txt preference; robots directives are voluntary unless paired with Cloudflare’s blocking option. For personal agents, the practical question is more immediate: may this identified intermediary fetch or act on the site now? A block can reduce access for people who rely on an assistant, while an allow decision may expose workflows that were designed only for humans. Operators need route-level testing, authentication controls and transaction safeguards in addition to the bot policy.[1][2]
Recognized identity is useful, but it does not carry the person’s authorization
Cloudflare explicitly says agent identity is only part of the problem. A site may recognize the intermediary but still not know which customer it represents, what that person authorized, whether the person holds a subscription or who is accountable if the action is wrong. Those questions matter most when an agent moves beyond reading public pages to logging in, changing data or buying something. The launch does not create a universal delegation credential or proof that a particular request matches the user’s current intent.
Cloudflare’s Account Abuse Protection, currently described as early access, adds a narrower account view. Login and sign-up events can show which recognized assistant acted and which account it represented; analysts can filter accounts and mitigate one account rather than blocking an assistant for everyone. The changelog limits that visibility to login and sign-up events. Requests from assistants Cloudflare does not recognize appear as ordinary traffic. That means absence of an assistant label is not proof that a human made the request, and the feature should not replace strong authentication, step-up checks or transaction confirmation.[1][3]
Who is supported and why that list needs careful reading
Cloudflare’s public API schema exposes individual policy fields for OpenAI, Anthropic and Google agents as well as labels called Instinct and Muse. The dashboard description uses the broader phrase ‘top Personal Agents’ rather than promising that every assistant, browser agent or custom automation can be identified. The supported set can change as providers adopt verifiable identity and as Cloudflare updates its bot directory. A site owner should inspect the current dashboard and documentation rather than assume a consumer brand, model or user-agent string maps cleanly to one policy field.
Recognition also depends on traffic behaving in ways Cloudflare can classify. An agent running through a person’s ordinary browser session, a corporate proxy or an unregistered automation may not look like a known agent. Conversely, bot classification systems can make mistakes. Cloudflare says it maintains a large verified-bot directory, but this announcement does not publish validation data for the personal-agent category. High-consequence routes should therefore use application-layer authorization and audit trails. Network classification can support a decision; it should not be the only evidence that an instruction came from an authorized person.[1][2]
What changes for publishers, shops and people who use assistants
Publishers can choose to welcome a personal agent on subscription or support pages while blocking it where advertising funds the content. Retailers can observe whether agents reach product and checkout routes before deciding which workflows to expose. Support teams can see error patterns that may show an agent cannot navigate a form. These are practical operational uses, but none is an outcome demonstrated by the launch. Cloudflare does not report whether the controls increase direct visits, reduce scraping, lower fraud or improve completed transactions.
For people, the trade-off is not abstract. Personal agents may assist someone with a disability, limited time or a complex comparison task. Blocking a recognized agent can remove that route even when the person is a paying customer. Allowing it may create privacy or transaction risks if the site cannot verify the scope of delegation. Good policy should distinguish public reading, authenticated retrieval and irreversible action. Sites should give users a clear human fallback and explain when an assistant is unsupported instead of silently failing or assuming that all automation is hostile.[1][2]
The launch leaves measurement and governance questions unanswered
Cloudflare is both the source and the vendor. Its pages explain the feature precisely enough to verify the controls, but they do not provide independent accuracy testing, the number of supported sites, the share of agent traffic recognized or the consequences of each policy. There is no reported experiment comparing blanket blocking with selective access, no false-block rate for legitimate users and no measurement of whether ad-page detection matches a publisher’s business model. Those are evidence gaps, not evidence that the feature fails.
Governance also extends beyond a toggle. A site needs owners for policy changes, a log of who changed them, review dates and monitoring for unexpected shifts. Security teams should coordinate with accessibility, commerce, editorial, privacy and customer-support teams because a rule that reduces automated risk may also block a service people rely on. If an agent can take actions, the site should separate read access from write access, require fresh confirmation for high-impact steps and retain enough evidence to investigate disputes without collecting more personal data than necessary.[1][2][3]
What would change the assessment
The assessment would strengthen with published identification performance across real traffic, independent tests of the allow and block actions, and measured outcomes for publishers and users. Useful denominators would include the number of recognized agent requests, sites using overrides, legitimate tasks blocked, abusive requests stopped and user journeys completed. Research should also test whether people understand when an assistant is acting for them and whether sites can carry consent and subscription context without exposing unnecessary identity data.
It would weaken if unrecognized agents routinely bypass the controls, if known agents are misclassified, if ad-page blocking harms accessibility or if operators treat the label as authorization for sensitive action. Today’s change is consequential because it turns a coarse web-policy choice into a per-agent control available through a major infrastructure provider. It is not Breaking: no urgent incident, binding rule or immediate public-safety threat has been reported. The responsible interpretation is specific—Cloudflare customers have a new control surface, while its real-world effects remain to be measured.[1][2][3]
Watch the background, then check the evidence
Illustrative photo · not a video frame
The Royal Society · 44 min 28 sec · Background explainer
Is this the AI future we want? | The Royal Society
YouTube loads only when you choose; playback starts when you press play.
A Royal Society discussion with Madhumita Murgia and biomedical engineer Alison Noble on AI’s potential in healthcare, science and culture, recorded at the 30 June 2026 event.
Evidence check: A discussion of opportunities and risks, including future possibilities. It is not evidence that every application described is available or clinically proven.
Published 2026-07-01. Source checked 14 October 2026. Check captions on the publisher’s video page.
Check the healthcare evidencePhoto: Daniel Sone / National Cancer Institute / Unsplash · Licence
Continue the story
Read next
Continue exploring web access: compare the finding and its evidence limits.
Can shopping agents verify the total and refund terms on merchant sites?
A company-authored pilot found many merchant pages readable but too incomplete for a hard-budget agent to decide safely. The benchmark is unvalidated, commercially interested and does not measure completed transactions or disputes.
Read the next reportExplore the full source and evidence record
What this means for people
- People who use assistants for accessibility, comparison or support may gain from selective access, but a block can also remove a legitimate route to a service.
- Publishers and shops can make per-agent choices instead of one blanket rule, but request analytics do not show whether a person completed a task or consented to an action.
- Security teams should treat agent identity as one signal and keep application-level authorization, step-up checks and human fallbacks for consequential actions.
Global context
The control is available through a global web-infrastructure provider, but agent identity, privacy, advertising and accessibility rules differ across jurisdictions. A publisher’s business model and a user’s reliance on an assistant also vary. Selective edge policy may become one layer of a broader delegation system, yet global interoperability will require shared identity, consent and accountability standards rather than provider-specific labels alone.
What the evidence does not yet show
- All evidence for the launch comes from Cloudflare; no independent identification test, adoption denominator or user-outcome study was published.
- Only supported and recognized agents receive the category and policy treatment; unrecognized assistants appear as ordinary traffic.
- Account-level visibility is early access and limited to login and sign-up events in the current documentation.
- Allowing or blocking an agent does not establish copyright permission, user authorization, task success or accountability for a mistaken action.
What to watch next
- Independent measurements of recognized-agent precision, recall and bypass rates.
- Published adoption and outcome data for publishers, retailers, accessibility users and fraud teams.
- Standards that carry user authorization and subscription context without exposing unnecessary personal data.
- Whether supported-agent lists and per-agent controls remain available across plan levels and regions.
Living evidence record
Impact record IAI-0N5XDQE
Evidence stage
Announced
Confidence
Supported
Reporting basis
Multi-source analysis
Independent or research support
Not yet
Record status
Monitoring
Last checked
4 November 2026
Source trail
3 direct sources across 2 source types.
People impact
Documented in this record.
Uncertainty
Limits and next checks are explicit.
Stages describe the evidence available—not whether a technology is good or bad. See the public method.
Evidence trail
Sources used for this report
Links checked 4 November 2026
Research question, topics and regions
Topics: Personal agents · Web access · Publishers · Bot management · Online commerce · Advertising · Account security
Regions: United States · North America · Global
This report is labelled multi-source analysis. We summarise and analyse source material in our own words; company statements remain attributed claims until independently supported. Translated summaries preserve the meaning of the original source and link back to it. Read our editorial standards.
Reader commentary
What does this mean where you are?
Tell us what you have seen at work, in your community or in everyday life. A question is welcome too. No account is needed; we review notes before publishing them.
Explore commentary across the portal →Published reader notes
0No published reader notes yet. You can start the evidence-led discussion above.
Prefer a private correction or response? Contact the newsroom.