Visa's Trusted Agent Protocol: identity at the merchant edge

Every payment protocol for agents answers the question "how does money move." Visa's Trusted Agent Protocol answers a different one: who is knocking. No value transfers over TAP. It is a signature check at the front door, and it is quietly becoming the admission criterion for the open commercial web.

The Trusted Agent Protocol was announced on October 14, 2025, developed with Cloudflare, with twelve launch partners on the merchant and processor side: Adyen, Ant International, Checkout.com, Coinbase, CyberSource, Elavon, Fiserv, Microsoft, Nuvei, Shopify, Stripe and Worldpay. The stated trigger was a 4,700% surge in AI-driven traffic to U.S. retail sites. Visa committed to aligning with the IETF, the OpenID Foundation and EMVCo, to complementing the Agentic Commerce Protocol, and to working with Coinbase on x402 interoperability.

That last commitment is why this protocol matters to anyone building on stablecoin rails. TAP does not compete with x402. It sits on top of it — or rather, in front of it. And the shape of that front door decides which agents get to spend at all.

What TAP actually is

Strip away the commerce framing and TAP is a profile of RFC 9421 HTTP Message Signatures, applied to the requests an agent makes against a merchant's website. The agent attaches signed headers to each request. The merchant — or, far more commonly, the CDN in front of the merchant — reconstructs the signature base, fetches the agent's public key from a Visa-operated directory, verifies, and decides whether to serve the page.

This is the same substrate as Web Bot Auth, which we covered two weeks ago. Cloudflare's October 24, 2025 writeup is explicit that Web Bot Auth is the cryptographic authentication layer under both TAP and Mastercard's Agent Pay, and that the point is to replace user-agent strings and IP addresses — both spoofable — with a stable identifier backed by public key cryptography.

Cloudflare's verification path for an authenticated agent request runs seven checks: the Signature-Input and Signature headers are present; the keyid resolves to a public key fetched from a directory; the current time falls between created and expires; the nonce has not been seen; the tag is a value the merchant accepts; the canonical signature base reconstructs from the covered components; and the Ed25519 signature verifies.

The critical sentence in Cloudflare's post is the one about scope. These mechanisms identify agents and link cardholder identity. Actual payment processing remains the payment network's responsibility. TAP is authentication and recognition. It is not settlement.

The wire format

Visa's published specification defines the minimum set of signature parameters. The covered components are the target URI pieces @authority and @path. The parameters are created and expires, a keyid, an alg, a nonce, and a tag.

Cloudflare's documentation shows the header in the shape a merchant will actually see it:

Signature-Input: sig2=("@authority" "@path"); created=1735689600;
  expires=1735693200; keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U";
  alg="Ed25519"; nonce="e8N7S2MFd/qrd6T2R3tdfAuuANng..."; tag="web-bot-auth"

Two properties fall directly out of that structure. Because @authority and @path are inside the signature base, a signature captured on one merchant's product page is worthless on another merchant's checkout page. And because created, expires and nonce are signed parameters, a captured request is worthless after its window closes. Visa's specification puts that window at eight minutes, with merchants tracking nonces for the same duration.

The tag is where TAP diverges from generic bot authentication. Web Bot Auth uses tag="web-bot-auth" to say "I am a declared bot." TAP defines two values that say something narrower. agent-browser-auth means the agent is browsing — reading a product page, checking availability, comparing a price. agent-payer-auth means the agent is at checkout with intent to pay.

The directory is the trust anchor

A signature is only as meaningful as the key that verifies it. TAP's specification says there is no centralized registry requirement in the protocol sense, but that agents must participate in a payment scheme program — Visa Intelligent Commerce being the reference case. Public keys are published at https://mcp.visa.com/.well-known/jwks.

That is a meaningful architectural choice, and it is the opposite of how the on-chain agent world has approached the same problem. In TAP, an agent is trusted because Visa vouched for it in advance. There is an enrollment step, product terms to accept, and a scheme program to join before the first request is ever signed. Cloudflare's role is to make the verification free for merchants: managed rulesets let a merchant allow Visa and Mastercard agents and block everything else, without changing anything behind the CDN.

Contrast this with ERC-8004, where any address can register an agent and the trust signal is supposed to emerge from feedback — which, as the first empirical audit showed, largely did not happen. TAP has the inverse failure mode. Its trust signal is strong and its registration gate is a business relationship. Both designs answer "who is this agent." One answers it with a permissionless registry that nobody has learned to read, the other with a permissioned directory that a card network controls.

Visa has continued building out that side. At Visa Payments Forum on June 10, 2026 the company announced an Agentic Directory of agents and merchants it has verified as legitimate participants, an Agent Score that rates whether a merchant's own site is navigable by agents, a Large Transaction Model for fraud detection, and a strategic collaboration with OpenAI. The same release put stablecoin settlement at roughly a $7 billion annualized run rate as of March 2026, and showed a Crypto Labs proof of concept letting AI agents pay for digital services from a command line using tokenized Visa credentials. Jack Forestell's framing was the cleanest summary of Visa's position: AI is transforming the front end of commerce, stablecoins are reshaping the back end.

Recognition: the second half of the protocol

The signature proves the agent. A second structure proves the shopper. Visa's specification defines an Agentic Consumer Recognition Object carried in the request body, containing a nonce matching the message signature, an idToken, a contextualData block, and its own signature made with the same private key as the message signature.

The idToken is a JWT issued by the payment scheme, signed with PS256, carrying obfuscated contact identifiers — phone number and email with verification flags — plus masked versions intended for UI rendering. The contextualData block carries country code, postal code, IP address and device identifiers. Merchants are expected to maintain mapping tables that resolve an obfuscated phone or email back to their own account records.

That last requirement deserves attention, because it defines the actual business value of TAP. The point is not just to admit the agent. It is to let the merchant recognize a returning customer through an agent, pre-fill checkout, and apply loyalty. Payment Account References for cards on file travel the same path when the consumer consents. TAP is a customer-recognition protocol wearing a bot-authentication uniform.

Three payment containers, and one of them is a 402

TAP does not move money, but it does carry the data that lets the merchant move it. The specification defines three approaches.

Guest checkout / key entry carries a credentialHash — a hash over card number, expiration and CVV — that the merchant uses to verify the credential the agent is keying in. API protocol carries an encrypted payload with a full payment object: token, shipping and billing addresses, consumer contact details. Both are card-rail flows, and both are what you would expect from a card network.

The third is not. Payment IOU is defined as an HTTP 402 response carrying a browsingIOU object that references an invoice ID, an amount, and acquirer details. Visa's own description of the mechanism is about managing balances and settlements between agents and merchants.

Read that against what we have written about x402's batch-settlement scheme and the resemblance is hard to miss. Both take the position that a per-request on-chain or on-rail settlement is the wrong unit for high-frequency agent traffic, and that the right primitive is an accumulating obligation redeemed later. TAP's version is card-network-shaped: the acquirer is named in the object and the merchant of record relationship is presumed. x402's is stablecoin-shaped. But the state machine — commit, accumulate, redeem — is the same one, and both chose HTTP 402 as the signal.

What the reference implementation actually ships

Specifications tell you what a protocol intends. Reference implementations tell you where it is. We cloned visa/trusted-agent-protocol on August 1, 2026 and read it.

The repository was created on October 10, 2025. The last commit to main landed on October 28, 2025. In the nine months since, nothing has been merged. It carries 191 stars, 40 forks, and 18 open issues and pull requests, nine of which are pull requests. The license is not an open source license: LICENSE.md binds use to the Visa Developer Center Terms of Use and the Trusted Agent Protocol Product Terms.

The sample has five components: a Streamlit agent that generates signatures, a React merchant frontend, a FastAPI merchant backend, a Node CDN proxy, and an agent registry serving public keys. The agent builds its signature base exactly as RFC 9421 prescribes, with @signature-params as the final line:

# tap-agent/agent_app.py
signature_params = f'("@authority" "@path"); created={created}; expires={expires}; ' \
                   f'keyId="{keyid}"; alg="rsa-pss-sha256"; nonce="{nonce}"; tag="{tag}"'

signature_base = '\n'.join([
    f'"@authority": {authority}',
    f'"@path": {path}',
    f'"@signature-params": {signature_params}',
])

Note keyId, camel-cased. RFC 9421 defines the parameter as keyid, lowercase, and both Cloudflare's example and Visa's own specification page use the lowercase form. The sample agent emits a parameter name no conformant verifier will recognize.

It gets worse one component over. The merchant backend parses the header with a regular expression:

# merchant-backend/app/security/signature_verification.py
signature_input_pattern = r'sig1=\("([^"]+)"\);\s*nonce="([^"]+)";\s*created=(\d+);' \
                          r'\s*expires=(\d+);\s*keyid="([^"]+)";\s*tag="([^"]+)"'

The agent emits label sig2; this expects sig1. The agent emits individually quoted covered components; this expects a single quoted blob. The agent emits created, expires, keyId, alg, nonce, tag in that order; this hardcodes nonce, created, expires, keyid, tag and has no slot for alg at all. The shipped agent and the shipped merchant verifier in the same repository cannot talk to each other. The CDN proxy, which implements the parse and base construction properly, is the only component that interoperates with the agent — and its inline documentation quotes a tag value, agent-payment-auth, that does not exist in the specification.

Pull request #21, opened July 15, 2026, diagnoses exactly this and offers the fix. It is still open. So is #11, opened February 18, 2026, which adds a working x402 flow to the sample — USDC on Solana and Base, the merchant backend serving HTTP 402 with payment requirements, settlement through a facilitator, tested end to end on Solana devnet and Base Sepolia. The x402 interoperability Visa promised in the launch press release exists, as a community contribution, unmerged for five months.

The most instructive open item is issue #23, filed July 18, 2026 by an independent implementer who built a merchant-side verifier to public-spec depth. Their blocker was not the message signature — that part is RFC 9421 and it is well defined. It was the object signature, the one covering the Consumer Recognition Object and the Payment Container. The public guidance for that base is a single sentence: a canonical representation of all fields in the object in the order received, excluding the signature field. There is no worked example and no test vector, which leaves rendering, nested-value encoding, line joining and field ordering all undefined. Two reasonable implementations produce incompatible signatures.

That is the real state of TAP in August 2026: a well-specified outer envelope that Cloudflare and Akamai can verify at the edge, wrapped around an inner layer that an outside party cannot implement from the public documentation alone. Which is consistent with the deployment model. The processors integrate once and cover their merchant base; adoption concentrated on the processor side first. Visa reported hundreds of agent-initiated transactions completed on December 18, 2025 with Skyfire, Nekuda, PayOS and Ramp, with Akamai providing edge-based identity and bot controls. Hundreds. The protocol is real and the volume is a pilot.

What it means for LLM4Agents

Three consequences, in order of how soon they bite.

The first is that the open web is becoming signature-gated, and our users are the ones being gated. An agent running on our gateway that browses a merchant site to compare prices is, from Cloudflare's perspective, unclassified automated traffic. It will increasingly be served a challenge or a block. The remedy is not TAP enrollment — that is a card program — but the layer underneath it: an agent that signs its requests with a Web Bot Auth key and publishes a directory is at least legible. Illegible agents lose access first.

The second is a mirror-image observation. LLM4Agents is itself a merchant selling to agents, and we have chosen the exact opposite trust model. Our walk-up rail is x402: an agent we have never seen presents a payment authorization, we verify it, we serve the request, we settle. Trust comes from money that moved, not from a directory that vouched. That model is strictly more permissionless, and it is also strictly weaker at answering "who was this." Both facts are true at once, and a serious platform should hold both.

The third is the convergence point. TAP's 402 IOU container and x402's batch-settlement scheme are two implementations of the same idea, arriving from opposite ends of the payments industry, both keyed on HTTP 402. Meanwhile Visa's own Crypto Labs proof of concept has agents paying for digital services from a terminal with tokenized credentials — which is our product surface described in a card network's press release. The identity layer and the settlement layer are being built by different parties, and the seam between them is exactly where a gateway lives. That seam is not a threat. It is the position.

Staying on the frontier

Sign outbound requests, and publish the directory. Ed25519 keys, a JWK thumbprint keyid, a directory at /.well-known/http-message-signatures-directory, and RFC 9421 signatures over @authority and @path on every outbound HTTP call an agent makes through us. This is the same work whether the far end is Cloudflare's Verified Bots, a TAP-aware merchant, or nothing at all. It is the cheapest available insurance against being classified as anonymous traffic.

Make the tag a policy boundary, not a string. Adopt the agent-browser-auth / agent-payer-auth split internally, and enforce that a payer-auth signature is never emitted without an explicit, scoped spend authorization from the operator. This is the same discipline as the keys-out-of-the-LLM rule we applied to the A2A x402 extension: the model decides what to buy, the signer decides what it is allowed to sign.

Verify TAP inbound, on our own edge. The outer envelope is implementable today from the public spec plus RFC 9421 — label-agnostic parsing, individually quoted covered components, @signature-params as the final base line, an eight-minute window, a nonce cache with the same TTL, and Ed25519 plus RSA-PSS. A TAP-signed request arriving at our gateway should be recognized and logged as such even before we do anything with it.

Bridge 402 to 402. When a signed agent hits a paid endpoint, answer with x402 payment requirements and carry the signature nonce into the payment context, so the settlement receipt is bound to the request that triggered it. That is the missing link between "this agent is who it says" and "this agent paid" — and it is precisely what unmerged pull request #11 prototypes. Track it, and build our side regardless of whether it lands.

Sign receipts, both directions. Issue #16 in the TAP repository asks for exactly this: a tamper-evident record binding the original request signature to a hash of what was processed, signed by the seller. We already emit settlement transaction hashes. Binding the hash to the request signature turns two separate logs into one verifiable claim, which is what a dispute actually needs.

Watch the IETF path, not the press releases. Visa committed to aligning TAP with the IETF, and the Web Bot Auth signature layer is already moving through a working group. If TAP's outer envelope converges on the IETF profile, everything built for one works for the other. If it does not, that divergence is the single most important fact about agent identity in 2027, and it will show up in a draft long before it shows up in an announcement.

Visa built a door and a doorman. The doorman checks credentials issued by Visa. That works well for the commerce that flows through card rails, and it says nothing at all about an agent that shows up with a stablecoin and no introduction. Both kinds of traffic are growing. Only one of them is trying to be permissionless.