Summary: On November 4, 2026, Cloudflare shipped two connected changes for site owners: Security Analytics now breaks out personal-agent traffic into its own category with per-agent detail, and the summer’s AI bot policies have grown into per-agent access controls. Together they let a site tell which assistant is visiting, on behalf of whom, and decide — agent by agent — whether to allow it, block it on ad-supported pages, or block it outright. For anyone running a site or an agent platform, this is the access layer agents now have to pass through.
From undifferentiated bot traffic to named agents
The problem Cloudflare describes will feel familiar if you’ve stared at a traffic dashboard lately: a personal agent that compares products, pulls support articles, or completes a purchase on a customer’s behalf shows up as automated traffic. Without knowing which agent is behind it, the safe move has been to block everything — which, as Marina Elmore and Nicole Justus point out in the announcement, can also mean losing customers who simply asked their assistant to shop on your site.
The visibility half of the launch works through two surfaces. First, the Bot Analysis chart in Security Analytics adds Personal Assistants as a category alongside Verified Bot, Likely Human, Likely Automated, and Automated, so security teams can isolate agent traffic over time. Second, a new Personal Assistants widget in Top statistics lists which agents are hitting your site and how many requests each sends. Filter on one agent and the rest of the dashboard narrows with it: the paths it requests, the status codes it gets back, the networks it comes from. In practice that means you can see whether an agent is logging in, reading product pages, reaching checkout, or repeatedly erroring on pages it can’t use.
This leans on Cloudflare’s verified bot directory — the same identification infrastructure behind its earlier bot-accountability work, which I covered in Cloudflare Verified Bots: Trust Now Depends on Behavior. The mechanism is consistent: identification first, then policy on top of it.
Tying an agent to a user account
The more interesting layer is Account Abuse Protection, currently in early access. For sites that have it enabled, owners and fraud teams can see which user each agent represents. A population overview shows which personal agents are active across your user base and how many accounts use them — a quick read on whether agent traffic is a meaningful slice of your business at all.
Every login and sign-up event now records whether a personal agent made the request, and which one. On an individual account page, the agents acting for that account are listed. The use case Cloudflare sketches is the one fraud analysts actually face: a login looks unusual, and the question is whether it came from an agent the customer has used for weeks or from one that appeared today. If an attacker does appear to be driving an agent on a specific account, the analyst can mitigate that account directly with a WAF rule on its Hashed User ID — without blocking the agent for every other customer who relies on it.
That last detail matters for anyone who has shipped a block-and-pray response to abuse. Scoped mitigation at the user level, rather than a blanket agent ban, is the difference between stopping one bad actor and cutting off a whole segment of customers.
Per-agent policies, renamed
On the control side, Cloudflare introduced AI bot policies this summer (2026) with separate choices for Search, Training, and Agent behaviors. Those Agent controls now extend to granular options for supported personal agents, and the setting is renamed AI Crawler and Agent access policies to match the broader scope.
The mechanics are simple. You set an overall Agents policy in Security Settings, then override it per supported agent with one of three options:
- Allow (do not block)
- Block on pages with ads
- Block
So the default might be Block on pages with ads site-wide, with an explicit Allow for one assistant you want to welcome everywhere. Search and Training policies stay untouched. Cloudflare also folds this into zone onboarding: when you add a new zone, it asks whether you monetize pages with ads and tailors the recommended policies to the answer.
The trade-off Cloudflare names itself, and it’s the honest one: the right policy differs by site. One publisher may allow a supported agent across its whole site so readers can find its articles; another may block that same agent on pages where ads fund the content. There’s no universally correct setting — only a setting that matches how your site makes money.
What this doesn’t solve yet
Cloudflare is upfront that agent identity is only part of the story. A site can now recognize which agent is making a request, but it still lacks what it would know about the human behind it: whether they’re an existing customer, what they actually authorized the agent to do, whether they hold a subscription, which protections should apply.
Closing that gap, per the post, requires three things that don’t exist yet in this launch: privacy-aware ways to carry user context through an agent, mechanisms for sites to assess agent reputation, and clear accountability when something goes wrong. Cloudflare says it will share more as it works with agent operators. It’s worth reading that as a roadmap rather than a promise — the sources here don’t establish how any of it will work, and there are no adoption metrics or customer examples in the announcement to gauge how much agent traffic sites are actually seeing.
What to check on your own site
If you run a site behind Cloudflare, the concrete next steps are short. Open Security Analytics and look at the Personal Assistants category — if you’re in Account Abuse Protection early access, check how many of your accounts have agents active. Then go to Security Settings → AI Crawler and Agent access policies and see whether the default policy matches how your pages monetize; the onboarding question about ads is the same question you should ask yourself now.
If you build on the other side — an agent platform — the calculus flips. Being named in that widget, and therefore being individually allowable or blockable, is the new baseline for getting through. Being absent from the supported list means you’re just automated traffic, subject to whatever blanket policy a site chose. This launch doesn’t establish how support for new agents gets decided or how quickly, so that’s the open question worth pressing Cloudflare and other agent operators on next.