Cloudflare and World announced a Trusted Agent Delegation (TAD) coalition in November 2026. What is it, what problem with personal AI agents is it meant to fix for websites, and what can a site actually do about agent traffic today while it's still being worked out?

What should I check, step by step?

1. Find out which personal agents already reach you. Group requests by declared agent and, where present, by Web Bot Auth signer (the Signature-Agent URL), and look at which paths they hit: product pages, login, cart, checkout, support.

2. Decide per agent and per area, not one switch for all automation. Reading product pages, logging in and buying carry different risks; Cloudflare's per-agent policy has Allow, Block on pages with ads and Block.
3. Prefer cryptographic identity over the user-agent string. Cloudflare notes attackers copy a well-known agent's user agent to get the same allowances; a verified Web Bot Auth signature tells you which operator signed the request.
4. Plan for one agent serving many users. When one user abuses a shared agent, act on that user's account or session rather than the agent, or you cut off every other customer using it.
5. Keep your own record of what each agent did on each account: the agent and signer, the account, the action, the time and what the user had authorized. That's what you'll have when a purchase made through an agent is disputed.
6. Don't count a CAPTCHA handed to the user as accountability. Cloudflare's post says it proves a human was present at that moment and nothing about who the agent acts for the rest of the time.
7. Treat TAD as a direction to follow, not a spec to build against yet. Watch the Web Bot Auth, AIPREF, OAuth and WIMSE work at the IETF, where the coalition says it will bring specific problems.

What is Trusted Agent Delegation (TAD) from Cloudflare and World?

TAD was previewed at Cloudflare Connect and announced by World on November 12, 2026 as a coalition to help personal AI agents reach more services under conditions those services can trust. Cloudflare describes its goal as bringing representatives across the ecosystem together to examine existing protocols and take well-defined problems to the IETF, with side meetings and workshops planned. Its site, trustedagentdelegation.org, says users should be able to share only what an interaction requires, without enabling tracking across sites.

• The scope is agents hosted by an operator, such as an agent running a cloud browser for many users. On-device and locally run agents are explicitly out of the initial scope, because there's no single operator to build reputation with or hold to account.
• In TAD's framing, "trusted" means a website trusts an agent enough to let it in. When an agent misbehaves, the aim is that the site can hold the user associated with it to account, by refusing that user service or reporting them to the agent's operator, instead of blocking the agent outright.

Why can't a website tell which user is behind a personal AI agent?

Cloudflare's post lists fourteen problems that agents create for sites and says the site bears the primary cost in nearly all of them. Examples: friendly fraud, where a user approves an agent's purchase and later disputes it, and the usual evidence (same device, IP and address as past purchases) doesn't exist; traffic commingling, where credential stuffing or card testing through a shared agent can only be stopped by blocking the agent for all its users; identity spoofing, where attackers copy a known agent's user agent; and resource exhaustion from constant stock and price polling.

• It also explains why common fixes fall short. Handing a CAPTCHA to the user shows a human was there once and adds friction operators will try to remove. Narrow permission scopes tell the site what the agent may do but not who answers when it gets something wrong.
• Its proposed identity spectrum runs from nothing, to a session identifier, to an account identifier that persists across sessions with one operator, to a unique per-user identifier from a third party for high-risk actions. Privacy-preserving tools such as Privacy Pass and the planned MoLE are meant to answer "can we trust you?" without "who are you?" where that's enough.

How can a website see and control personal AI agent traffic today?

Cloudflare's November 4, 2026 release adds Personal Assistants as a traffic category in Security Analytics, a widget listing which agents visit, how many requests each sends, the paths they request and the errors they hit, and a renamed AI Crawler and Agent access policies setting where you can set an overall Agents policy and override it per supported personal agent.

• For sites in Account Abuse Protection's early access, every login and sign-up shows whether a personal agent made it and which one, each account shows the agents acting for it, and a WAF rule on the account's Hashed User ID can stop an attacker on one account without blocking the agent for others.
• Outside Cloudflare, the same ideas apply with your own tooling: verify Web Bot Auth signatures where agents send them, key rate limits and blocks to the signer and the account rather than the IP, and log each agent action against the account it touched. The IETF Web Bot Auth draft (-01, October 29, 2026) recommends that a site expecting signatures ask for them with Accept-Signature, and notes that the identifier allows correlation across sites.