Per-agent access rules and traffic visibility for personal AI assistants

The hard part of dealing with personal agents isn't deciding whether to let them in. It's knowing who they are and what they're doing once they arrive. A personal agent takes a person's instructions and turns them into requests on websites. One customer might ask it to compare products across your catalog, another to dig up a support article, and a third to finish a checkout. From your server's point of view, all three look like automated traffic. Blocking every agent is the simplest response, but it can cut off real customers who happen to be shopping through a tool. Cloudflare is betting that site owners would rather make specific decisions than blanket ones, and today's launch gives them the data and the controls to do it.

Seeing which agents show up

Cloudflare maintains what it describes as the largest verified bot directory, and that catalog now feeds directly into traffic details. The most useful change is a new category in Security Analytics. The Bot Analysis chart now separates Personal Assistants from Verified Bot, Likely Human, Likely Automated, and Automated. Security teams can isolate personal agent traffic and watch it over time, which is a different question from "is this bot good or bad?" It's closer to "is this a kind of visitor we want more of?"

The Top statistics view adds a Personal Assistants widget that lists each agent visiting your site alongside its request count. Filtering on a single agent rewires the rest of the dashboard. You see the paths it requests, the status codes it gets back, and the networks its traffic originates from. That's where the practical insight lives. An agent that's hammering product pages and reaching checkout looks very different from one that keeps hitting errors on pages it can't parse. If you've ever tried to explain a traffic spike to a product team, you'll appreciate being able to say which agent it was and what it tried to do.

Tying agent activity to accounts

For sites that use Account Abuse Protection, currently in early access, the picture gets more specific. Site owners and fraud teams can see which user each agent represents. The population overview shows which personal agents are active across your user base and how many accounts rely on them. That's useful for a basic business question: is agent traffic a rounding error or a meaningful share of your customers?

Login and sign-up events now carry a flag showing whether a personal agent made the request and which one did. Fraud teams can filter accounts by AI assistant events or by the number of assistants associated with an account. Each account overview also lists the agents acting on its behalf.

This is where the feature earns its keep. Picture an unusual login. Without context, the analyst's options are crude: trust it, challenge it, or block it. With this data, they can ask whether the request came from an agent the customer has used for weeks or from one that appeared for the first time this morning. The first is probably a customer doing their shopping. The second deserves a closer look. And if the analyst concludes an attacker is using an agent to get into an account, they can apply a WAF rule to that account's Hashed User ID. The agent stays available to everyone else who depends on it. That granularity matters, because blocking an agent platform-wide to stop one bad actor punishes every legitimate user of that agent.

Per-agent access policies

Cloudflare introduced AI bot policies over the summer, letting site owners set separate choices for AI bots used in Search, Training, and Agent behaviors. The new release extends the Agents policy to cover granular options for supported personal agents. The setting is now called AI Crawler and Agent access policies to reflect its broader scope.

In Security Settings, you set an overall Agents policy and then override it per supported personal agent with one of three options: Allow (do not block), Block on pages with ads, or Block. A typical configuration might set the default to Block on pages with ads and then explicitly allow one agent you want to welcome. Existing Search and Training policies stay untouched.

Onboarding for new zones asks whether you monetize pages with ads, and the recommended policies adjust based on the answer. You can revisit everything later in Security Settings.

The ads question is a good example of why one default won't fit everyone. A publisher whose revenue depends on page views may want an agent that reads its articles blocked on ad-supported pages, since the agent never loads the ads that fund the content. Another publisher may want the same agent to roam freely so readers can find its work through assistants. Neither is wrong. They're making different bets about where value flows, and the tool is built to let each site encode its own bet.

What identity doesn't tell you

Knowing which agent is calling is only part of what a site needs. Cloudflare is candid that the current release doesn't solve the harder problem. When a personal agent intermediates a request, the site may recognize the agent but lack the context it would normally have about the human behind it. Is this person an existing customer? What did they actually authorize the agent to do? Do they hold a subscription that should unlock certain content? Which protections should apply?

Closing that gap, according to the company, requires three things: privacy-aware ways to carry user context through an agent, mechanisms for sites to assess an agent's reputation, and clear accountability when something goes wrong. Those are open problems, and they touch agent operators, browsers, and site owners at once. Cloudflare says it will share more as it works with agent operators across the ecosystem. The stated aim is to let sites decide whether to extend greater access while keeping their direct relationship with users intact.

That last point is the one to watch. Today's tools answer "which agent, and how do I treat it?" The next question is "which person, and what do they expect from me?" Solving the second without exposing more personal data than necessary is harder, and how it gets done will shape whether agents become a normal channel into a business or a black box that sites tolerate.

Where to start

For most teams, the practical path is short. Open Security Analytics and look at the Personal Assistants category to see what's already visiting. Check which agents generate the most requests and what they're reaching. If you use Account Abuse Protection, look at how many accounts depend on agents before deciding how much weight to give them. Then set your Agents policy in Security Settings under AI Crawler and Agent access policies, with overrides for the agents you want to welcome or limit.

The person asking an agent to compare products or complete a purchase is still a customer trying to reach your business. The new tools make it possible to let that customer through without giving up control over what the agent does on your pages.