Make the agent prove who it is, and who it acts for

A request arrives at a shop. It looks like a browser. It might be a person, an agent doing the shopping for a real customer, or a scraper wearing the same costume. The shop cannot tell.

The usual signals are all forgeable. A user-agent string is a text field anyone can type. Behaviour patterns are a guess. IP ranges move. So merchants end up choosing between blocking agents and losing genuine customers, or letting everything through and eating the fraud. Both are defaults dressed up as decisions.

There is a second problem hiding inside the first, and it is easy to miss because the two questions sound so alike. Suppose the shop does know that the request genuinely comes from a well-known agent platform. That tells it which software is calling. It says nothing about whether the buyer told that software to make this purchase.

Amazon puts it plainly in the documentation for its own agent service: verification confirms that a request came from Bedrock AgentCore, and the site still decides what to allow, so a cryptographically verified agent can still be blocked. A valid signature proves that this really is Agent X. It does not prove that a person authorised Agent X to buy this. Those are two different proofs: identity, and delegation.

In the ordinary world, someone dealing with an agent carries some of the risk of checking. If a stranger turns up saying they buy on behalf of a company, a careful supplier asks for something: a purchase order, a letter, a phone call to someone known. Sensible commerce has always involved verifying the claim rather than accepting it.

There is also a doctrine covering someone who claims authority they do not have. An agent who claims permission it was never given may be liable to a third party who relied on that claim, and the law calls this breach of warranty of authority.

That remedy becomes awkward when the agent is software. The software is not the obvious legal person to sue, so liability would have to attach, if at all, to a person or company behind the system. Which one — the buyer, the agent operator, the platform, the model provider, someone else — is not something I would treat as settled, and it may well depend on the architecture and the contracts as much as on the doctrine.

The useful takeaway is narrower than a legal conclusion. Verification has always been the third party's job as well as the principal's, so building a system in which the merchant has no way to verify anything is not a neutral choice.

Treat the two claims separately, because they have different answers.

For who the agent is, sign the requests. Web Bot Auth does this with cryptographic signatures on the requests themselves, built on an existing standard for signing them (RFC 9421). A signed request carries three headers: a Signature header, a Signature-Agent header pointing at a directory of public keys, and a Signature-Input header saying what was signed.

It rests on two drafts at the IETF — the body that standardises internet protocols — one covering the directory and one the protocol itself, so it is a live proposal rather than a settled standard. It is not theoretical either. OpenAI signs the outbound requests from ChatGPT's cloud browser this way and publishes its verification keys at a well-known directory. Cloudflare put forward a registry format in February 2026, and that registry work has since continued as a draft authored jointly with Amazon.

For who the agent acts for, do not accept the agent's word. The delegation has to be evidenced by something the buyer produced, such as a signed mandate travelling with the request, rather than asserted by the party that benefits from being believed. An agent vouching for its own authority is the oldest bad idea in this space.

Verify against a directory you actually trust, at the moment of the request. A key you fetched once and cached forever is a key you cannot revoke.

Match strictness to stakes. Browsing on an unverified claim is fine; spending money on one is not. Fail closed where value moves and degrade gracefully everywhere else, or you will have built a system that quietly turns customers away.

For each request that mattered: what identity was presented, how it was checked, against which directory, and what evidence of delegation came with it.

The question you are preparing to answer is simple, and it will be asked months later: who was this, and who were they acting for? If the records only say that a purchase happened, you cannot answer it.

More than you would expect for something this new, and it is moving fast enough that this section will date before the others.

Visa's Trusted Agent Protocol separates the pieces rather than bundling them, with an agent recognition signature, signed consumer and device identity, and a signed payment container, and Visa publishes verification keys. Mastercard's Agent Pay issues a token uniquely to an agent, and its material describes tokens carrying predefined spending limits, merchant categories, purpose constraints and time windows. That framework also registers and verifies agents, so participants can recognise agent transactions.

The most interesting of the three is Verifiable Intent, which Mastercard announced with Google in March 2026 and open-sourced as a specification with a reference implementation. It links the consumer's identity, the original instructions including product and price limits, and the eventual transaction. That is a cryptographic proof of what the person authorised — the second proof, built by the industry itself.

The direction of travel is the same in each case: bind the agent, the person and the permission into something a merchant can check before the money moves. Which is to say that the distinction this control is built on is not one I am proposing against the grain. Parts of the industry are already designing for it explicitly.

What does not yet exist is one answer. Web Bot Auth, Visa's protocol and Mastercard's token solve overlapping parts of the problem at different places in the stack, and a merchant may end up handling several at once. Picking one today is a bet rather than a compliance decision, and it is worth making deliberately rather than by accident.