If a request hits your product page or checkout claiming to be an AI shopping agent, how do you know it isn’t a scraper wearing a fake User-Agent string? Visa has a published answer: the Trusted Agent Protocol (TAP), a merchant-facing specification that defines exactly which cryptographic signatures to check, on exactly which requests, before you trust that the “agent” in front of you is real.

What TAP actually asks merchants to verify

Visa’s Trusted Agent Protocol specification describes a trust model built from three distinct signatures, checked at two points: when an agent browses a product page, and when it reaches checkout.

1. The agent recognition signature. Sent as an HTTP header on every request, built on RFC 9421 HTTP Message Signatures — the same standard underpinning Web Bot Auth. A real request looks like this:

Signature-Input: sig2=("@authority" "@path");created=1735689600;
  expires=1735693200;keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U";
  alg="Ed25519";nonce="e8N7S2MFd...";tag="agent-browser-auth"
Signature: sig2=:jdq0SqOwHdyHr9...:

The tag field is the tell: agent-browser-auth on a product-page visit, agent-payer-auth at checkout. Per the spec, a merchant verifying this signature must check, in order: all required fields are present (@authority, @path, created, expires, keyid, tag, alg, nonce); the created/expires window is currently valid and no more than 8 minutes wide; the nonce hasn’t been seen in the last 8 minutes (replay protection); the public key for keyid resolves at Visa’s published key store; and the signature itself validates against that key. Any failure on any step means: block the message.

2. The Agentic Consumer Recognition Object. A signed JSON object in the request body — same private key, same nonce linking it back to the header signature — carrying an ID Token (a Visa-signed JWT) plus contextual data (country code, postal code, IP, device data). This is how a merchant checks whether the consumer the agent is shopping for already has an account, without Visa exposing the consumer’s raw email or phone number in the clear — the merchant instead holds a mapping table matching obfuscated values.

3. The Agentic Payment Container. A third signed object carrying the actual payment data, shaped by how the merchant accepts payment: a hash of the card number/expiry/CVV for a guest-checkout key-entry form (so the merchant can catch a mismatch between what was key-entered and what the agent actually holds — a direct fraud check), a full encrypted payment token for an API integration, or an “IOU” object when the merchant used an HTTP 402 response to request payment before granting access.

Why the 8-minute window and the nonce matter

Two details in the spec are there specifically to close off the ways a captured “trusted” request could be reused. The created/expires pair is capped at an 8-minute span, and must straddle the current time — a signature can’t be pre-generated for later use, and it can’t still be valid long after being observed. The nonce doubles as a per-session replay guard: if a merchant has seen that exact nonce in the last 8 minutes, the request is rejected outright, even if the signature itself is otherwise valid. Together they turn “a valid signature was replayed” into a checkable, blockable condition instead of a silent gap.

Where this sits versus what you already run

TAP doesn’t ask a merchant to build new cryptography from scratch. Per the spec, verification “can be performed independently by the Merchant or by a Site Protection Provider on behalf of the Merchant” — in practice, your CDN or WAF. If your stack already verifies Web Bot Auth signatures, you’re most of the way there: TAP’s agent recognition signature is the same RFC 9421 mechanism with Visa-specific tags (agent-browser-auth, agent-payer-auth) and a Visa-hosted key directory at https://mcp.visa.com/.well-known/jwks. What’s new for most merchants is the second and third signatures — the consumer-recognition and payment objects arriving in the request body, not the header, and requiring your checkout logic (not just your edge) to read and validate them.

FAQ

What is Visa’s Trusted Agent Protocol?

It’s a specification Visa publishes for merchants and “Site Protection Providers” (CDNs, WAFs) describing how to cryptographically recognize an AI shopping agent acting on a consumer’s behalf, using signed HTTP requests instead of user-agent strings or IP allowlists. It defines three signatures — one on the request header, two in the request body — covering agent identity, consumer identity, and payment data.

Do merchants have to build their own signature verification?

Mostly no. Visa’s own spec states verification can be done by a Site Protection Provider on the merchant’s behalf, so if your CDN or WAF already supports RFC 9421 message signatures (the mechanism behind Web Bot Auth), the agent recognition signature is largely a configuration question. The consumer-recognition and payment-container objects, which arrive in the request body rather than the header, are more likely to require checkout-level code to parse and verify.

What happens if a signature fails verification?

For the agent recognition signature, Visa’s spec is direct: if any required field is missing, the timestamp window is invalid, the nonce was already seen, or the cryptographic check fails, “the message should be blocked.” For the consumer-recognition and payment objects, the spec is more permissive — a merchant may still choose to use the data even if verification fails, but is warned the content “may be inaccurate” and, for payment data specifically, “should not be used for processing any payment” if verification fails.

Sources

Whether your edge can tell a signed, trusted agent from an anonymous scraper — and whether your checkout actually reads what that signature carries — is exactly what an AgentReady scan checks.