The Visa Trusted Agent Protocol (TAP) is an open specification that signs an AI agent's identity into HTTP request headers, so that any merchant on the receiving end can answer one question cryptographically: is this agent legitimate. Visa and Cloudflare announced TAP on October 14, 2025 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 mechanism uses HTTP Message Signatures (RFC 9421) built on the emerging Web Bot Auth standard, with merchants verifying Ed25519 signatures against a Visa-operated directory of agent public keys. TAP does not move money. It sits as an identity wrapper in front of whatever payment rail the merchant runs, layering cleanly on top of other agent commerce protocols like ACP and UCP. This piece is the technical primer: what TAP is, how the Web Bot Auth signed-headers flow works in detail, what the directory does, who shipped it at launch, and how it compares to the rest of the agent identity and authorization stack.
​

The Trusted Agent Protocol (TAP) is an open ecosystem specification, co-developed by Visa and Cloudflare, that adds cryptographic agent identity to the existing HTTPS request flow. An AI agent attaches signed headers to every request; the merchant verifies the signature against a Visa-operated directory and treats the request as a known, accountable agent rather than an anonymous bot. No money moves over TAP itself.
​

Visa describes TAP as an "ecosystem-led framework for AI commerce" in its October 14, 2025 launch announcement. The framing matters: the spec belongs to the broader payments ecosystem rather than to Visa's card rails, and the working group at launch already included three of the largest payment processors (Adyen, Stripe, Worldpay), CyberSource, Elavon, and Nuvei on the processor side, and the major agent-side platforms shipping in 2026 (OpenAI's surface via Stripe, Microsoft's Copilot, Shopify's merchant network).
​

The specification is published openly on github.com/visa/trusted-agent-protocol, with a reference implementation, header schema definitions, and JSON-Schema files for the signed claim payloads. The protocol is licensed for any party to implement. Visa operates the directory of registered agent public keys at launch, but the spec contemplates a future federated directory model so that Visa's operational role does not become a permanent control point.
​

TAP solves a problem the merchant side has been pushing on hardest. The agent commerce stack of 2026 includes commerce protocols (ACP, UCP), payment authorization (AP2), tool plumbing (MCP), and inter-agent transport (A2A) — but until TAP, none of those layers gave the merchant a cryptographic answer to "is this a real agent acting for a real user, or a scraper pretending to be one." Cloudflare's launch press release frames the gap explicitly: bot detection has historically been heuristic, while agent traffic legitimately needs to look bot-like. TAP replaces heuristics with signatures.
​

TAP works by attaching three signed HTTP headers to every agent request. Signature-Agent carries the URL of the agent operator's public-key directory, Signature-Input declares the key ID, validity window, and the tag value (agent-browser-auth for browse-only or agent-payer-auth for payment intent), and Signature carries the Ed25519 signature over the canonical request. The merchant fetches the public key from the directory, verifies the signature, and proceeds with payment under whatever rail it normally runs.
​

The TAP request flow runs over standard HTTPS. There is no new transport, no out-of-band exchange, and no custom handshake. The agent sends its normal HTTP request to the merchant's checkout endpoint and adds the Web Bot Auth headers, all defined by RFC 9421 (HTTP Message Signatures). Any RFC 9421-compliant library can parse and verify them.
​

The signature mechanism is built directly on RFC 9421 HTTP Message Signatures, the same primitive WebAuthn aligns with. The Signature-Agent header points at the operator's published key directory, allowing a verifier to discover where to fetch the current public key. Signature-Input declares which request components are covered (typically the request method, path, host, and selected headers), the key ID, the algorithm (Ed25519), the timestamp, and the validity window. The Signature header carries the Ed25519 signature over the canonicalized request. The signature uses the agent operator's private key, and the header set travels intact through any HTTP proxy, CDN, or load balancer that does not strip arbitrary headers.
​

The headers are signed but not encrypted, so anyone in the request path can inspect them. That is intentional: a fraud system at the merchant's edge, a CDN running merchant-side bot detection, or an interchange node on the payment side can all see the agent's name and operator without holding any keys. TAP itself does not include payload encryption, so any cart, mandate, or shipping data sits in the request body protected only by TLS — the same threat model as a normal HTTPS checkout request.
​

TAP extends Web Bot Auth with two tag values inside the Signature-Input header that distinguish the agent's purpose. agent-browser-auth identifies a browse-only request — the agent is reading product pages, comparing prices, or building a cart but not yet committing to a purchase. agent-payer-auth identifies a payment-intent request — the user has authorized this agent to charge a specific amount with this merchant, and the merchant should treat the request as a binding payment instruction. Merchants can apply different verification logic, rate limits, and risk rules to each tag without writing two separate auth paths. Cloudflare's technical writeup details the tag semantics and the bot-management policies that consume them.
​

The merchant's verification step is where the Visa directory comes in. When the merchant receives the signed request, it follows the URL in Signature-Agent to fetch the operator's public key, or consults a cache that mirrors that directory. Rather than relying on PKI certificate authorities or X.509 chains, TAP uses a centralized directory service that Visa operates at launch. The merchant verifies the Ed25519 signature in the Signature header against the canonical request reconstructed from the components named in Signature-Input, and proceeds. The directory is HTTPS-served, cached aggressively, and refreshed on a published rotation schedule.
​

The directory model trades pure decentralization for two practical benefits. Key rotation is fast: a compromised operator can have its keys revoked across the network within minutes, rather than waiting for cached certificates to expire. Onboarding is gated: an agent operator has to register, prove its identity through Visa's standard merchant onboarding processes, and be assigned a directory entry before its requests get verified. The combination keeps the trust graph small and reviewable in the early years, with the open spec governance leaving room to evolve directory structure later.
​

The TAP architecture splits into three layers: the agent operator who holds signing keys and publishes a public-key directory, the Visa-operated trust directory that anchors operator identifiers to those keys, and the merchant who verifies signatures on incoming requests. Each layer is independently swappable, and the protocol does not assume a specific payment rail underneath.
​

The agent operator is the entity that runs the agent — typically a platform like OpenAI, Anthropic, Google, Microsoft, or any enterprise that builds its own agents. The operator generates an Ed25519 keypair, registers the public key with the Visa directory, and uses the private key to sign every outgoing request via RFC 9421 HTTP Message Signatures. Operators are responsible for their own internal user delegation: they decide how a user authorizes an agent (via AP2 mandate, OAuth flow, or signed prompt), and they apply the appropriate Web Bot Auth tag (agent-browser-auth or agent-payer-auth) when signing the request.
​

The directory is the trust anchor. Visa operates the launch directory, with a documented rotation schedule and revocation API. The directory does not see request bodies, does not log per-transaction data, and does not act as an interchange node. Its job is narrow: map operator identifiers to current public keys, refresh on rotation, revoke on compromise. This narrowness is what lets TAP scale without becoming a transaction bottleneck, since merchants cache directory responses locally and only call out on cache misses or refresh windows.
​

The merchant is the verifier. A merchant that receives a TAP-signed request runs two checks before processing payment. First, fetch the operator's public key from the directory referenced in the Signature-Agent header (or local cache). Second, verify the Ed25519 signature in the Signature header against the canonical request reconstructed from the components named in Signature-Input. Only after both checks pass — and the tag value matches the merchant's expectation for the endpoint — does the merchant hand the request to its payment processor. Verification adds one round-trip to the directory on cache miss and a few milliseconds of crypto work otherwise — measurable but not material against the typical card-authorization latency.
​

The architecture deliberately avoids defining a payment rail. TAP can sit in front of a Visa card-not-present authorization, an ACP Shared Payment Token call, a UCP checkout endpoint, an AP2 mandate, or a stablecoin transfer over x402. The merchant decides what runs underneath; TAP only certifies that the agent making the request is who it claims to be and is acting under the declared tag scope.
​

TAP launched on October 14, 2025 with twelve initial partners spanning payment processors, agent platforms, and merchant networks: Adyen, Ant International, Checkout.com, Coinbase, CyberSource, Elavon, Fiserv, Microsoft, Nuvei, Shopify, Stripe, and Worldpay, alongside Visa and Cloudflare as the co-developers. The launch list overlaps heavily with the ACP, UCP, and AP2 partner rosters, suggesting TAP is being positioned as the identity wrapper around those commerce protocols rather than as a substitute.
​

The processor partners cover most of the agent-payments rail capacity. Adyen, Stripe, and Worldpay handle a large share of card-not-present volume globally; Checkout.com, Fiserv, CyberSource, Elavon, and Nuvei round out the major-processor coverage; Ant International extends the reach into China and Southeast Asia where Alipay rails dominate. With those processors signed up at launch, any merchant integrating one of them inherits TAP support without writing the verification code itself — the processor verifies the headers and forwards the cleaned request to the merchant's backend.
​

The agent-platform partners on the launch list (Microsoft, Shopify) and the early adopters that joined within weeks (OpenAI via its Stripe integration, Google via the broader UCP family) cover the dominant agent surfaces. Coinbase's involvement is the bridge into stablecoin settlement: a TAP-signed agent paying via Coinbase Commerce or x402 can carry the same identity claim through to onchain settlement, even though the underlying rail is not a card network.
​

Cloudflare's role is operational. Cloudflare runs a meaningful fraction of the world's edge HTTP traffic, and its bot management product has historically had to choose between blocking agent traffic (frustrating users) or letting it through (frustrating merchants). With TAP, Cloudflare's edge can verify the RFC 9421 signature at the network layer, tag verified-agent traffic by the agent-browser-auth or agent-payer-auth value, and surface that signal to merchants through its existing bot management dashboard. Cloudflare's technical writeup describes how the verification fits into the existing Workers and Bot Management runtime.
​

By April 2026, six months after launch, several patterns are visible in the production traffic. Adoption is concentrated on the processor side first, since processors can implement TAP once and have it cover all of their merchant base. Direct merchant integrations are slower because they require backend changes; the merchants implementing TAP directly are the ones with their own engineering depth (large retailers, marketplace platforms) rather than long-tail Shopify sellers. The agent operators most active on TAP are the ones with formal Visa-merchant onboarding agreements already in place, which is the path of least resistance for directory registration.
​

One operational detail that surfaced in early production: directory caching strategy is the difference between TAP adding zero-latency overhead and TAP adding tens of milliseconds per request. Processors that cache directory entries aggressively (with stale-while-revalidate semantics) verify TAP signatures in roughly the same time budget as a TLS handshake. Processors that fetch fresh on every request pay the full directory round-trip latency, which adds up at agent-scale request rates. The reference implementation includes a recommended caching layer with a 60-second refresh window and immediate invalidation on revocation push, modeled on the way certificate transparency logs behave. Most processors that joined at launch reported sub-5ms verification overhead after the cache layer warmed up.
​

TAP is one of four agent identity-and-authorization protocols competing for adoption in 2026. The others are Google's AP2 for cryptographic user mandates, OpenAI/Stripe's ACP for shared payment tokens, and Skyfire's KYA (Know Your Agent) for agent reputation. Each occupies a slightly different slice of the trust problem, and a typical production stack composes two or three together rather than choosing one.
​

The four protocols answer overlapping but distinct questions. TAP answers "is this agent who it claims to be." AP2 answers "did the user really authorize this." ACP answers "is the payment instrument valid for this merchant and amount." KYA answers "is this agent trustworthy based on its history." The table below summarizes the comparison along five dimensions.

The non-overlap is the key takeaway. TAP and AP2 compose: TAP signs the agent identity at the HTTP layer, AP2 signs the user mandate inside the request body. ACP slots in below as the payment instrument: the SPT travels in the request payload while the TAP-signed headers wrap the request. KYA layers on as a risk score consulted at the merchant edge once the cryptographic checks pass. Google's AP2 GitHub repo documents how AP2 mandates compose with TAP-signed requests; the TAP reference implementation includes example payloads that carry AP2 mandates alongside the Web Bot Auth headers.
​

The composition pattern matters because no single protocol fully solves the trust problem on its own. A TAP signature without a user-authorization claim only proves that an agent is registered, not that the user wanted this purchase. An AP2 mandate without an identity wrapper proves the user signed but not who carried the signature. An SPT without either of the others proves the payment instrument is valid but says nothing about the agent or the user. In production stacks, all three usually show up together: TAP wraps the request with signed identity headers, AP2 lives inside the request body as a signed user mandate, and ACP or another payment-instrument layer carries the actual transfer authorization.
​

For merchants choosing where to invest first, processor-side TAP is the cheapest entry point because the processor handles the verification on the merchant's behalf. AP2 requires user-side wallet support, which means it depends on the agent platform first and the merchant second. ACP is narrower in scope but requires direct integration. KYA is optional layering for fraud-sensitive merchants who already run risk engines. The full stack only becomes mandatory at the high end of the merchant size distribution.
​

Eco operates a stablecoin execution network across 15 chains, complementing TAP rather than overlapping with it. TAP defines how the agent proves its identity to the merchant; Eco defines how the dollars actually settle when an agent paying USDC on one chain transacts with a counterparty whose treasury sits on another. The two layers compose without conflict.
​

TAP is an identity protocol. It signs agent identity and user authorization into HTTP headers but does not carry payment value itself. The actual money has to move on a rail underneath — whether a Visa card-not-present authorization, an ACP Shared Payment Token, an AP2-mandated PayPal transfer, or a stablecoin payment over x402. For merchants and agent platforms settling in stablecoins, Eco handles the cross-chain orchestration that TAP and the commerce protocols leave open: a TAP-signed agent request can carry an underlying USDC payment that originates on Base and lands in a treasury on Solana or Tron, with Eco's solver network choosing the route, the bridge, and the finality guarantees. The same logic applies for agent wallets running multi-chain balances and for agentic payment flows that need a stablecoin settlement layer behind whatever identity and authorization protocols sit in front. Eco uses Hyperlane and CCTP for the underlying transport. Identity layers like TAP and orchestration networks like Eco solve different problems, and the production stacks emerging in 2026 use both.
​

Sources and methodology. Protocol details and launch facts verified against primary sources: Visa's October 14, 2025 launch announcement, the TAP reference implementation on GitHub, Cloudflare's "Securing agentic commerce" technical writeup, and the Cloudflare collaboration press release. The HTTP Message Signatures specification is IETF RFC 9421. Partner lists reflect the launch announcement; production deployment characterizations reflect public processor and platform integrations as of Q1 2026.
​

For broader context on the agentic commerce stack and how TAP composes with adjacent protocols, the following pieces in this knowledge base cover the surrounding territory: