Cloudflare Personal Agent Policies: How to Allow, Limit or Block AI Assistants on Your Site

Cloudflare's newest bot controls exist to get site owners out of one specific trap. As Cloudflare explains in its Trusted Agent Delegation post, when one user abuses a shared agent for credential stuffing, scraping or card testing, the site can detect the abuse but can only block the agent, which also blocks all of its legitimate users. With more customers sending AI assistants to browse, compare and buy for them, that is an expensive choice to be forced into.

The new controls let you choose a different policy for each supported personal agent instead of settling for an all-or-nothing block. Below I cover how they work, a rollout model you can reuse, and where the evidence is still thin.

Why personal agents need their own policy

Crawlers and agents can look alike in your logs, but they raise different questions. A training crawler collects content to build a model. A search crawler indexes pages to surface them later.

With crawlers, you ask whether you want your content used. With personal agents, you ask whether you want to serve a customer who chose to send software in their place. The crawler side has its own set of decisions, covered in our Cloudflare crawler migration map for search teams.

Hold the volume argument loosely. Cloudflare argues that agentic traffic is growing rapidly and may eclipse traditional human browsing in the near future. In September, Cloudflare CEO Matthew Prince forecast that bot traffic would reach 1,000 times human traffic within five years. Those are forecasts from a company that sells tools for managing this traffic. They are not measurements.

The more useful idea is what Cloudflare calls the Intermediation Principle: the business relationship between users and sites, and each participant's security responsibilities, must be upheld regardless of intermediation. Your customer is still your customer when an assistant does the clicking. Much of this release is an attempt to make that principle workable.

Scale is the reason to pay attention even if you don't run on Cloudflare. The company says more than 20% of web domains sit behind its network, so the defaults and categories it sets shape how a large share of the web treats agents.

What changed in the access policies

Configuration lives in Security Settings. As Cloudflare's personal agents announcement explains, you set an overall Agents policy, then choose a different policy for each supported personal agent. Each agent gets one of these actions:

• Allow (do not block): matching traffic passes through. I'll call this Allow from here on.
• Block on pages with ads: the agent is stopped on ad-bearing pages but can still reach the rest of the site.
• Block: matching traffic is blocked across the whole site.

For context, the underlying Account Abuse Protection dashboard was introduced on October 2, 2026.

How inheritance works

This is where teams get caught out. According to Cloudflare's access policy documentation, personal agents inherit the Agents policy by default, and changing the Agents policy updates each personal agent. You can set individual actions again afterwards, but your per-agent overrides will not survive an edit to the parent.

Cloudflare recommends Allow for personal agents. For most businesses that is the right default, for reasons the decision matrix below explains.

Reading the Personal Assistants category

In Security Analytics, the Bot Analysis chart now shows Personal Assistants as a new category, next to Verified Bot, Likely Human, Likely Automated and Automated. Open this view before you touch any policy. Check how much recognised assistant traffic you get and whether it is steady or spikes around particular events. Most of all, check which paths it hits.

Paths decide the policy. An assistant reading ad-supported articles is a revenue question. One hitting login and checkout is a fraud and conversion question. The same volume can justify very different settings depending on where it lands.

One limitation applies from day one. Cloudflare's documentation states that requests from assistants it does not recognise appear as ordinary traffic. Treat the category as a floor, not a full count.

Account-level control with Hashed User ID

This is the part of the release that goes straight at the shared-agent trap. If it looks like an attacker is using an agent on an account, fraud analysts can mitigate that account with a WAF rule on its Hashed User ID, without blocking the agent for everyone else who relies on it. Independent coverage from Unite.AI describes the same mechanism: the rule targets the account's Hashed User ID rather than the agent as a whole.

There are two actions. Managed Challenge adds friction, while Block stops the account's requests outright. Cloudflare's Account Abuse Protection documentation says only the targeted account is affected, including when it uses an AI assistant that other users rely on.

The dashboard also surfaces credential signals. In Cloudflare's own dashboard example, approximately 2.4K events produced a leaked username or password result, compared with 11.7K events where credentials were classified as clean. That shows you what the view looks like. It is not a benchmark for your own traffic.

Plan around two constraints. First, Account Abuse Protection is in Early Access for Bot Management Enterprise customers, at no additional cost for a limited period until it becomes generally available. Budget as if pricing will change. Second, Cloudflare's documentation limits AI assistant visibility to login and sign-up events, so abuse elsewhere in a session will not be attributed to an assistant through this feature.

Decision matrix by business model

The right setting depends on how your site makes money. Treat the positions below as inputs to the Override step of the playbook further down. They are starting points. If your own baseline says otherwise, follow your data.

Ad-funded publishers

When an assistant reads your article and summarises it for its user, that visit may earn no ad revenue. Cloudflare has leaned this way itself. Its July 2026 announcement said that for all new domains onboarding to Cloudflare, the Training and Agent categories would be blocked by default on pages that display ads, while Search would remain allowed. Current documentation describes different defaults, which I come back to below, so check your own zones.

SaaS

For a SaaS product, an agent that logs in is most likely a paying customer automating their own work. Blocking agents wholesale risks broken workflows and a wave of support tickets. The recommended Allow setting fits this model. When abuse shows up, act on the Hashed User ID rather than the whole agent.

Ecommerce

Agents already reach checkout. Microsoft Clarity data showed checkout appearing in 25% of AI agent sessions versus 15% for humans. Block an agent and you may be blocking buyers.

Blanket blocks do happen. In early October, Meta's Muse accounted for 72% of AI agent requests in HUMAN's data, and Amazon blocked Muse from shopping on its site. We suggest treating any single blanket block as one business's decision, not a template for yours.

The fraud exposure is real too. Arkose Labs reported that 65.2% of its customers saw AI agents reach login, registration and checkout flows. That is a share of Arkose customers, not of sessions. We suggest reading it as directional rather than as a benchmark for your own site. It still argues for pairing Allow with active account monitoring instead of treating the decision as open versus closed.

Mixed content and commerce

Plenty of sites run ad-supported articles alongside checkout, a members area or a logged-in product. One site-wide action rarely suits them. A reasonable start is to keep the overall Agents policy at Allow, so agents can reach login, account and checkout pages, and apply Block on pages with ads only to the agents whose baseline shows heavy reading of ad pages. That action follows the ads, not the site section. Confirm your commerce and logged-in pages carry no ads, or the block will reach them as well. Split ownership along the same line: the content or revenue team owns ad-page overrides, and the fraud team owns account-level responses.

Summary table

Playbook: Baseline-Inherit-Override-Contain-Review

We suggest running this as a five-step loop. Each step produces one concrete output, so you know when it is finished and where to pick up at the next review.

Step 1: Baseline

Review Personal Assistants traffic in Bot Analysis over a period long enough to cover normal weekly cycles and any promotions. Group the pages assistants touch into ad pages, login and sign-up, product pages and checkout. Output: a saved Bot Analysis view and the top paths per agent.

Step 2: Inherit

Set the overall Agents policy first, since every personal agent inherits it. Record it as line one of an override log, with the date and the approver. Treat any later edit as a change request, and capture the current per-agent settings before anyone touches it, because the edit resets them. Output: a logged parent policy and an agreement that it changes only through review.

Step 3: Override

Start every agent at Allow. Move one to Block on pages with ads or Block only when a log entry justifies it. Here is an illustrative template, not a real client record:

Output: one entry per override. Anything without an entry goes back to the parent policy at the next review.

Step 4: Contain

If you have Bot Management Enterprise, enable Account Abuse Protection and draft WAF rules that target a Hashed User ID. Begin with Managed Challenge and escalate to Block only when the evidence supports it. Write the escalation like an AI agent kill switch runbook, with clear triggers and owners, so the on-call analyst isn't improvising. Log each account rule the way you log an override: account reference, action, trigger, owner and expiry date. Output: a written escalation path and a rule log.

Step 5: Review

Review monthly or quarterly, depending on traffic. Check defaults on newly added domains, reapply logged overrides after any parent change, expire account rules you no longer need, and revisit settings after major agent launches. Then go back to Step 1 with a fresh baseline.

Ownership is what keeps the loop honest. Marketing or revenue teams should own ad-page decisions, because they can weigh visits against income. Security or fraud teams should own account-level actions, because they hold the evidence.

Common mistakes

Treating Allow as identity. As Forkast notes, an agent policy controls whether matching traffic is allowed, but it does not by itself establish user account identity or who authorised the specific action. Your normal authentication still applies, whether that means passwords with MFA or a passkey rollout with solid recovery.

Assuming signatures verify the human. A Web Bot Auth signature authenticates the agent or bot identity. It tells you nothing about the person behind it.

Blocking a shared agent to stop one abuser. That cuts off every legitimate user of the agent. Use account-level mitigation where you can.

Forgetting inheritance. Edit the parent Agents policy and every per-agent choice needs reapplying.

Reading a small Personal Assistants number as low agent traffic. Unrecognised assistants show up as ordinary traffic, so a small category can hide a bigger picture.

Caveats and limits

The visibility gap. Only assistants Cloudflare recognises get labelled and per-agent control. Your policy covers the agents Cloudflare can identify, not every automated assistant.

Conflicting sources on defaults. The July 2026 blog said new domains would block Training and Agent on ad pages by default. Current documentation says that for new domains, Search, Agents and Training use Allow by default. When the two disagree, trust your dashboard.

Detection limits. In Resemble AI's own test, bot tools caught between 3.1% and 14.8% of disguised AI agents. It is a vendor figure with no published sample size, but the direction is clear: agents built to look human are hard to spot.

The identity gap. Arkose Labs found that 97.7% of legitimate AI agent sessions carried no verified ID between July 1 and September 30. We suggest planning on the assumption that legitimate agent traffic may reach you without any verified identity attached.

Early standards. The Trusted Agent Delegation post refers to a coalition working on agent delegation but does not name a single member, and the coalition's own website does not either. That website says the open standards are being developed in the IETF and the W3C. Expect the mechanics to change as that work matures.

Unlinked figures. Several third-party figures and quotations in this article are attributed but not linked to their original publications. Check methodology and dates at the source before reusing them. The traffic forecasts also come from Cloudflare itself, so use them for direction, not capacity planning.