Cloudflare now names the supported personal AI agents that visit your site

A customer may now arrive through software

A shopper asks an assistant to compare products on your site. Another asks it to find a support article. A third tells it to complete a purchase. Cloudflare says that to a site owner all three show up as the same thing: automated traffic.

That is the shift worth noticing. A customer may now be acting through a piece of software. The source gives no figure for how common this is. The visitor is still your customer. The thing you can see is the agent.

Cloudflare announced new tools on November 4 to deal with this. They are one vendor's answer, and they only cover the agents Cloudflare supports. They still show where the problem sits.

What Cloudflare now shows you

In Security Analytics, the Bot Analysis chart gains a category called Personal Assistants. It joins the existing groups, including Verified Bot and Likely Human. Selecting it isolates personal agent traffic, so a security team can follow its volume over time.

A new Personal Assistants widget in Top statistics names each visiting agent and counts its requests. Cloudflare says the feature draws on its verified bot directory, which it calls the largest in the world. Pick one agent and the other widgets narrow to that agent alone. They show which paths it asks for, which status codes come back and which networks it uses.

In practice, you can tell whether an agent is logging in, reading product pages or reaching checkout. You can also see whether it keeps hitting errors on pages it cannot use. We read those errors as possible lost sales. Cloudflare does not say so itself.

Sites using Account Abuse Protection, which is in early access, get a deeper view. Cloudflare says owners and fraud teams can see which user each agent represents. Login and sign-up events are tagged with the agent behind them, if there was one. Each user's account page lists the agents acting for that account.

Cloudflare describes what this means for a fraud analyst. A login from an agent the customer has used for weeks looks different from one by an agent that appeared today. If an attacker seems to be using an agent on an account, the team can act on that account alone. Cloudflare says this is done with a WAF rule on the account's Hashed User ID. Other people who rely on the same agent are not blocked.

Rules for each agent, not one rule for all

This summer Cloudflare introduced separate AI bot policies for Search, Training and Agent behaviour. It has now widened the Agents policy to cover individual supported personal agents. The setting is renamed AI Crawler and Agent access policies.

You set one overall Agents policy. Then each supported agent can get its own choice from three: allow it, block it only on pages that carry ads, or block it fully. Cloudflare does not say how it detects which pages carry ads. Its example sets the overall policy to block on ad pages and makes an exception for one agent you want to welcome. The Search and Training policies are untouched.

Cloudflare also asks new customers whether they monetise pages with ads, and tailors its recommended policies to the answer. It gives two examples of valid choices. One publisher may allow an agent across its site so readers find its articles. Another may block the same agent where ads pay for the content.

Seeing the agent is not knowing the customer

Here is the lesson we draw. Naming the agent is progress, but a name alone does not carry the customer's story. A site that recognises an agent may still not know whether the person behind it is a subscriber or a first-time visitor.

Cloudflare names the limit itself. Recognising which agent sent a request is one thing. Holding the background a site would normally have on the person is another. The company lists what can go missing: whether the person is an existing customer, what they allowed the agent to do, whether they subscribe, and which protections apply.

Cloudflare names its next goal as preserving that context. It lists three needs: carrying user context through an agent, helping sites assess reputation, and setting clear accountability when something goes wrong. It says these will need privacy-aware methods. It says it will share more, but it gives no details or dates for any of them.

Until then, the new tools are a way to look and to set terms. They do not replace the customer relationship that an intermediary can hide. Blocking agents outright can look like the safe choice. Cloudflare warns it can mean losing customers.

Questions to put to your team

First, do we know which personal agents already reach our login, product and checkout pages? If we use Cloudflare, the Personal Assistants widget answers this for the agents it supports.

Second, are agents hitting errors on pages they cannot use? If so, that may be demand we are turning away without noticing.

Third, should one rule cover every agent, or should each get its own? Ask which agents deserve full access and which should be limited on pages that carry ads.

Fourth, can our fraud team tell a long-standing agent from a new one on a single account? Ask whether they can act on one account without blocking an agent for everyone.

Last, who owns the answer when an agent acts for a customer and something goes wrong? Cloudflare lists accountability as unfinished work. Your own contracts and policies should not wait for it.

The visitor has not left. They have sent someone ahead, and your job is to decide on what terms that someone comes in.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cloudflare.