What Is the Visa Trusted Agent Protocol (TAP)?
The Visa Trusted Agent Protocol (TAP) is a framework Visa introduced in October 2025 that lets an AI agent prove to a merchant, with a cryptographic signature on each request, that it is a recognized agent and whether it is browsing or paying. Built on HTTP Message Signatures (RFC 9421), each signature covers the merchant's domain and page path and carries timestamps and a nonce, so the merchant can reject requests that were altered, expired or replayed. Signed objects in the request body can also carry consumer recognition data and payment information.
Updated
What is the Visa Trusted Agent Protocol?
Visa introduced TAP on October 14, 2025, "developed in collaboration with Cloudflare" and available "in the Visa Developer Center and GitHub."
The problem sits on the merchant's side: bot defenses can block legitimate agents, and there was no standard way to tell a trusted shopping agent from malicious automation. The TAP repository lists the merchant's questions: "Is this a legitimate, trusted, and recognized AI agent?" "Is it acting on behalf of a specific, authenticated user?" "Does the agent carry valid instructions from the user to make this purchase?"
Visa's merchant specification ties TAP to Visa Intelligent Commerce, its agent payments program: a signature verified with a Visa-associated key "would imply the Agent's participation in (and compliance with) Visa Intelligent Commerce program requirements." The release says the initial specifications "apply to the Visa network in this phase," with alignment planned with the IETF, the OpenID Foundation and EMVCo.
How the Visa Trusted Agent Protocol works
The specification's trust model uses three signatures. An agent recognition signature goes in the header of every browsing and payment request. A signed consumer recognition object in the body tells the merchant whether it already knows the consumer. A signed payment container in the body carries payment data, from a hash of card details to be key-entered up to a full payment payload. Both body objects are signed with the header's key and include its nonce, which links them to it.
An illustrative checkout header, in the specification's format with shortened values and timestamps eight minutes apart:
Signature-Input: sig2=("@authority" "@path"); created=1735689600;
keyid="poqkLGiy..."; alg="Ed25519"; expires=1735690080;
nonce="e8N7S2MF..."; tag="agent-payer-auth"
Signature: sig2=:jdq0SqOw...:The tag is agent-browser-auth for browsing and agent-payer-auth for payment. The specification's verification steps, run by the merchant or the CDN or bot-protection layer in front of it:
- 1.No signature with one of the two tags means no trusted agent signed it; the merchant decides whether to block.
- 2.A required field is missing: block.
- 3.Block unless
createdis past,expiresis future, and the two are no more than 8 minutes apart. - 4."If maintaining a record of all nonces received in the last 8 minutes, if the nonce received matches a recorded nonce, the message should be blocked."
- 5.Fetch and cache the public key for
keyid; block if it can't be retrieved or has expired. - 6.Rebuild the signature base and verify the signature.
Why the Visa Trusted Agent Protocol matters in real-time systems
Five of the six steps check one request in isolation. Step 4 needs memory, and it is conditional: a signature is single-use only if the verifier keeps a record of every nonce it receives for 8 minutes. Visa's sample CDN proxy keeps seen nonces in an in-memory map inside one process. If a merchant verifies on several edge nodes and each keeps its own record, the same signed request can pass once at each node. A shared record with an atomic insert closes that:
-- tap_nonces.nonce is the primary key
INSERT INTO tap_nonces (nonce, expires_at)
VALUES ($1, to_timestamp($2))
ON CONFLICT (nonce) DO NOTHING
RETURNING nonce; -- no row returned: nonce already seen, blockTAP tells one merchant that an agent is recognized and its request is fresh. It does not know what other agents acting for the same user have already bought, or whether a purchase fits a budget those agents share. Visa Intelligent Commerce lets consumers set spending limits and conditions for agent transactions; budgets a platform defines across its own agents are the platform's to check before it submits.
On the agent platform's side, per-agent limits and purchase intents held in Tacnode commit under full transactions, so two agents cannot both reserve past the same cap. Visa's network, the issuer and the merchant's verifier keep their own checks; how the two sides divide the work is covered in Visa Intelligent Commerce.
FAQ
Related terms
Agent spend limits cap what an AI agent may commit per transaction, period or agent. They are only as accurate as the spend total they are checked against.
Idempotency means an operation has the same effect whether applied once or many times. Covers its math origin, HTTP methods, and API idempotency keys.
A race condition occurs when a system's outcome depends on the timing of concurrent operations, letting interleaved reads and writes corrupt shared state.
Multi-writer contention is two or more actors reading and writing the same mutable state in the same short window. It is not multi-tenancy or partitioning.
A decision ledger is an append-only record of automated decisions: what was decided, on what inputs, under which policy and authority, and what changed.
Decision context is everything an automated decision reads and everything earlier decisions committed, as it stands at the moment the decision executes.
Mastercard Verifiable Intent is an open spec for signed proof of what a user let an AI agent buy, with limits that merchants and payment networks can check.