How do merchants detect AI agents?

What does a signed agent request look like?

An agent that wants to be recognised sends three headers. Signature-Input carries the metadata: a keyid naming the public key, a created and an expires timestamp, a nonce so the request cannot be replayed, a tag describing what kind of request this is, and the algorithm, which in practice is Ed25519. Signature carries the signature itself. Signature-Agent points at the directory where the key lives, and the origin fetches that directory from /.well-known/http-message-signatures-directory, takes the public key and checks the signature against the request it has just received (Cloudflare, IETF).

None of that is one vendor's invention. Web Bot Auth sits in three Internet-Drafts at the IETF: an architecture draft, a protocol draft that defines the Signature-Agent header and the JWKS-shaped key directory, and a registry draft for the signature agent card. Underneath them is RFC 9421, HTTP Message Signatures, which is a published standard rather than a proposal.

What a merchant learns from a valid signature is narrow, and worth stating precisely. It says the request came from the holder of a key that a named directory vouches for. It does not say the agent is honest, and it does not say the person behind it approved this particular purchase. It rules out the impersonator, and nothing further.

What does Visa's Trusted Agent Protocol add?

Visa published the Trusted Agent Protocol on 14 October 2025, built on the HTTP Message Signature standard and aligned with Web Bot Auth, naming twelve early partners across acquiring and platforms: Adyen, Ant International, Checkout.com, Coinbase, CyberSource, Elavon, Fiserv, Microsoft, Nuvei, Shopify, Stripe and Worldpay (Visa, Cloudflare).

Two additions do the work. The first is the directory. Under plain Web Bot Auth the agent points at its own key directory, so trust reduces to whether you trust that directory. Under the Trusted Agent Protocol the agent registers with a payment network, and Visa and Mastercard each host the directory for the agents registered with them, which moves the thing being trusted from the agent to the network. That is the card model applied to a header.

The second is the tag. The same field Web Bot Auth uses to say this is automated traffic now also says whether the agent has come to browse or to pay, so a merchant can treat a crawl and a checkout differently at the edge instead of at the payment page. Visa also describes linking a registered agent to a consumer identity, which is the step that turns detection into authorisation.

Why is a closed integration not the general answer?

Because it only identifies the agents you have already signed something with. The Agentic Checkout specification says a merchant's endpoints receive an Authorization header carrying an API key, a User-Agent naming the client (its own example value is ChatGPT/2.0), a Signature header holding a base64 signature of the request body and a Timestamp for replay protection, with webhooks returning an HMAC signature computed from a key the platform issued (Agentic Commerce Protocol, agentic checkout specification).

That is a sound design for what it is. The merchant knows exactly who is calling, because the merchant provisioned the key. But the identification comes out of the commercial relationship rather than out of the request itself, so it says nothing about the next agent, from a different vendor, arriving tomorrow. A merchant with three such integrations can identify three agents and is blind to the rest of the web.

Signing runs the other way round. The merchant needs no prior relationship with the agent, only with the directory that vouches for it.

What if the agent does not announce itself?

Then the merchant is inferring, and the inference is weak. An agent driving a real browser inside a session where a real customer is logged in looks like that customer, because in every respect the server can see, it is that customer. User-agent strings are self-reported and cost nothing to change. Behavioural heuristics catch the crude cases and miss anything built by somebody who read the heuristics first.

Volume is what makes that gap expensive. Adobe Analytics put AI-referred traffic to United States retail sites up 138 per cent year on year in May 2026, measured across more than a trillion visits, and found it converting at a rate 54 per cent better than traffic from non-AI sources (Digital Commerce 360, MarketingTech News). Traffic a merchant cannot label is traffic it cannot attribute, which means the best-converting channel on the site is the one nobody can defend a budget for.

How many merchants can identify agent traffic today?

Twenty-three per cent can identify both AI-driven traffic and AI-driven purchases. A further 21 per cent can see the traffic and cannot connect it to a completed purchase, which is the more dangerous half of the two, because it produces a number that looks like measurement. The figures come from the Global Digital Shopping Index: Merchant Edition, PYMNTS Intelligence's survey of 1,185 retail merchants in the United States, Brazil and the United Arab Emirates, fielded in March 2026 and commissioned by Visa Acceptance Solutions (PYMNTS, Visa Acceptance Solutions).

So the specifications are a long way ahead of the deployments. The signing standard is drafted, the network directories exist, the acquirers are named in a press release, and roughly three quarters of surveyed merchants still cannot say whether a sale came from a person or a program.

What should a merchant do first?

Log the headers before building anything on them. Signature-Input, Signature, Signature-Agent and User-Agent cost nothing to record, and they answer the question that decides everything after it: how much signed agent traffic is arriving at your origin today. Every conversation I have sat in on this has run on assumption rather than on a count. People argue about whether the traffic has arrived yet, and in the rooms I have been in, nobody had opened a log before arguing.

Verification comes after that. If the answer is a handful of requests a day, there is time to implement the directory fetch properly and to decide what an unverified agent is allowed to do (who is liable when an agent buys the wrong thing). If it is already a meaningful share of checkout, that decision is overdue, and it sits with whoever owns risk rather than with the team wiring up the header.