Cloudflare gives site owners visibility and control over personal agents
Personal AI agents are changing the nature of the web. You don't just go to a site. You let the agent go there. It scrapes the pages and forms. Extracts stuff for you. To the site owner, it looks like automated traffic. It is. Automated traffic. But it's automated traffic on behalf of a real user who has a relationship with the site. Cloudflare has some recent blog posts on personal agents and trusted agent delegation. These are about this. How site owners can see the agent traffic. And control how they respond to it.
Here's what Cloudflare is doing. The problem. Why it's a problem. And how it impacts sites. And the choices they need to make about letting, restricting or blocking agent traffic.
The problem: agents are not humans, but they act for them
From Cloudflare's point of view, the problem is that AI agents are acting on behalf of millions of users. But to the server they look like intermediaries that obscure user visibility. When a human comes to a site, he has a browser, a session, a cookie. And some behaviours that the site can recognise and respond to. When an agent comes to a site, it has an HTTP client. It has no session context. And the request it's making might not be distinguishable from a scraper.
It's a rock and a hard place for the site owner. If they block it, they're blocking their own users. They're increasingly going to want to use agents to interact with your site. If they blindly let the traffic through, they don't have control over how their content is being consumed and indexed and re-presented. And they're open to abuse by agents that aren't acting on behalf of anyone.
The key thing is the difference between agents acting on behalf of a real user and agents acting on their own behalf. The former is a delegation. The latter is a slightly nicer looking scraper. Most sites today are getting this wrong. Treating them the same.
What Cloudflare shipped
Complementary posts 4th and 5th of November 2026.
The first post "See the agents, set the terms: New visibility and control for personal agents" gives site owners visibility over their personal agent traffic. And control over how to respond to it. The idea is that if you can know that you're seeing personal agent traffic (agents acting on behalf of a specific user) you can have different rules for it than you would for anonymous automation. You can let it through or rate limit it. Or require authentication. Or block it. Depending on what they're doing. Instead of having a crude heuristic like bot vs human.
The second post "Agents aren't humans (but they kinda are)" is about the problem space. And how we can collaborate to safely identify and let and manage automated traffic that's acting on behalf of users. It's about identification and consent. An agent that can credibly assert that it's acting on behalf of a specific user. And that user has authorised it. Should be different than one that can't.
What these are is a step towards an ecosystem where you don't just tolerate or block agent traffic. You manage it. You can make an informed choice as the site owner for every agent and every use case.
The identification problem
Identification is the basis of everything. Agent identification is very difficult.
You can identify a browser by its user agent string. Its TLS fingerprint. Its behaviour. Its cookie state. All of that is imperfect. But it's signals you can combine. An agent might present a user agent string. But it might easily change that. An agent might present a TLS fingerprint. But only if it's not trying to deliberately spoof a browser. An agent might present a token that says it's acting on behalf of a user. But only if you have a standard for such tokens. And only if you trust the issuer of the token.
What Cloudflare is doing is based on the latter. A token based assertion of delegation. And some network level signals that make it harder to spoof. It's not about identifying perfectly. That's not possible. It's about having a credible enough signal that the site owner can make a confident policy choice. And a cost structure that makes spoofing too expensive for most attackers.
It's the same problem as any other web identification problem. The solution isn't one signal. It's a stack of signals. And a cost gradient. Is the stack good enough for the choice you're making?
What site owners should actually decide
From the site owner perspective, it's not "should I let agents through?" It's "which agents? doing what? under what conditions?" That's going to be different for each site. So it's worth thinking about before the tooling is in place. Rather than afterwards.
For content sites. Do you want to have your content re-presented by agents without attribution or compensation? Today's web assumes that a visitor sees the ads and navigation and branding on your site. When an agent extracts content and re-presents it elsewhere, that's violated. Some sites will want to see the traffic. Some will want to force attribution. Or limit extraction. Or charge for API access. That's what Cloudflare is building tooling to enforce. The choices you make.
For transactional sites (commerce, banking, booking). The problem is that when an agent books a flight or makes a purchase on behalf of a user. It's a user with unusual behaviour patterns from the site's point of view. The site needs to authenticate the agent's authority. And prevent fraud. And have an audit trail. It can't block the traffic. Because it's the customer. The user. How to serve the agent without undermining the security model that protects the user?
For API first sites. They're agent ready. Because they're already expecting to have programmatic access. So it's just extend your API model you have. To include agent use. With appropriate rate limits. And terms of service. The problem is that the agents might not use the API. They might scrape the HTML. That's slower. And more expensive for everyone.
The delegation question
The deeper problem is what does it mean for an agent to be acting on behalf of a user? That's the subject of Cloudflare's "Agents aren't humans" post.
On the human web you have implicit authorisation. The user logs in. You have a session cookie that tells you who it is. You serve them. On the agent web the agent has the user's credentials or a delegated token. So the site has to decide whether or not to trust the delegation. You have a longer trust chain. And each link is a potential failure point.
If you want to make a delegation model work you need a few things. You need to be able to give and revoke the authority from the user's point of view. You need to be able to show that you have that authority as an agent. You need to be able to check that as a site without needing to contact the user for each request. And all of that needs to be cheap enough to use on each request. Without making latency go up perceptibly.
All of this is the same stuff as for OAuth. It's likely to be solved with OAuth. Delegated. And scoped. And revocable. Tokens from an identity provider that the site trusts. The nitty gritty of the token format. And the scope language. And how revocation propagates. That's where the standards work will happen. And where Cloudflare's position in the infrastructure space gives us leverage.
Conclusion: what this means for the web
The web was designed for human visitors. All the conventions (ie robots.txt and user agents and cookies and sessions and CAPTCHAs) assume there's a human on the other end of the connection. Agents break that assumption. And now the industry is building the replacements.
Cloudflare's contribution is to give site owners the tools to make informed choices about agent traffic. Not to have to make a binary choice of let or block. That's the right shape of the problem. Because it's site specific. And use case specific. It'd be wrong for most sites most of the time to have a global policy.
The danger is that the tooling just becomes a way to selectively exclude agents. And we end up with a bunch of gated APIs on the open web. That's certainly a possibility. And it's the tension that's going to drive web infrastructure over the next few years. But there's the counter balance that users want to make agents work. And sites that block them are going to lose users. There'll be pressure for access. And the tooling will define the terms.
Sources
- Cloudflare, "See the agents, set the terms: New visibility and control for personal agents" (4 Nov 2026): https://blog.cloudflare.com/personal-agents-visibility-control/
- Cloudflare, "Agents aren't humans (but they kinda are)" (5 Nov 2026): https://blog.cloudflare.com/trusted-agent-delegation/