Cloudflare adds per-agent website access controls Cloudflare adds per-agent website access controls

Requests become attributable traffic

Security Analytics adds a Personal Assistants category and a widget showing agent request counts. Selecting an assistant filters paths, response codes and networks across the other widgets. Account Abuse Protection adds agent attribution to login and signup events and individual account views. Cloudflare says an analyst can mitigate a suspicious account through its hashed user identifier, without blocking the same agent for everyone. Existing Search and Training policies remain separate from the expanded Agents setting.

Overrides can change with the parent policy

The policy guide says individual personal agents inherit the overall Agents policy. Changing that parent setting updates each personal agent, after which an owner can choose individual actions again. An exception therefore needs checking after a broader policy change. Policies cover verified bots with the relevant behavior and matching unverified bots. Blocking on advertising pages depends on Cloudflare detecting ads, rather than a blanket restriction across the zone. For new domains, Search, Agent and Training currently default to Allow. Owners can change those defaults after onboarding. Allow means these policies do not block matching requests. We would not treat that setting as a blanket exception to other security checks.

Account attribution has prerequisites

The existing Account Abuse Protection documentation limits early access to Enterprise Bot Management customers, who must request it through their account team. User ID is opt-in. It produces an opaque identifier scoped to a zone, and other Cloudflare customers cannot access that zone’s profiles. Detection also depends on recognizing the application’s login and signup traffic. Nonstandard endpoints may need explicit labels; the guide gives cf-log-in as the login label. Profiles can aggregate locations, devices, browsers and event types to help an analyst investigate an account.

A verified operator is not every user

Cloudflare’s bot documentation distinguishes direct operators from intermediary services used by many people. Verification checks honest identification and non-abusive behavior. Identification can use a cryptographic Web Bot Auth signature, a published IP list with a stable user agent, or reverse DNS. An intermediary’s operator and the person directing a request are different parties. Trust in the operator does not establish trust in every user. The documentation describes forwarding end-user context as experimental. Its newer behavior classifications also are not individual WAF custom-rule fields; existing categories remain available for those rules. Verified status can be revoked for policy violations; repeated misconduct can cost an organization verification for all its bots and agents.