Cloudflare Agent Controls: See Which Personal Agents Visit Your Site and Set Rules for Each

Cloudflare agent controls now let site owners see which personal AI agents visit their sites and set a rule for each one. Cloudflare announced the changes on November 4, 2026. A day later it published a proposal for how sites could learn who an agent is acting for.

Personal agents are AI helpers that browse and buy for people, and they already reach donation, membership and checkout pages. This post covers what you can now see and set, which plans get what, how this differs from crawler controls, and what to decide for transaction pages. It ends with steps for WordPress and Drupal sites. Facts are as of November 8, 2026.

The short version: open Security Analytics and look for the new Personal Assistants category. Then go to Security > Settings > AI Crawler and Agent access policies and set a rule for each listed agent. For most nonprofits and associations, allowing agents on public pages is still the sensible default. Spend your time on login, renewal, donation and checkout paths.

What Cloudflare agent controls show you now

Cloudflare’s November 4 post, "See the agents, set the terms", describes three new views.

Bot analysis. In Security Analytics, the Bot Analysis chart now shows Personal Assistants as its own category. It sits next to Verified Bot, Likely Human, Likely Automated and Automated. You can select it to see only personal agent traffic over time.

A Personal Assistants widget. Under Top statistics, a new widget lists which agents visit your site and how many requests each sends. Filter on one agent and the other widgets update. You then see the paths it requests, the status codes it gets and the networks it comes from.

Account-level views. Sites using Account Abuse Protection, which is in early access, get more. Cloudflare’s November 3 changelog entry says every login and sign-up event now shows whether a recognized assistant made it, and which one. You can also see which assistants are active across your users and act on a single account.

That changelog entry also notes a limit: "Requests from assistants that Cloudflare does not recognize appear as ordinary traffic." The views cover agents Cloudflare can identify. An agent that hides behind a normal browser will not show up here.

How to set Cloudflare agent controls for each agent

Cloudflare renamed its "Configure AI bot policies" setting to AI Crawler and Agent access policies. Its documentation page for the setting lists three behaviors you can control:

• Search: crawlers that collect or index content to answer questions later.
• Agent: activity acting in real time for a person, such as chat fetch bots and browser-use agents.
• Training: crawlers taking content to train or fine-tune a model.

New this month, you can set the overall Agent policy and then choose a different action for each of the top personal agents. The actions are Allow (do not block), Block on pages with ads, and Block. Search and Training policies stay as they are.

To change them, go to Security > Settings in the Cloudflare dashboard. Filter by Bot traffic, then open AI Crawler and Agent access policies. Pick an action for each behavior and each listed agent, then save.

Two details are easy to miss. First, the docs say personal agents inherit the Agents policy, and changing that policy updates each personal agent. If you set per-agent rules and later change the overall rule, check your per-agent choices again. Second, the docs state: "Cloudflare recommends Allow (do not block) for Personal Agents." For new domains, Search, Agents and Training all default to Allow.

Cloudflare agent controls by plan, as of November 2026

Cloudflare’s posts do not give a plan table for the new agent features. This is what its own pages say.

The Security Analytics docs say zone analytics come with every plan, but statistics and filters vary by plan. Check your own dashboard to see whether the new widget appears on your plan.

How Cloudflare agent controls differ from crawler controls

Crawlers and personal agents are different traffic, and Cloudflare now treats them that way. A crawler collects pages to index or train on later. A personal agent visits a page right now because a person asked it to.

Crawler controls lean on robots.txt and on Cloudflare’s verified bot directory. We covered that side in our posts on BotBase and Bot Preference Sync and the AI crawler default change. Cloudflare’s docs note that robots.txt directives are voluntary. Its Disallow action applies to Training only.

Personal agents need different handling. A person who sends an agent to renew a membership is still your member. Blocking the agent can block a sale or a gift. Our post on AI shopping agents being blocked walked through that tradeoff for nonprofits in October.

So keep two questions apart. Which crawlers may copy your content? And which agents may act on your site for people? The Cloudflare agent controls answer the second question, per agent.

The November 5 proposal: trusted agent delegation

Cloudflare’s November 5 post, "Agents aren’t humans (but they kinda are)", looks past identifying the agent. It asks how a site can know the person behind it. The post names Muse from Meta and dots from OpenAI as examples. We explained both in What Is Meta Muse? and What Are ChatGPT Dots?.

The core idea is what Cloudflare calls the Intermediation Principle. The business relationship between a user and a site, and each side’s security duties, "must be upheld regardless of intermediation." In plain terms, an agent in the middle should not erase who the customer is.

The post lists problems sites face today. Three matter most for our readers:

• Friendly fraud. A person approves an agent’s purchase, then disputes it. The site lacks the usual device and address evidence.
• Traffic commingling. One user abuses a shared agent, and blocking the agent blocks every other user too.
• Account sharing. One paid account serves many people through one agent.

Cloudflare names Web Bot Auth as its preferred way for an agent to sign requests and identify itself. It also points to MOLE, a privacy-preserving way to rate limit without user identifiers. It describes identity as a spectrum, from no identifier to session, account or unique ID.

This is a proposal, not a standard. Cloudflare announced a Trusted Agent Delegation coalition and says it plans side meetings at the IETF. It says the IETF’s AI Preferences working group focuses on preferences about use, and no group yet covers what agents may do on a site. Nothing here changes your Cloudflare agent controls today.

What to decide for donation, membership and checkout flows

Use the widget to see which agents reach these paths, then decide page type by page type.

Donation forms. Card testing is a real risk on donation pages, and the challenges that stop it may also stop agents. Cloudflare’s November 5 post explains why agent purchases are harder to defend in a dispute. Decide whether agents may complete a gift, and test what your processor sees.

Membership login and renewal. Account sharing and shared-agent abuse land here. If you have Account Abuse Protection, use it to see which agents log in for which members. Otherwise, watch login paths in the widget.

Checkout and event registration. Check quantity limits, member pricing and receipts. Make sure confirmation emails go to the person, not the agent.

Public content. Allow by default unless you run ads and have a reason to protect ad pages. Block on pages with ads exists for that case.

The policy actions apply across the zone or on pages with ads. Cloudflare’s docs describe Block as blocking matching requests "across the zone." If you need one rule for articles and another for /donate, that takes a WAF custom rule. Our agentic browser security post covers the risks from the agent’s side.

What WordPress and Drupal sites behind Cloudflare should do

Most of the work with Cloudflare agent controls happens in the dashboard, not in the CMS. A few site-level checks still apply.

1. Confirm who controls the zone. Many managed hosts run Cloudflare for you. Our post on Pantheon’s Global CDN on Cloudflare is one example. Ask your host whether you can see Security Analytics and change the agent policies.

2. Filter the widget by your login and transaction paths. On WordPress that usually means /wp-login.php and the pages your donation or store plugin uses for checkout. On Drupal it means /user/login, Webform donation pages and Commerce checkout.

3. Check plugin and module bot rules. Security plugins, form spam tools and rate limiting modules can block agents on their own. Your Cloudflare setting will not override them.

4. Look at errors. The widget shows status codes per agent. A run of 403 or 429 responses on a form means something is blocking agents, on purpose or not.

See our Drupal 10 end-of-life guide and our plain-language Webform vulnerability brief. For search and training bots, our AI crawler access audit still applies.

Frequently Asked Questions