Web Bot Auth, Trusted Agent Protocol, Agent Pay, AP2 and Poppy: what agent protocols prove, and what they leave open

When banks restricted outside AI agents in October 2026, a common response from the technology side was: this is what protocols are for. Instead of agents signing in with a customer's password, they should identify themselves, carry a defined permission and present proof of what the customer asked for.

That is right, and a lot of that machinery now exists. This post maps five of the most prominent efforts, what each one establishes, and the question none of them is designed to answer on its own.

The map

1. Naming the agent: Web Bot Auth

For most of the web's history, a bot said who it was with a user-agent string, which anyone can copy. Web Bot Auth replaces that with a signature: the agent operator signs its HTTP requests with a private key, and a site checks the signature against a published public key. Cloudflare's September 2026 post “The Internet has a second audience” says operators including OpenAI, Google and AWS now sign their agents' requests, so a site can tell a real agent from an impersonator. Its summary is a good one: “A bot's name is only worth something if you can trust it.”

What it proves: this request came from a particular operator's agent. What it does not: which user the agent is acting for, what that user asked for, or whether the user is watching.

2. Recognised shoppers: Trusted Agent Protocol

In October 2025, Visa and Cloudflare introduced the Trusted Agent Protocol, built on Web Bot Auth, so merchants can tell a legitimate shopping agent from a malicious bot. The same announcement said Mastercard was incorporating Web Bot Auth into Agent Pay and American Express planned to use it in its agentic commerce programme.

What it proves: a recognised agent is visiting. What it does not: that this particular purchase reflects the user's wishes at this moment.

3. Credentials for agents: Mastercard Agent Pay

Mastercard announced Agent Pay in April 2025, introducing “Agentic Tokens” that extend its existing tokenisation (the same idea behind card-on-file and mobile wallets) to AI agents. The agent never holds the real card number, and tokens can be limited and revoked.

What it proves: the agent is using a credential issued for agent use, inside limits. What it does not: whether any given purchase within those limits is one the user would approve.

4. Proof of intent: AP2 mandates

Google's Agent Payments Protocol, launched in September 2025, goes furthest on the user's side. It records an “intent mandate” (what the user asked the agent to do, with limits) and a “cart mandate” (the specific items and price approved), both signed. Notably, AP2 distinguishes purchases made with the human present from purchases delegated in advance. In the first, the user approves the final cart; in the second, a detailed intent is set ahead of time and the cart is generated later.

What it proves: a signed record of what was asked and what was approved. What it leaves to the platform: showing that the approval was given by a person, rather than by software that had access to the approval screen.

5. Scoped access: Personal Agent Protocol

On 6 October 2026, Sierra announced the Personal Agent Protocol, developed with Meta and built on OAuth. The draft specification starts from the problem banks described: “Today it is all or nothing: the company blocks the agent, or the agent signs in as the person and can do anything they can.” Instead, companies publish named scopes, users sign in on the company's own page and choose what to grant, and one tier lets an agent act only with the user's approval. Payments are deferred to a future extension. American Banker reported that Bank of America, BBVA, Synchrony and Wells Fargo are among the banks exploring the framework.

What it proves: the user granted this agent this scope, on the company's own page. What it leaves to the platform: the moments where the scope says “with the user's approval.”

The common gap: presence at the moment of the action

Put the five side by side and a pattern emerges. They answer, with increasing precision:

• Who operates this agent? (Web Bot Auth, Trusted Agent Protocol)
• What credential may it use, within what limits? (Agent Pay)
• What did the user ask for and approve? (AP2)
• What did the user allow it to access? (Personal Agent Protocol)

Each of these is either established once in advance, or captured as a record. Several also depend, at their most sensitive point, on a human doing something: approving a cart, granting a scope, confirming an action. None of them is designed to check, at that moment, that the something was done by a person rather than by the agent that was already in the session.

That is not a criticism. Protocols define how parties exchange claims; the platform that shows the approval screen is the one that knows who is in front of it. But it means the weakest link in “human in the loop” is the loop itself. The six banks behind Building Trust in Agentic Commerce asked that any party carrying liability “be able to require authentication” when purchases are authorised. Authentication proves an identity. The open question is presence.

What platforms should do with this

1. Prefer named agents over credential sharing. Signed identity and scoped tokens are strictly better than a shared password.
2. Separate the agent's work from the person's approval. Let the agent prepare; make the approval a distinct step.
3. Check the approval step itself. When an action needs a person, confirm that a person is in control at that moment, tied to that action. This is the check HEIP provides: an answer, for one specific action, on whether a person is at the controls.
4. Keep the record. Pair the signed mandate with evidence about who was present when it was signed.