Mixed The specification has been public since 2025-10-14 with no version number. Visa reported live agent purchases at named European merchants on 2026-07-02, yet its overview page still says TAP is in development and deployment and may not be available in all markets.
Latest version
Unversioned specification (launched 2025-10-14); sample code last changed 2025-10-28,
State as of
Verified (verified under 30 days ago)
Card network
Identity and trust (primary layer)
Payment credential
Checkout and orders
A. TL;DR and key facts
Visa TAP lets a merchant recognize an approved AI agent. The agent signs each request with RFC 9421, tagged for browsing or paying, and may add signed consumer and payment objects. It identifies agents; it moves no money.
Why it exists
Merchants block most automated traffic because they cannot tell a shopping agent acting for a real cardholder from a scraper or a fraud bot, and IP addresses or user-agent strings prove nothing. TAP gives an agent that Visa has onboarded a key, and asks it to sign every request with a short-lived signature that says whether it is browsing or paying. A merchant, or the CDN in front of it, checks the signature against Visa's key directory and can then let the agent through, recognize the returning shopper and receive payment data in a signed container.
What it is not
Not an IETF standard. TAP is a Visa specification published under Visa's own revocable Product Terms, and Visa alone changes it. Source [1, 3, 5]
Not a payment rail. TAP identifies the agent and carries payment data; the money moves through Visa Intelligent Commerce tokens and ordinary card processing. Source [1, 9]
Not the Web Bot Auth working group draft. TAP predates the 2026-09-01 draft and differs from it: its own tags, does not require a Signature-Agent header, a mandatory nonce and Visa's own key directory. Source [1, 3, 14]
Not the same "agentic token" as Mastercard's. Visa's agent credentials are agentic network tokens in Visa Intelligent Commerce; Mastercard Agentic Tokens are a separate Agent Pay product on another network. Source [9, 15, 16]
Not a consent or spending-limit system. Passkey-approved instructions, step-up and limits live in Visa Intelligent Commerce, not in TAP. Source [1, 9]
Not mandatory for merchants. A merchant can accept Visa credentials without adopting TAP or registering with Visa. Source [1]
Not an open source project. The sample repository's LICENSE.md binds users to Visa's terms, even though the source files carry MIT-style headers. Source [17]
Key facts as of 2026-10-11
Steward
Visa, developed with Cloudflare; presented as an enhancement to Visa Intelligent Commerce Source [1, 2, 3, 4]
Governance
Proprietary Visa specification, not an IETF standard; Visa says it will align with the IETF, the OpenID Foundation and EMVCo Source [1, 3, 5]
License
TAP Product Terms (2025-10-10): revocable, no modification, full conformance, updates within six months Source [5]
First announced
2025-10-14, with 12 early feedback partners Source [3]
Latest version
No version number or date on the specification; sample repository has six commits, the last on 2025-10-28 Source [1, 6]
Status
Live purchases at named European merchants (2026-07-02); overview page still says development and deployment Source [4, 7]
Transports
RFC 9421 headers on HTTP requests; signed JSON objects in the request body Source [1, 8]
https://mcp.visa.com/.well-known/jwks; on 2026-10-11 it held one RSA sandbox key and no Ed25519 key Source [1, 10]
Builds on
RFC 9421, JWT and JWS, OpenID Connect ID Token claims, JWKS, Ed25519 and PS256 Source [1, 8]
Composes with
Stripe MPP (Visa's card method), x402 (browsingIOU answers a 402), OpenAI ACP and UCP (accepted by Intelligent Commerce Connect) Source [1, 11, 12, 13]
How to read this explanation
ELI5 is a short plain-language version. Practitioner is the full text. Spec-deep adds field tables and wire examples. STE shows the Simplified Technical English version instead.
B. Detailed explanation
ELI5 mode: plain-language version only.
Practitioner mode: the full explanation.
Spec-deep mode: the full explanation plus 2 field tables and wire examples.
STE mode: section B is hidden; the Simplified Technical English version (section D) is shown first.
Picture a big shop with a guard at the door. Many robots come to the shop. Some robots shop for real people. Others copy the price tags or try to cheat. The guard cannot tell them apart by looking, so he sends most robots away.
Visa gives each good robot its own stamp and keeps a book of stamp shapes at its office. Each time a good robot walks in, it stamps a fresh note: which shop and which shelf it wants, the time, a code for this visit, and one word that says “just looking” or “I want to pay”. The note is good for a few minutes only. The guard, or a security company the shop hires, compares the stamp with Visa’s book. If the stamp matches and the note is fresh, the robot may come in.
At the till the robot can hand over two more stamped envelopes. One says “this is a customer you may know” without saying the person’s name or email. The other holds what the shop needs to get paid: a check that the card details the robot types are right, a locked box that only the shop can open, or a note that says “I owe you for this page”.
The stamp pays for nothing. It only says who the robot is and what it wants to do. The money still moves the normal card way, and the shopper’s permission to spend lives in another Visa service.
Visa’s (TAP) answers one question for a merchant: is this automated request from an AI (artificial intelligence) that a payment network has approved, and does the agent want to browse or to pay?Source [1, 2] The agent signs each HTTP (Hypertext Transfer Protocol) request with RFC (Request for Comments) 9421 and puts a in the signature: agent-browser-auth for browsing, agent-payer-auth for checkout and payment.Source [1, 8] The merchant, or a CDN (content delivery network) in front of it, fetches the agent’s public key from the network’s key directory, checks a validity window of at most 8 minutes and a , rebuilds the signed text and verifies the signature.Source [1] At checkout the same key can sign two JSON (JavaScript Object Notation) objects in the request body, one that helps the merchant recognize the consumer and one that carries payment data.Source [1] What TAP does not give you: a payment, the user’s consent, spending limits or a liability rule. The money moves through tokens and ordinary card processing, and the user’s approval lives there too.Source [1, 9, 24] TAP is a Visa specification under Visa’s own terms, not an IETF (Internet Engineering Task Force) standard.Source [1, 3, 5]
Problem and design goals
Merchants and the services that protect their sites have long classed automated traffic as bots and blocked most of it, and an agent shopping for a real cardholder arrives as exactly that kind of traffic.Source [4] Visa’s launch release quoted Adobe data that AI-driven traffic to US retail sites rose more than 4,700 percent in the year to August 2025.Source [3] Visa said on 2025-11-20 that malicious bot-initiated transactions had risen 25 percent over six months, and 40 percent in the US.Source [25] Neither figure measures TAP traffic; they describe the problem TAP was built for.
Visa announced TAP on 2025-10-14, said it was developed with Cloudflare, and presents it as an enhancement to Visa Intelligent Commerce (VIC), the agent payment program it unveiled on 2025-04-30.Source [3, 4, 26] The specification is written for the case where the merchant does not know the agent in advance, and a merchant that has not adopted it can ignore every signature.Source [1] It names four goals for the agent signature: strong identity tied to a payment scheme’s program, requests that cannot be altered unnoticed, through timestamps and nonces, and no reliance on IP addresses or extra header content.Source [1] A key that belongs to Visa implies that the agent takes part in, and complies with, the VIC program.Source [1]
The overview groups what an agent can prove into three kinds of information: agent intent, consumer recognition and payment information.Source [4] The specification turns them into three signatures, one in the request headers and two in the request body.Source [1] It covers two moments of a purchase. Browsing means asking about a product, its availability and its final cost after taxes and shipping; payment means buying it or paying for access to a resource.Source [1]
Actors and roles
The specification names eight participants: Agent Providers, Checkout Enablers, Consumers, Site Protection Providers, Identity Providers, Merchants, Payment Schemes and a Key Store.Source [1] An Agent Provider is a certified AI platform that a payment scheme has onboarded and approved to pay on behalf of its account holders.Source [1] How Visa onboards agents is not public, and the guide that tells agents how to generate signatures is available only to onboarded agents.Source [1, 4, 9]
A is an intermediary that an agent may use to reach merchant sites, and TAP expects only one thing of it: pass the message signatures and query parameters through unchanged.Source [1] A is the layer in front of the merchant’s site, such as a CDN, a trust management system or a proxy.Source [1] Verification can happen at the merchant or at that provider on the merchant’s behalf.Source [1] In practice the edge does much of the work: Cloudflare published its TAP checks on 2025-10-24, and Akamai announced TAP support across Akamai Cloud on 2025-12-17.Source [27, 28, 29]
The Merchant does not have to use TAP or register with any payment scheme to accept its credentials.Source [1] A merchant that recognizes agents may serve them simpler pages or a shorter checkout.Source [1] The Payment Scheme, Visa in this case, sets the rules for agent-initiated transactions and hosts the key store at https://mcp.visa.com/.well-known/jwks.Source [1] For VIC, Visa also acts as the Identity Provider: it signs the ID Token that the consumer object carries.Source [1] The Consumer signs nothing in TAP; their approval of a purchase happens earlier, inside VIC, with a .Source [9]
Core objects
TAP has three signed things. The first is the agent recognition signature: two RFC 9421 header fields, Signature-Input with the metadata and Signature with the value.Source [1, 8] Its minimum are @authority and @path, and it must carry six parameters: created, expires, keyid, alg, nonce and tag.Source [1] The two timestamps may be at most 8 minutes apart.Source [1] The nonce is unusual: TAP calls it a session identifier and reuses the same value across every message signature and every signed body object of the interaction.Source [1] Agents and payment schemes may add fields beyond this minimum.Source [1]
The second is the , agenticConsumer, in the request body. It holds at least a nonce, an idToken, a contextualData object, a kid, an alg and a signature.Source [1]contextualData carries a country code, a postal code, the consumer’s IP address and device data, the last two collected when the consumer set up the in VIC.Source [1] The ID Token is a JWT (JSON Web Token) compatible with an and signed by Visa as a JWS (JSON Web Signature); its header needs alg, kid and typ, and the none algorithm is not allowed.Source [1] Its contact claims are obfuscated, so a merchant that wants to match a returning customer keeps its own mapping table from obfuscated email or phone values to its account holders.Source [1] Visa’s overview also mentions a blockchain wallet address as possible consumer data, but the specification’s tables define no such field.Source [1, 4]
The third is the , agenticPaymentContainer, also in the body, with at least nonce, kid, alg and signature.Source [1] What else it holds depends on how the merchant takes payment: a hash of the card credentials for a key-entered guest checkout, cardMetadata for display, an encrypted payload for merchants that process by API (application programming interface), or a browsingIOU after the merchant answered with .Source [1]cardMetadata includes the last four digits and the (PAR), which lets a merchant link token and virtual card payments to one funding account.Source [1] The payload is encrypted to a merchant public key that the merchant onboards to each payment scheme, and it carries a token object, addresses and consumer contact details.Source [1]
Both body objects are signed with the same private key as the header signature and carry the same nonce, which is what links them to the request.Source [1] TAP publishes no JSON Schema, OpenAPI file or test vectors, and the sample repository implements neither body object.Source [1, 2, 6] The field tables below therefore follow the specification page itself, which carries no version number.Source [1]
Field tables. Visa TAP merchant specification, unversioned and undated, read on 2026-10-11 at developer.visa.com. Descriptions are paraphrased. The page spells some names inconsistently (keyId and keyid, IdToken and idToken, paymentCredentialsHash and credentialHash); the tables use the names from the field lists.
Agent recognition signature: covered components and Signature-Input parameters (minimum set)Spec version TAP spec, unversioned (read 2026-10-11)
Hash of account number, expiry month and year and security code; for key-entered guest checkout. Called credentialHash in the processing section. Spec reference for paymentCredentialsHash
cardMetadata
object
No
lastFour, paymentAccountReference, shortDescription and card art (CardData: contentType, mimeType, width, height). Spec reference for cardMetadata
payload
encrypted object
No
Token object (paymentToken, expirationMonth, expirationYear, cardholderName, dynamicData), shipping and billing addresses, consumerEmailAddress, consumerName, consumerMobileNumber. Spec reference for payload
Illustrative example, spec version TAP (unversioned, read 2026-10-11): a signed browsing request. The host, key id, nonce and signature are placeholders that will not verify; the window is 300 seconds. The specification’s own examples reuse test values instead, as explained under security.
GET /example-product HTTP/1.1Host: shop.exampleSignature-Input: sig2=("@authority" "@path");created=1767225600;keyid="agent-key-1";alg="Ed25519";expires=1767225900;nonce="bm9uY2UtcGxhY2Vob2xkZXI";tag="agent-browser-auth"Signature: sig2=:c2lnbmF0dXJlLXBsYWNlaG9sZGVy:
The RFC 9421 for that request: one line per covered component, then the signature parameters as the last line.
The main sequence in section C follows one shopping trip: a signed browsing request, then a signed checkout request with both body objects, verified at a CDN and then at the merchant.Source [1] TAP defines verification steps for the merchant, not an API; the agent side lives in Visa’s non-public client guide.Source [1, 4]
The agent sends GET for a product page with Signature-Input and Signature headers covering @authority and @path, tagged agent-browser-auth.Source [1] A Checkout Enabler on the way must leave the headers and query parameters alone.Source [1]
The verifier looks for a signature tagged agent-browser-auth or agent-payer-auth. With neither tag, the request was not signed by a trusted agent, and the merchant may block it or judge it by other means.Source [1]
The verifier checks that every minimum field is present, that created is in the past and expires in the future, and that the two are at most 8 minutes apart.Source [1]
If the verifier keeps the nonces of the last 8 minutes, it blocks a nonce it has already seen.Source [1]
It takes the public key for keyid from its cache or from the key store; a key that cannot be found or has expired blocks the request.Source [1]
It rebuilds the signature base and verifies the signature. Any failure in steps 3 to 6 blocks the request.Source [1] On success the merchant treats the caller as a trusted agent that is browsing or paying, and may still limit what it can do.Source [1]
At checkout the agent sends the same kind of signature with agent-payer-auth, plus agenticConsumer and agenticPaymentContainer in the body, all with the same nonce and key.Source [1]
The merchant checks each body object: required fields, a nonce equal to the header nonce, the key for kid, and a signature over the other fields in the order received.Source [1]
The merchant processes the payment data: it compares its own hash of the key-entered card with the credential hash and declines on a mismatch, decrypts payload with its private key, or checks a browsingIOU against its 402 response.Source [1] Authorization then runs through the merchant’s acquirer as for any card payment; TAP adds nothing there.Source [1, 9, 24]
The two body objects fail differently. Consumer data that fails verification may be inaccurate, and the merchant may still use it.Source [1] Payment data with missing fields, a nonce mismatch or a bad signature should not be used for payment, yet a missing key only makes it possibly inaccurate, and the same section leaves usability to the merchant’s discretion.Source [1] The nonce comparison may be skipped when a payment is requested without a message signature.Source [1]
Cloudflare’s edge runs the same checks in its own order: headers present, key fetched by keyid, time window, nonce unused, tag allowed, signature base rebuilt, Ed25519 verification.Source [27] The same post’s example request carries tag="web-bot-auth", which its own tag check would reject; follow the Visa specification.Source [27] Section C has the decision tree and three failure paths: an untagged request, an expired window and a replayed nonce.
Illustrative example, spec version TAP (unversioned, read 2026-10-11): a payment container answering a merchant’s HTTP 402. The specification gives no types for most IOU fields, so every value here is a placeholder string, and the signatures will not verify.
TAP has no stateful objects of its own, no order, mandate or token. The only state lives with the verifier: a nonce record, a key cache and the signature’s validity window.Source [1] The state machine in section C therefore follows one request through verification, from received to served, blocked or untrusted.
The window is short on purpose. A signature lives at most 8 minutes, and the sample agent sets expires to exactly created plus 8 minutes with a random UUID as nonce.Source [1, 30] Because the specification calls the nonce a session identifier shared across signatures, a verifier that blocks every repeated nonce could also block a legitimate second signature in the same session; the text does not resolve this.Source [1]
The purchase itself has a lifecycle, but it lives in VIC. Visa’s API client enrolls a card with POST /vacp/v1/cards, creates, updates and cancels purchase instructions under /vacp/v1/instructions, fetches payment credentials with POST /vacp/v1/instructions/{instructionId}/credentials and reports outcomes with POST /vacp/v1/instructions/{instructionId}/confirmations.Source [31] VIC issues agent-specific tokens after step-up verification and passkey setup, and the user approves each Payment Instruction with a passkey before the agent fetches credentials.Source [9] Section C shows that link as its own sequence.
Security and trust model (summary)
The stamp proves the robot is one Visa knows, and the short time limit stops anyone from copying an old note. But the note only names the shop and the shelf, not what the robot asks for there, and the guard does not have to keep a list of codes already used.
TAP’s guarantee is narrow: a request signed with a key from the scheme’s store, for this host and path, inside an 8-minute window, with a stated purpose.Source [1] Trust rests on two things the public cannot inspect: Visa’s onboarding of agents and the key store Visa runs.Source [1, 9, 10]
The gaps are specific. The minimum signature does not cover the method, the query string or a content digest, so the body, including both signed objects’ transport, is not bound to the header signature.Source [1, 32] The Web Bot Auth draft warns that a signature over the authority alone can be reused against any method, path or body until it expires.Source [14] The specification’s own benefits text claims coverage of method and headers that its minimum does not require.Source [1] Nonce tracking is optional, so replay protection depends on the verifier keeping state.Source [1] Body objects are signed over all fields in the order received, with no named canonicalization and no test vector.Source [1, 6] The credential hash has no stated algorithm or salt, and the data it hashes (a 16-digit number, expiry and a 3-digit code) has little entropy.Source [1]
The published material does not hold together in places. The live key store held one 2048-bit RSA key from a Visa sandbox CA (certificate authority), with no alg or use, and no Ed25519 key, so the specification’s example keyid cannot be resolved there.Source [10] The example keyid, nonce, timestamps and signature match a test vector in the Web Bot Auth draft that signs a different base with a different tag, and the browsing and checkout examples show the same signature, so neither example can verify as printed.Source [1, 14] The example window is 3,600 seconds against the 8-minute rule.Source [1] No CVE (Common Vulnerabilities and Exposures) entry or GitHub advisory names TAP, and the one formal analysis of agent payment protocols did not model it.Source [6, 33, 34] Section H has the threat table.
Versioning and governance
There is no version number. The specification page shows no version or date, the Product Terms are dated 2025-10-10, and the sample repository has six commits from 2025-10-12 to 2025-10-28 and no tags or releases.Source [1, 5, 6] Nothing has been merged since; twelve later pull requests are open or were closed unmerged.Source [6]
Visa governs TAP alone. The Product Terms grant a nonexclusive, nontransferable and revocable license, conditioned on implementing the current specification in full and in strict conformance.Source [5] They forbid modifications other than implementing or porting, and assign unpermitted modifications to Visa.Source [5] Licensees must apply each Visa update at least yearly and within six months of its publication, though production use needs no Solution Approval review.Source [5] The implementer alone carries disclosure and consent duties toward users.Source [5] The sample repository’s LICENSE.md points to these terms while its source files carry MIT-style permission text, and GitHub reports no recognized license.Source [6, 17]
Visa calls TAP an open framework and says it will align with the IETF, the OpenID Foundation and , with the first specifications applying to the Visa network in this phase.Source [3, 5, 29] None of those bodies publishes TAP today.Source [1, 3, 5]
Extensibility
The specification is a framework with a Visa implementation inside it, and the extension points are loose. Agents and schemes may add signature fields beyond the minimum.Source [1] The consumer object may carry a loyalty number or another party’s identity token, and the payment container’s content changes with the merchant’s processing path.Source [1] The specification says agents can talk over web or API channels and protocols such as MCP (Model Context Protocol) and ACP (Agentic Commerce Protocol), but no binding for them exists.Source [1] A shared key store across payment schemes is named as a goal; today each network runs its own.Source [1, 27]
How it composes with the other seven
TAP is an identity layer that sits in front of checkout and payment protocols. Visa authored the card method of Stripe and Tempo’s MPP (Machine Payments Protocol), says that method and its SDK (software development kit) are built on VIC and TAP, and the mppx SDK can sign and verify TAP request attestations.Source [11, 12, 23] The browsingIOU answers an HTTP 402 but uses none of x402’s headers or payloads, while Visa sits on the x402 Foundation as a Premier member.Source [1, 35] Visa says TAP complements ACP, which OpenAI and Stripe maintain, and accepts TAP, MPP, ACP and UCP (Universal Commerce Protocol) payments, but no wire-level binding to ACP or UCP is published.Source [1, 3, 13] AP2 (Agent Payments Protocol) and ERC-8004 have no documented link.Source [1, 36] Section P goes further.
Limitations and open issues
Proprietary and revocable. The terms forbid modification and can be withdrawn, which limits independent implementations and forks.Source [5]
One directory per network. Visa and Mastercard each host their own key directory, so a verifier needs one integration per network.Source [1, 27]
Key store mismatch. The published (JSON Web Key Set) does not hold the kind of key the examples use, and Visa has not said how production agent keys reach verifiers.Source [1, 10]
Spec quality. No version, no changelog, “RCF 9421” for RFC 9421, inconsistent field spellings, a Python sample whose signature parameters start with the label and leave out alg, and no test vectors.Source [1, 6, 8]
Sample drift. The sample uses the unregistered algorithm name rsa-pss-sha256, adds spaces to the serialized parameters, builds a non-RFC base in the merchant backend, and its CDN proxy checks neither tag nor window and protects only /product/ paths.Source [8, 30, 37, 38]
Privacy. Every merchant the agent visits can receive the consumer’s IP address, device data, country and postal code, and the specification sets no minimization or retention rule.Source [1]
Unclear transport. The README says identifiers arrive through query parameters, the specification puts them in the body, and nothing says how a body travels on a GET.Source [1, 2]
No liability rule. Worldpay wrote on 2026-07-30 that no liability shift exists yet for agentic transactions.Source [24]
Open questions in the repository ask what standing a payment instruction keeps after its agent is revoked and how receipts should be signed.Source [6]
What changed in 2025 and 2026
2025-04-30: Visa unveiled Visa Intelligent Commerce.Source [26]
2025-09-04: Visa announced an MCP server for VIC and piloted the Visa Acceptance Agent Toolkit.Source [39]
2025-10-14: TAP launched with 12 named feedback partners, the specification and the sample repository.Source [3]
2025-10-24: Cloudflare published its edge verification checks for TAP and Agent Pay.Source [27]
2025-10-28: the last merged change to the sample repository added nonce validation.Source [6]
2025-12-17 and 2025-12-18: Akamai support; Visa reported hundreds of agent-initiated transactions completed with partners, a count of VIC transactions rather than TAP traffic.Source [28, 29]
2026-03-17 and 2026-03-18: Agentic Ready launched in Europe with 21 issuers; Visa published its MPP card specification and the mpp-card SDK.Source [11, 40, 41]
2026-07-01 and 2026-07-02: Cloudflare folded signed agents into verified bots; 31 European issuers completed live agent purchases at merchant websites.Source [7, 20]
2026-08-12: TAP request attestation arrived in mppx.Source [22]
2026-09-01: the IETF Web Bot Auth working group posted draft -00, which TAP predates and does not follow.Source [3, 14]
C. Diagrams
Main flow: Visa TAP: browse a product, then check out with signed objects
One shopping trip under TAP. The agent signs a browsing request with agent-browser-auth, a CDN verifies it against the Visa key store, and the merchant serves the page. At checkout the agent signs with agent-payer-auth and adds the consumer recognition object and the payment container, both signed with the same key and nonce. The merchant verifies them, decrypts the payment payload and authorizes the payment through its acquirer as an ordinary card payment.
AI agent
Site Protection Provider (CDN)
Visa key store
Merchant
Acquirer and Visa network
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 11AI agent toto Site Protection Provider (CDN)
GET product page, signed agent-browser-auth
The agent requests a product detail page. Signature-Input covers @authority and @path and carries created, expires, keyid, alg, nonce and tag. The values here are placeholders.
HTTP payload. Illustrative example, spec version TAP spec, unversioned (read 2026-10-11).
GET /example-product HTTP/1.1
Host: shop.example
Signature-Input: sig2=("@authority" "@path");created=1767225600;keyid="agent-key-1";alg="Ed25519";expires=1767225900;nonce="bm9uY2UtcGxhY2Vob2xkZXI";tag="agent-browser-auth"
Signature: sig2=:c2lnbmF0dXJlLXBsYWNlaG9sZGVy:
Spec version TAP spec, unversioned (read 2026-10-11) (2025-10-14). Sources: [1], [9], [10], [27]
Step 1 of 11: AI agent to Site Protection Provider (CDN). GET product page, signed agent-browser-auth. Crosses a trust boundary.
Sequence diagram: Visa TAP: browse a product, then check out with signed objects
Scroll to see the whole diagram
Generated from the flow definition (spec version TAP spec, unversioned (read 2026-10-11), 2025-10-14). The player above uses the same data.
Text alternative
Sequence diagram: Visa TAP: browse a product, then check out with signed objects. 5 participants: AI agent, Site Protection Provider (CDN), Visa key store, Merchant, and Acquirer and Visa network. 11 steps, 8 crossing a trust boundary, 8 failure branches. Based on visa-tap TAP spec, unversioned (read 2026-10-11) (2025-10-14). Step 1: AI agent to Site Protection Provider (CDN): GET product page, signed agent-browser-auth. This step crosses a trust boundary. If A Checkout Enabler strips the signature headers: The request arrives unsigned and is treated as an unknown bot. Step 2: Site Protection Provider (CDN) to Visa key store: Fetch the key for keyid (if not cached). This step crosses a trust boundary. If Key not found or expired: Block the request. Step 3: Site Protection Provider (CDN) to Site Protection Provider (CDN): Check tag, fields, window, nonce, signature. If No TAP tag: Not a trusted agent; block or use other means. If Missing field, bad window, reused nonce or bad signature: Block the request. Step 4: Site Protection Provider (CDN) to Merchant: Forward as a verified agent request. This step crosses a trust boundary. Step 5: Merchant to AI agent: 200 product page. This step crosses a trust boundary. Step 6: AI agent to Site Protection Provider (CDN): POST checkout, signed agent-payer-auth, with body objects. This step crosses a trust boundary. If Body altered in transit: The header signature still verifies; only the object signatures can catch it. Step 7: Site Protection Provider (CDN) to Merchant: Verify header signature, forward. This step crosses a trust boundary. Step 8: Merchant to Merchant: Verify agenticConsumer and agenticPaymentContainer. If Consumer object fails: Content may be inaccurate; the merchant may still use it. If Payment container fails: Should not be used for payment. Step 9: Merchant to Merchant: Decrypt payload and map the ID Token. Step 10: Merchant to Acquirer and Visa network: Authorize the card payment. This step crosses a trust boundary. If Issuer declines: Ordinary card decline; TAP has no role. Step 11: Merchant to AI agent: Order confirmation. This step crosses a trust boundary.
Step 1: AI agent to Site Protection Provider (CDN): GET product page, signed agent-browser-auth. This step crosses a trust boundary. If A Checkout Enabler strips the signature headers: The request arrives unsigned and is treated as an unknown bot.
Step 2: Site Protection Provider (CDN) to Visa key store: Fetch the key for keyid (if not cached). This step crosses a trust boundary. If Key not found or expired: Block the request.
Step 3: Site Protection Provider (CDN) to Site Protection Provider (CDN): Check tag, fields, window, nonce, signature. If No TAP tag: Not a trusted agent; block or use other means. If Missing field, bad window, reused nonce or bad signature: Block the request.
Step 4: Site Protection Provider (CDN) to Merchant: Forward as a verified agent request. This step crosses a trust boundary.
Step 5: Merchant to AI agent: 200 product page. This step crosses a trust boundary.
Step 6: AI agent to Site Protection Provider (CDN): POST checkout, signed agent-payer-auth, with body objects. This step crosses a trust boundary. If Body altered in transit: The header signature still verifies; only the object signatures can catch it.
Step 7: Site Protection Provider (CDN) to Merchant: Verify header signature, forward. This step crosses a trust boundary.
Step 8: Merchant to Merchant: Verify agenticConsumer and agenticPaymentContainer. If Consumer object fails: Content may be inaccurate; the merchant may still use it. If Payment container fails: Should not be used for payment.
Step 9: Merchant to Merchant: Decrypt payload and map the ID Token.
Step 10: Merchant to Acquirer and Visa network: Authorize the card payment. This step crosses a trust boundary. If Issuer declines: Ordinary card decline; TAP has no role.
Step 11: Merchant to AI agent: Order confirmation. This step crosses a trust boundary.
Lifecycle: Visa TAP: one request through verification (verifier-side state)
A filled dot marks the initial state; terminal states have a double border; dashed lines go back to an earlier state. Numbers on the lines match the transition list.
created past, expires future, at most 8 minutes apart.
Nonce not seen
Only if the verifier keeps nonces of the last 8 minutes.
Key resolved
From cache or the key store.
Trusted agent, paying
Body objects may follow.
Body objects checked
agenticConsumer and agenticPaymentContainer.
Not a trusted agent
Merchant may block or use other means.
Transaction declined
Merchant declines the payment and does not use the payment data.
Spec version TAP spec, unversioned (read 2026-10-11).
State diagram: Visa TAP: one request through verification (verifier-side state)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Generated from the state machine definition (spec version TAP spec, unversioned (read 2026-10-11)).
Text alternative
State diagram: Visa TAP: one request through verification (verifier-side state). 13 states: Request received, TAP tag found, Minimum fields present, Inside the window, Nonce not seen, Key resolved, Trusted agent, browsing, Trusted agent, paying, Body objects checked, Served, Not a trusted agent, Blocked, and Transaction declined. Starts in Request received. Ends in Served, Not a trusted agent, Blocked, and Transaction declined. 17 transitions. From Request received to TAP tag found when Signature-Input has a TAP tag. From Request received to Not a trusted agent when No TAP tag. From TAP tag found to Minimum fields present when All minimum fields present. From TAP tag found to Blocked when A field is missing. From Minimum fields present to Inside the window when Timestamps valid. From Minimum fields present to Blocked when Window over 8 minutes or outside now. From Inside the window to Nonce not seen when Nonce unseen, or no record kept. From Inside the window to Blocked when Nonce already recorded. From Nonce not seen to Key resolved when Key for keyid found (GET https://mcp.visa.com/.well-known/jwks). From Nonce not seen to Blocked when Key missing or expired (GET https://mcp.visa.com/.well-known/jwks). From Key resolved to Trusted agent, browsing when Signature valid, tag agent-browser-auth. From Key resolved to Trusted agent, paying when Signature valid, tag agent-payer-auth. From Key resolved to Blocked when Signature invalid. From Trusted agent, browsing to Served when Merchant serves the page. From Trusted agent, paying to Body objects checked when Nonce, kid and signature of each body object checked. From Body objects checked to Served when Payment data processed. From Body objects checked to Transaction declined when Payment container invalid or hash mismatch: decline the transaction.
From Request received to TAP tag found when Signature-Input has a TAP tag.
From Request received to Not a trusted agent when No TAP tag.
From TAP tag found to Minimum fields present when All minimum fields present.
From TAP tag found to Blocked when A field is missing.
From Minimum fields present to Inside the window when Timestamps valid.
From Minimum fields present to Blocked when Window over 8 minutes or outside now.
From Inside the window to Nonce not seen when Nonce unseen, or no record kept.
From Inside the window to Blocked when Nonce already recorded.
From Nonce not seen to Key resolved when Key for keyid found (GET https://mcp.visa.com/.well-known/jwks).
From Nonce not seen to Blocked when Key missing or expired (GET https://mcp.visa.com/.well-known/jwks).
From Key resolved to Trusted agent, browsing when Signature valid, tag agent-browser-auth.
From Key resolved to Trusted agent, paying when Signature valid, tag agent-payer-auth.
From Key resolved to Blocked when Signature invalid.
From Trusted agent, browsing to Served when Merchant serves the page.
From Trusted agent, paying to Body objects checked when Nonce, kid and signature of each body object checked.
From Body objects checked to Served when Payment data processed.
From Body objects checked to Transaction declined when Payment container invalid or hash mismatch: decline the transaction.
Five trust zones. Visa onboards agents, runs the key store and signs the ID Token; the agent holds its signing key; the request can pass a Checkout Enabler and a CDN before the merchant; money moves through the card network outside TAP.
Text alternative
Flowchart with five zones. Agent provider zone: the AI agent and its private key, which signs headers and body objects. Visa zone: VIC onboarding, which registers the key in the key store at mcp.visa.com/.well-known/jwks, the ID Token signer and VIC tokens, passkeys and instructions, which supply credentials to the agent. Path zone: a Checkout Enabler that passes requests through and a Site Protection Provider (CDN). The agent sends a signed request through the Checkout Enabler to the CDN, which fetches the key by keyid from the key store and forwards the verified request to the merchant. The merchant verifies the body objects and ID Token with keys from the key store, decrypts the payload with its own key, and authorizes the payment through the acquirer and Visa network.
The header signature and the two body objects, linked by the same nonce and signing key, plus the nested objects and the key format. Field names follow the unversioned specification read on 2026-10-11.
Text alternative
Class diagram. SignatureInput covers @authority and @path and has created, expires, keyid, alg, nonce and tag. It links, through the same nonce and key, to an optional agenticConsumer (nonce, idToken, contextualData, kid, alg, signature) and an optional agenticPaymentContainer (nonce, kid, alg, signature, paymentCredentialsHash, cardMetadata, encrypted payload, browsingIOU). contextualData holds countryCode, zip, ipAddress and deviceData. The ID Token holds iss, sub, aud, exp, iat and obfuscated or masked email and phone claims. cardMetadata holds lastFour, paymentAccountReference and shortDescription. browsingIOU holds invoiceId, amount, cardAcceptorId, acquirerId, uri, sequenceCounter, paymentService, kid, alg and signature. A JWK with kty, kid, use, alg, n and e verifies the keyid and the ID Token.
The covered components become one line each, the signature parameters become the last line, and the agent signs that exact text. The method, query string and body are not in the minimum set, so they are not protected.
Text alternative
Flowchart. From the request, the Host value becomes the @authority line, the path becomes the @path line, and the Signature-Input parameters become the last line, @signature-params, which repeats the component list and the parameters created, keyid, alg, expires, nonce and tag. The agent signs the three lines with its key, Ed25519 in the examples, producing the Signature header value. The verifier rebuilds the same base and checks it with the public key. A note says the method, the query and the body are not covered by the minimum set.
The Cloudflare sequence for a browsing request: headers present, key fetched by keyid and cached, time window, nonce uniqueness, tag, signature base rebuilt, Ed25519 verification.
Text alternative
Sequence diagram: Visa TAP: browsing request verified at the CDN. 5 participants: AI agent, Checkout Enabler, Site Protection Provider (CDN), Visa key store, and Merchant. 9 steps, 4 crossing a trust boundary, 7 failure branches. Based on visa-tap TAP spec, unversioned (read 2026-10-11) (2025-10-14). Step 1: AI agent to Checkout Enabler: Signed GET through a Checkout Enabler. This step crosses a trust boundary. Step 2: Checkout Enabler to Site Protection Provider (CDN): Pass signatures and query parameters through. This step crosses a trust boundary. If Headers stripped or rewritten: Verification fails or the request looks unsigned. Step 3: Site Protection Provider (CDN) to Site Protection Provider (CDN): Headers present. If Missing: Treat as an unsigned bot. Step 4: Site Protection Provider (CDN) to Visa key store: Fetch key by keyid and cache it. This step crosses a trust boundary. If keyid not in the directory: Block. Step 5: Site Protection Provider (CDN) to Site Protection Provider (CDN): Time window. If Outside the window: Block. Step 6: Site Protection Provider (CDN) to Site Protection Provider (CDN): Nonce not seen recently. If Nonce seen: Block as replay. Step 7: Site Protection Provider (CDN) to Site Protection Provider (CDN): Tag is agent-browser-auth. If Other tag: Block or handle as non-TAP traffic. Step 8: Site Protection Provider (CDN) to Site Protection Provider (CDN): Rebuild signature base and verify Ed25519. If Signature invalid: Block. Step 9: Site Protection Provider (CDN) to Merchant: Forward, marked as a verified agent. This step crosses a trust boundary.
Step 1: AI agent to Checkout Enabler: Signed GET through a Checkout Enabler. This step crosses a trust boundary.
Step 2: Checkout Enabler to Site Protection Provider (CDN): Pass signatures and query parameters through. This step crosses a trust boundary. If Headers stripped or rewritten: Verification fails or the request looks unsigned.
Step 3: Site Protection Provider (CDN) to Site Protection Provider (CDN): Headers present. If Missing: Treat as an unsigned bot.
Step 4: Site Protection Provider (CDN) to Visa key store: Fetch key by keyid and cache it. This step crosses a trust boundary. If keyid not in the directory: Block.
Step 5: Site Protection Provider (CDN) to Site Protection Provider (CDN): Time window. If Outside the window: Block.
Step 6: Site Protection Provider (CDN) to Site Protection Provider (CDN): Nonce not seen recently. If Nonce seen: Block as replay.
Step 7: Site Protection Provider (CDN) to Site Protection Provider (CDN): Tag is agent-browser-auth. If Other tag: Block or handle as non-TAP traffic.
Step 8: Site Protection Provider (CDN) to Site Protection Provider (CDN): Rebuild signature base and verify Ed25519. If Signature invalid: Block.
Step 9: Site Protection Provider (CDN) to Merchant: Forward, marked as a verified agent. This step crosses a trust boundary.
Source of truth: Participants (external link) Generated from src/content/flows/visa-tap-browsing-verification.json.
Play this flow step by step
AI agent
Checkout Enabler
Site Protection Provider (CDN)
Visa key store
Merchant
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 9AI agent toto Checkout Enabler
Signed GET through a Checkout Enabler
The agent may reach the merchant through a Checkout Enabler.
HTTP payload. Illustrative example, spec version TAP spec, unversioned (read 2026-10-11).
GET /example-product HTTP/1.1
Host: shop.example
Signature-Input: sig2=("@authority" "@path");created=1767225600;keyid="agent-key-1";alg="Ed25519";expires=1767225900;nonce="bm9uY2UtcGxhY2Vob2xkZXI";tag="agent-browser-auth"
Signature: sig2=:c2lnbmF0dXJlLXBsYWNlaG9sZGVy:
Spec version TAP spec, unversioned (read 2026-10-11) (2025-10-14). Sources: [1], [27], [49]
Step 1 of 9: AI agent to Checkout Enabler. Signed GET through a Checkout Enabler. Crosses a trust boundary.
Visa TAP: checkout request and body object verification at the merchant
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The merchant verifies the agent-payer-auth signature, then each signed body object, then processes the payment data according to its processing path: credential hash for key entry, encrypted payload for API checkout.
Text alternative
Sequence diagram: Visa TAP: checkout request and body object verification at the merchant. 4 participants: AI agent, Merchant, Visa key store, and Acquirer and Visa network. 8 steps, 3 crossing a trust boundary, 6 failure branches. Based on visa-tap TAP spec, unversioned (read 2026-10-11) (2025-10-14). Step 1: AI agent to Merchant: POST checkout with agent-payer-auth and body objects. This step crosses a trust boundary. Step 2: Merchant to Merchant: Verify the header signature. If Any check fails: Block the request. Step 3: Merchant to Merchant: Consumer object: fields and nonce. If Missing field or nonce mismatch: Content may be inaccurate. Step 4: Merchant to Visa key store: Locate keys for kid and the ID Token. This step crosses a trust boundary. Step 5: Merchant to Merchant: Verify consumer object and ID Token. If Verification fails: Merchant may still use the data at its discretion. Step 6: Merchant to Merchant: Payment container: fields, nonce, key, signature. If Missing field, nonce mismatch or bad signature: Should not be used for payment. If Key not found: Content may be inaccurate. Step 7: Merchant to Merchant: Process by type. If Hash mismatch: Decline the transaction. Step 8: Merchant to Acquirer and Visa network: Authorize as a card payment. This step crosses a trust boundary.
Step 1: AI agent to Merchant: POST checkout with agent-payer-auth and body objects. This step crosses a trust boundary.
Step 2: Merchant to Merchant: Verify the header signature. If Any check fails: Block the request.
Step 3: Merchant to Merchant: Consumer object: fields and nonce. If Missing field or nonce mismatch: Content may be inaccurate.
Step 4: Merchant to Visa key store: Locate keys for kid and the ID Token. This step crosses a trust boundary.
Step 5: Merchant to Merchant: Verify consumer object and ID Token. If Verification fails: Merchant may still use the data at its discretion.
Step 6: Merchant to Merchant: Payment container: fields, nonce, key, signature. If Missing field, nonce mismatch or bad signature: Should not be used for payment. If Key not found: Content may be inaccurate.
Step 7: Merchant to Merchant: Process by type. If Hash mismatch: Decline the transaction.
Step 8: Merchant to Acquirer and Visa network: Authorize as a card payment. This step crosses a trust boundary.
Spec version TAP spec, unversioned (read 2026-10-11) (2025-10-14). Sources: [1], [10]
Step 1 of 8: AI agent to Merchant. POST checkout with agent-payer-auth and body objects. Crosses a trust boundary.
CDN decision tree for a TAP request
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The order of checks from the Visa specification and Cloudflare's 2025-10-24 post. Every failed check after the tag check blocks; a request without a TAP tag falls back to the site's normal bot policy.
Text alternative
Decision tree. If the signature headers are missing, or the tag is neither agent-browser-auth nor agent-payer-auth, the request is not a TAP agent and gets normal bot policy. Otherwise the CDN blocks when a minimum field is missing, when the window is wrong (created must be past, expires future, at most 8 minutes apart), when the nonce was seen in the last 8 minutes, when the key for keyid cannot be found, or when the signature does not verify. If all pass, a browsing tag is allowed as a trusted agent browsing, and a paying tag is allowed as a trusted agent paying, with the merchant checking the body objects.
TAP versus the Web Bot Auth working group draft: header rules
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Both use RFC 9421, but TAP does not conform to draft-ietf-webbotauth-httpsig-protocol-00. TAP launched almost eleven months before the draft, so the draft is not its basis.
Text alternative
Side-by-side comparison. TAP: tags agent-browser-auth or agent-payer-auth; covers @authority and @path; no Signature-Agent required; keyid is an opaque key id; nonce and alg required; window at most 8 minutes; keys at mcp.visa.com/.well-known/jwks. Web Bot Auth draft -00: tag web-bot-auth; covers @authority or @target-uri plus a signed Signature-Agent header, which is required; keyid is a JWK SHA-256 thumbprint; no nonce required by the draft; expiry of 24 hours or less recommended; keys at /.well-known/http-message-signatures-directory. Each pair differs.
A request reaches the verifier without a Signature-Input tagged agent-browser-auth or agent-payer-auth. Under TAP it was not signed by a trusted agent, and the merchant decides whether to block it.
Text alternative
Sequence diagram: Visa TAP failure: request without a TAP tag. 3 participants: AI agent, Site Protection Provider (CDN), and Merchant. 4 steps, 3 crossing a trust boundary, 1 failure branch. Based on visa-tap TAP spec, unversioned (read 2026-10-11) (2025-10-14). Step 1: AI agent to Site Protection Provider (CDN): GET with no signature, or tag web-bot-auth. This step crosses a trust boundary. Step 2: Site Protection Provider (CDN) to Site Protection Provider (CDN): Look for a TAP tag. If No TAP tag: Not signed by a trusted agent. Step 3: Site Protection Provider (CDN) to Merchant: Apply bot policy. This step crosses a trust boundary. Step 4: Merchant to AI agent: 403 or challenge. This step crosses a trust boundary.
Step 1: AI agent to Site Protection Provider (CDN): GET with no signature, or tag web-bot-auth. This step crosses a trust boundary.
Step 2: Site Protection Provider (CDN) to Site Protection Provider (CDN): Look for a TAP tag. If No TAP tag: Not signed by a trusted agent.
Step 3: Site Protection Provider (CDN) to Merchant: Apply bot policy. This step crosses a trust boundary.
Step 4: Merchant to AI agent: 403 or challenge. This step crosses a trust boundary.
HTTP payload. Illustrative example, spec version TAP spec, unversioned (read 2026-10-11).
GET /example-product HTTP/1.1
Host: shop.example
Spec version TAP spec, unversioned (read 2026-10-11) (2025-10-14). Sources: [1], [27]
Step 1 of 4: AI agent to Site Protection Provider (CDN). GET with no signature, or tag web-bot-auth. Crosses a trust boundary.
Visa TAP failure: validity window too long or expired
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The signature window is checked before the key and the signature. A window over 8 minutes, a created time in the future or an expires time in the past blocks the request. The specification's own example uses a 3,600-second window and would fail this check.
Text alternative
Sequence diagram: Visa TAP failure: validity window too long or expired. 3 participants: AI agent, Site Protection Provider (CDN), and Merchant. 3 steps, 2 crossing a trust boundary, 2 failure branches. Based on visa-tap TAP spec, unversioned (read 2026-10-11) (2025-10-14). Step 1: AI agent to Site Protection Provider (CDN): Signed GET with a 60-minute window. This step crosses a trust boundary. Step 2: Site Protection Provider (CDN) to Site Protection Provider (CDN): Check created and expires. If Interval over 8 minutes: Block. If created in the future or expires in the past: Block. Step 3: Site Protection Provider (CDN) to AI agent: Block. This step crosses a trust boundary.
Step 1: AI agent to Site Protection Provider (CDN): Signed GET with a 60-minute window. This step crosses a trust boundary.
Step 2: Site Protection Provider (CDN) to Site Protection Provider (CDN): Check created and expires. If Interval over 8 minutes: Block. If created in the future or expires in the past: Block.
Step 3: Site Protection Provider (CDN) to AI agent: Block. This step crosses a trust boundary.
Source of truth: Timestamps (external link) Generated from src/content/flows/visa-tap-failure-expired-window.json.
Play this flow step by step
AI agent
Site Protection Provider (CDN)
Merchant
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 3AI agent toto Site Protection Provider (CDN)
Signed GET with a 60-minute window
created and expires are 3,600 seconds apart, as in the specification example.
HTTP payload. Illustrative example, spec version TAP spec, unversioned (read 2026-10-11).
GET /example-product HTTP/1.1
Host: shop.example
Signature-Input: sig2=("@authority" "@path");created=1767225600;keyid="agent-key-1";alg="Ed25519";expires=1767229200;nonce="bm9uY2UtcGxhY2Vob2xkZXI";tag="agent-browser-auth"
Signature: sig2=:c2lnbmF0dXJlLXBsYWNlaG9sZGVy:
Spec version TAP spec, unversioned (read 2026-10-11) (2025-10-14). Sources: [1]
Step 1 of 3: AI agent to Site Protection Provider (CDN). Signed GET with a 60-minute window. Crosses a trust boundary.
Visa TAP failure: replayed nonce
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
An attacker who captured a signed request resends it inside its window. A verifier that keeps nonces from the last 8 minutes blocks it; a verifier that keeps none accepts it, because the signature is still valid.
Text alternative
Sequence diagram: Visa TAP failure: replayed nonce. 3 participants: AI agent, Site Protection Provider (CDN), and Merchant. 4 steps, 3 crossing a trust boundary, 2 failure branches. Based on visa-tap TAP spec, unversioned (read 2026-10-11) (2025-10-14). Step 1: AI agent to Site Protection Provider (CDN): Original signed request. This step crosses a trust boundary. Step 2: Site Protection Provider (CDN) to Merchant: Verified and recorded. This step crosses a trust boundary. Step 3: AI agent to Site Protection Provider (CDN): Same request replayed within 8 minutes. This step crosses a trust boundary. Step 4: Site Protection Provider (CDN) to Site Protection Provider (CDN): Nonce lookup. If Nonce found: Block as replay. If Verifier keeps no nonce record: Replay is accepted; TAP makes the record optional.
Step 1: AI agent to Site Protection Provider (CDN): Original signed request. This step crosses a trust boundary.
Step 2: Site Protection Provider (CDN) to Merchant: Verified and recorded. This step crosses a trust boundary.
Step 3: AI agent to Site Protection Provider (CDN): Same request replayed within 8 minutes. This step crosses a trust boundary.
Step 4: Site Protection Provider (CDN) to Site Protection Provider (CDN): Nonce lookup. If Nonce found: Block as replay. If Verifier keeps no nonce record: Replay is accepted; TAP makes the record optional.
HTTP payload. Illustrative example, spec version TAP spec, unversioned (read 2026-10-11).
GET /example-product HTTP/1.1
Host: shop.example
Signature-Input: sig2=("@authority" "@path");created=1767225600;keyid="agent-key-1";alg="Ed25519";expires=1767225900;nonce="bm9uY2UtcGxhY2Vob2xkZXI";tag="agent-browser-auth"
Signature: sig2=:c2lnbmF0dXJlLXBsYWNlaG9sZGVy:
Spec version TAP spec, unversioned (read 2026-10-11) (2025-10-14). Sources: [1], [27]
Step 1 of 4: AI agent to Site Protection Provider (CDN). Original signed request. Crosses a trust boundary.
Visa TAP alternative path: paid content with HTTP 402 and a browsingIOU
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The merchant asks for payment for a resource with HTTP 402. The agent retries with a payment container that holds a signed browsingIOU. The merchant checks the IOU against its 402 data and the signature, then grants access expecting the funds at settlement, which TAP does not define.
Text alternative
Sequence diagram: Visa TAP alternative path: paid content with HTTP 402 and a browsingIOU. 3 participants: AI agent, Merchant, and Acquirer and Visa network. 6 steps, 5 crossing a trust boundary, 3 failure branches. Based on visa-tap TAP spec, unversioned (read 2026-10-11) (2025-10-14). Step 1: AI agent to Merchant: Signed GET for a paid resource. This step crosses a trust boundary. Step 2: Merchant to AI agent: 402 with invoiceId, amount and CAID. This step crosses a trust boundary. If Agent cannot parse a merchant-specific 402: No IOU; access denied. Step 3: AI agent to Merchant: Retry with agenticPaymentContainer.browsingIOU. This step crosses a trust boundary. Step 4: Merchant to Merchant: Match IOU to the 402 and verify. If Mismatch or bad signature: Deny access. Step 5: Merchant to AI agent: 200 with the resource. This step crosses a trust boundary. Step 6: Merchant to Acquirer and Visa network: Settlement (not specified). This step crosses a trust boundary. If Funds never arrive: No TAP remedy is specified.
Step 1: AI agent to Merchant: Signed GET for a paid resource. This step crosses a trust boundary.
Step 2: Merchant to AI agent: 402 with invoiceId, amount and CAID. This step crosses a trust boundary. If Agent cannot parse a merchant-specific 402: No IOU; access denied.
Step 3: AI agent to Merchant: Retry with agenticPaymentContainer.browsingIOU. This step crosses a trust boundary.
Step 4: Merchant to Merchant: Match IOU to the 402 and verify. If Mismatch or bad signature: Deny access.
Step 5: Merchant to AI agent: 200 with the resource. This step crosses a trust boundary.
Step 6: Merchant to Acquirer and Visa network: Settlement (not specified). This step crosses a trust boundary. If Funds never arrive: No TAP remedy is specified.
HTTP payload. Illustrative example, spec version TAP spec, unversioned (read 2026-10-11).
GET /reviews/123 HTTP/1.1
Host: shop.example
Signature-Input: sig2=("@authority" "@path");created=1767225600;keyid="agent-key-1";alg="Ed25519";expires=1767225900;nonce="bm9uY2UtcGxhY2Vob2xkZXI";tag="agent-browser-auth"
Signature: sig2=:c2lnbmF0dXJlLXBsYWNlaG9sZGVy:
Spec version TAP spec, unversioned (read 2026-10-11) (2025-10-14). Sources: [1]
Step 1 of 6: AI agent to Merchant. Signed GET for a paid resource. Crosses a trust boundary.
Visa Intelligent Commerce link: token, passkey and instruction behind a TAP checkout
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
What happens in VIC around a TAP purchase, using only the endpoint paths in Visa's own API client. The user enrolls a card with step-up verification and a passkey, approves a Payment Instruction with the passkey, the agent retrieves credentials for the purchase, presents them to the merchant in a TAP checkout, and reports the outcome as a confirmation.
Text alternative
Sequence diagram: Visa Intelligent Commerce link: token, passkey and instruction behind a TAP checkout. 4 participants: Consumer, AI agent, Visa Intelligent Commerce, and Merchant. 8 steps, 8 crossing a trust boundary, 2 failure branches. Based on visa-tap TAP spec, unversioned (read 2026-10-11) (2025-10-14). Step 1: Consumer to AI agent: Ask the agent to add a card. This step crosses a trust boundary. Step 2: AI agent to Visa Intelligent Commerce: POST /vacp/v1/cards. This step crosses a trust boundary. If Step-up fails: No token is provisioned. Step 3: AI agent to Visa Intelligent Commerce: POST /vacp/v1/instructions. This step crosses a trust boundary. Step 4: Consumer to AI agent: Approve with a passkey. This step crosses a trust boundary. If User declines: No credentials can be retrieved. Step 5: AI agent to Visa Intelligent Commerce: Pass the passkey result with the instruction. This step crosses a trust boundary. Step 6: AI agent to Visa Intelligent Commerce: POST /vacp/v1/instructions/{instructionId}/credentials. This step crosses a trust boundary. Step 7: AI agent to Merchant: TAP checkout with the payment container. This step crosses a trust boundary. Step 8: AI agent to Visa Intelligent Commerce: POST /vacp/v1/instructions/{instructionId}/confirmations. This step crosses a trust boundary.
Step 1: Consumer to AI agent: Ask the agent to add a card. This step crosses a trust boundary.
Step 2: AI agent to Visa Intelligent Commerce: POST /vacp/v1/cards. This step crosses a trust boundary. If Step-up fails: No token is provisioned.
Step 3: AI agent to Visa Intelligent Commerce: POST /vacp/v1/instructions. This step crosses a trust boundary.
Step 4: Consumer to AI agent: Approve with a passkey. This step crosses a trust boundary. If User declines: No credentials can be retrieved.
Step 5: AI agent to Visa Intelligent Commerce: Pass the passkey result with the instruction. This step crosses a trust boundary.
Step 6: AI agent to Visa Intelligent Commerce: POST /vacp/v1/instructions/{instructionId}/credentials. This step crosses a trust boundary.
Step 7: AI agent to Merchant: TAP checkout with the payment container. This step crosses a trust boundary.
Step 8: AI agent to Visa Intelligent Commerce: POST /vacp/v1/instructions/{instructionId}/confirmations. This step crosses a trust boundary.
Spec version TAP spec, unversioned (read 2026-10-11) (2025-10-14). Sources: [1], [9], [31]
Step 1 of 8: Consumer to AI agent. Ask the agent to add a card. Crosses a trust boundary.
How Visa TAP composes with the other protocols
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
TAP identifies the agent; payment data comes from VIC. Visa's MPP card method may carry TAP headers, Intelligent Commerce Connect accepts TAP, MPP, ACP and UCP payments, and CDNs verify both TAP and Mastercard Agent Pay. Dotted lines are looser links.
Text alternative
Composition diagram. TAP takes payment data from Visa Intelligent Commerce. The Stripe MPP card method, authored by Visa, may add TAP headers. TAP's browsingIOU answers an HTTP 402 but uses a different format from x402. Intelligent Commerce Connect accepts TAP, MPP, ACP and UCP. Cloudflare and Akamai verify TAP and Mastercard Agent Pay, which uses the tag Agent-pay-auth and its own directory. TAP is aligned with but does not conform to the Web Bot Auth draft, which UCP offers as an optional profile.
Spec-deep mode: the full explanation plus 0 field tables and wire examples.
STE mode: section B is hidden; the Simplified Technical English version (section D) is shown first.
This section uses Simplified Technical English (ASD-STE100): short sentences, one instruction per step, and one word for one meaning.
The Visa Trusted Agent Protocol (TAP) helps a merchant to identify an AI agent that Visa approved. The agent signs each HTTP request with a private key. The merchant or its CDN verifies the signature with a public key from Visa. TAP does not move money. TAP is a Visa specification. It is not an IETF standard.
The signature uses RFC 9421. Two HTTP headers carry it: Signature-Input and Signature. The signature includes the host and the path of the request. It also includes a time of creation, a time of expiry, a key identifier, an algorithm, a nonce and a tag.
The tag tells the purpose of the request. The tag agent-browser-auth is for a visit to a product page. The tag agent-payer-auth is for payment. A request without one of these tags does not come from a trusted agent.
At checkout, the agent can add two signed objects to the request body. The consumer object helps the merchant to identify a known customer. The payment container gives the payment data. The agent signs the two objects with the same key and the same nonce as the header signature.
The signature does not include the HTTP method, the query or the body. A signature is valid for a maximum of 8 minutes.
Procedure Verify a TAP request at the edge (CDN operator)
Find the Signature-Input header and the Signature header in the request.
If the tag is not agent-browser-auth or agent-payer-auth, apply your usual bot policy.
Make sure that each minimum field is in the Signature-Input header.
Make sure that the creation time is in the past and the expiry time is in the future.
Make sure that the two times are not more than 8 minutes apart.
Compare the nonce with the nonces of the last 8 minutes.
Get the public key for the keyid value from your cache or from the Visa key store.
Make the signature base again from the covered components and the parameters.
Verify the signature with the public key.
If a check fails, block the request.
If all checks pass, send the request to the merchant as a trusted agent request.
Procedure Accept a TAP checkout (merchant)
Verify the header signature. Make sure that the tag is agent-payer-auth.
Read the agenticConsumer object and the agenticPaymentContainer object from the request body.
Make sure that each object has the minimum fields.
Make sure that the nonce in each object is the same as the nonce in the header.
Get the public key for the kid value of each object.
Verify the signature of each object.
If the payment container is not valid, do not use it for the payment.
If the agent types the card data, make a hash of that data and compare the two hashes.
If the hashes are different, decline the transaction.
If the payment comes through an API, decrypt the payload with your private key.
Send the payment to your acquirer.
Procedure Sign a TAP request (agent platform)
Get a signing key through the Visa onboarding process.
Make a new nonce for the session.
Set the creation time to the time now.
Set the expiry time to not more than 8 minutes after the creation time.
Select the tag agent-browser-auth for a product page.
Select the tag agent-payer-auth for a checkout page.
Make the signature base from the host, the path and the parameters.
Sign the signature base with your private key.
Put the signature in the Signature-Input header and the Signature header.
Sign each checkout body object with the same key and the same nonce.
Technical nouns and technical verbs
agent recognition signature: The RFC 9421 signature that the agent puts in the HTTP headers of each request.
tag: The signature parameter that tells the purpose of the request: a visit to a product page or a payment.
nonce: A value that identifies the session. All signatures of one interaction use the same nonce.
key store: The web location where Visa publishes the public keys for verification.
signature base: The exact text that the agent signs and that the verifier makes again.
consumer recognition object: The signed body object that helps the merchant to identify a known customer.
payment container: The signed body object that contains the payment data.
browsing IOU: A signed promise to pay that the agent sends after the merchant sends status 402.
Site Protection Provider: A CDN or proxy in front of the merchant site. It can verify signatures for the merchant.
verify (TV): To make sure that a signature is correct with the public key.
sign (TV): To make a signature with a private key.
STE check report
Sentences
79
Longest procedural sentence
18 words (limit 20)
Longest descriptive sentence
21 words (limit 25)
Flags
None
Written to the public ASD-STE100 Issue 9 writing rules. Vocabulary not checked against the official dictionary.
Compare with the practitioner text side by side
Practitioner text (section B)
Visa's Trusted Agent Protocol (TAP) answers one question for a merchant: is this automated request from an AI (artificial intelligence) agent that a payment network has approved, and does the agent want to browse or to pay? The agent signs each HTTP (Hypertext Transfer Protocol) request with RFC (Request for Comments) 9421 HTTP Message Signatures and puts a tag in the signature: `agent-browser-auth` for browsing, `agent-payer-auth` for checkout and payment. The merchant, or a CDN (content delivery network) in front of it, fetches the agent's public key from the network's key directory, checks a validity window of at most 8 minutes and a nonce, rebuilds the signed text and verifies the signature. At checkout the same key can sign two JSON (JavaScript Object Notation) objects in the request body, one that helps the merchant recognize the consumer and one that carries payment data. What TAP does not give you: a payment, the user's consent, spending limits or a liability rule. The money moves through Visa Intelligent Commerce tokens and ordinary card processing, and the user's approval lives there too. TAP is a Visa specification under Visa's own terms, not an IETF (Internet Engineering Task Force) standard.
Merchants and the services that protect their sites have long classed automated traffic as bots and blocked most of it, and an agent shopping for a real cardholder arrives as exactly that kind of traffic. Visa's launch release quoted Adobe data that AI-driven traffic to US retail sites rose more than 4,700 percent in the year to August 2025. Visa said on 2025-11-20 that malicious bot-initiated transactions had risen 25 percent over six months, and 40 percent in the US. Neither figure measures TAP traffic; they describe the problem TAP was built for.
Simplified Technical English
The Visa Trusted Agent Protocol (TAP) helps a merchant to identify an AI agent that Visa approved. The agent signs each HTTP request with a private key. The merchant or its CDN verifies the signature with a public key from Visa. TAP does not move money. TAP is a Visa specification. It is not an IETF standard.
The signature uses RFC 9421. Two HTTP headers carry it: Signature-Input and Signature. The signature includes the host and the path of the request. It also includes a time of creation, a time of expiry, a key identifier, an algorithm, a nonce and a tag.
The tag tells the purpose of the request. The tag `agent-browser-auth` is for a visit to a product page. The tag `agent-payer-auth` is for payment. A request without one of these tags does not come from a trusted agent.
E. Main personas
CDN or bot-management engineer
Runs the Site Protection Provider in front of merchant sites and verifies TAP signatures at the edge on the merchant's behalf. Source [1, 10, 27, 28]
Goals
Let approved shopping agents through without opening the door to bots
Verify signatures fast enough to sit on every request
Give merchants one rule that covers Visa and Mastercard agents
Pains
Two networks with two directories and different tags
A key store whose single RSA key does not match the Ed25519 examples
Nonce records that must be shared across edge locations
Implements
The header checks: tag, minimum fields, window, nonce, key, signature
Key caching by keyid with refresh from the Visa JWKS
Logging of verification outcomes for the zone owner
Must trust
Visa's onboarding of agents and its key store
Checkout Enablers to pass headers through unchanged
Its own RFC 9421 implementation to match the agents' serialization
Questions, first steps, metrics and a day in the life
Questions they ask
Where do production agent keys come from, if not the published JWKS?
Must I keep nonces, given that TAP makes it optional?
How do I treat a request that carries both a TAP and a Web Bot Auth signature?
First three steps
Read the TAP specification's verification steps and Cloudflare's 2025-10-24 post
Fetch https://mcp.visa.com/.well-known/jwks and inspect what it holds
Build a verifier that blocks windows over 8 minutes and repeated nonces
Metrics they care about
Share of agent traffic with a valid TAP signature
Verification latency at the edge
Blocks by reason (tag, window, nonce, key, signature)
A day in the life
Ana runs bot management for a CDN. A retail customer wants shopping agents in and scrapers out. She turns on TAP verification: the edge reads Signature-Input, checks the tag, the 8-minute window and the nonce, fetches the key for keyid and verifies the signature. On day one the dashboard shows a spike of requests tagged web-bot-auth from an agent that copied Cloudflare's example, and she routes them to the normal bot policy. She also notices the Visa key store holds one RSA key, so she asks Visa how production keys reach her edge. Until she gets an answer, she keeps the rule in log-only mode.
Runs a large online store that wants to serve Visa-approved agents, recognize returning customers and take payment data in a signed container. Source [1, 5, 24, 27]
Goals
Sell to customers who shop through agents
Recognize returning customers from the ID Token
Reduce fraud on agent checkouts
Pains
Proprietary terms that require updates within six months
No test vectors for the body object signatures
Personal data in contextualData that brings privacy duties
Implements
Verification of agenticConsumer and agenticPaymentContainer
A mapping table from obfuscated email and phone values to accounts
Decryption of the payment payload with a key onboarded to Visa
Must trust
Its CDN's verification of the header signature
Visa's ID Token and key store
The acquirer and card rules for liability, since TAP sets none
Questions, first steps, metrics and a day in the life
Questions they ask
Do I verify the body objects myself or does my CDN do it?
What happens to a chargeback on an agent purchase?
How do I hash key-entered card data the same way Visa does?
First three steps
Accept the Product Terms and read the merchant specification
Ask the CDN to turn on TAP verification in log-only mode
Onboard a merchant public key for the encrypted payload
Metrics they care about
Agent checkout conversion
Fraud and chargeback rate on agent orders
Share of agent orders matched to existing accounts
A day in the life
Malik leads payments at a fashion retailer. Agents were tripping the bot wall at checkout, so he asks the CDN to let TAP-signed requests through. His team then builds the merchant side: compare each body object's nonce with the header nonce, verify the signatures, and decrypt the payload. The ID Token does not give emails in the clear, so they build a table that maps obfuscated values to existing accounts. Legal asks who carries a dispute on an agent order. He finds no agent-specific rule from Visa and books the orders as ordinary tokenized card-not-present sales for now.
Operates the AI agent as an Agent Provider onboarded to Visa Intelligent Commerce and signs every merchant request with its registered key. Source [1, 4, 6, 9]
Goals
Get past merchant bot defenses
Complete purchases with VIC credentials
Keep one signing setup across Visa and Mastercard
Pains
The client implementation guide is only for onboarded agents
Body object signing has no canonical form or test vector
Two networks with different tags and directories
Implements
RFC 9421 signing with the TAP tags and an 8-minute window
Signed agenticConsumer and agenticPaymentContainer objects
VIC calls for card enrollment, instructions, credentials and confirmations
Must trust
Visa to keep its key in the key store
Checkout Enablers and CDNs to pass headers intact
Merchants to treat the consumer data with care
Questions, first steps, metrics and a day in the life
Questions they ask
Which merchants verify TAP today?
How should I serialize the body object signature base?
Must I send both a TAP and a Web Bot Auth signature?
First three steps
Apply for VIC onboarding and obtain the client guide
Sign browsing requests with agent-browser-auth against a test merchant
Add the payment container at checkout with the same key and nonce
Metrics they care about
Agent checkouts blocked by bot defenses
Checkout success rate per merchant
Signature verification failures reported by merchants
A day in the life
Priya builds the shopping agent for an AI assistant. After VIC onboarding, her agent signs each product page request with agent-browser-auth and each checkout with agent-payer-auth, inside an 8-minute window. Checkout also needs the two signed objects, and her first build fails at a merchant because the merchant joined the fields in a different order. With no test vector in the specification, she agrees a byte format with that merchant and files the question with Visa. The user's passkey approval sits in VIC, so her agent never asks for a card number.
Issues the Visa cards that VIC tokenizes for agents and decides on authorization, without seeing the TAP signature itself. Source [7, 9, 24, 40]
Goals
Approve legitimate agent purchases
Keep step-up and passkey checks effective
Know which transactions an agent started
Pains
No public agent transaction indicator from Visa
No agent-specific liability rule
Customers who dispute what their agent bought
Implements
Step-up verification and passkey setup for agent tokens through VIC
Risk rules for agent-specific tokens
Agentic Ready participation
Must trust
Visa's onboarding of agents
Merchants and CDNs to verify TAP
VIC confirmations as evidence in disputes
Questions, first steps, metrics and a day in the life
Questions they ask
Can I tell a TAP-verified purchase in the authorization message?
Who carries the loss when an agent misreads the user?
What does the passkey approval prove in a dispute?
First three steps
Join Visa's Agentic Ready program
Review how VIC step-up and passkeys work for my cardholders
Map agent token transactions in fraud monitoring
Metrics they care about
Approval rate on agent tokens
Fraud and dispute rate on agent purchases
Passkey enrollment rate
A day in the life
Lena runs digital fraud at a European bank in the Agentic Ready program. Her cardholders now link cards to shopping agents: VIC runs step-up verification, the user sets up a passkey, and the agent gets its own token. When a purchase arrives she sees a token transaction, not the merchant's TAP check, so she relies on Visa's signals. A customer disputes a hotel booking made by an agent. The passkey approval of the Payment Instruction helps, but no agent-specific liability rule exists yet, so the case runs under the usual card rules.
Visa itself: writes the specification, onboards agents, hosts the key store and signs the ID Token. Source [3, 6, 7, 10, 14]
Goals
Make agent commerce on Visa credentials safe enough for merchants to allow it
Keep agent identity tied to VIC participation
Align with standards bodies over time
Pains
A competing Mastercard design with another tag and directory
Criticism of proprietary terms and an unversioned specification
A sample repository that has not changed since 2025-10-28
Implements
The TAP specification and Product Terms
The key store at mcp.visa.com
The Agentic Directory and Agent Score
Must trust
Agent Providers to protect their signing keys
CDNs to verify correctly
Merchants to handle consumer data lawfully
Questions, first steps, metrics and a day in the life
Questions they ask
When does TAP get a version number and test vectors?
Can the key store be shared across payment schemes?
How does TAP map to the IETF Web Bot Auth draft?
First three steps
Publish versioned specifications and test vectors
Publish the production key distribution model
Bring the sample code to RFC 9421 conformance
Metrics they care about
Merchants verifying TAP
Agent transactions on VIC
Disputes and fraud on agent transactions
A day in the life
Tom works on the agentic commerce team at Visa. TAP launched on 2025-10-14 with twelve partners and Cloudflare, and by 2026-07-02 agents completed live purchases at named European merchants. His inbox holds the hard questions: why the key store has one sandbox RSA key, why the examples cannot verify, and why community fixes sit unmerged. He also follows the IETF Web Bot Auth draft, which differs from TAP in tags and key discovery. He drafts a plan for a versioned specification with test vectors and a public directory.
Designs fraud rules for a merchant or acquirer and decides how much a valid TAP signature should lower friction. Source [1, 14, 25]
Goals
Separate approved agents from malicious bots
Stop replay and relay of signed requests
Detect card testing through agents
Pains
Signatures that do not cover the method, query or body
Optional nonce tracking
Consumer data that may be used even when unverified
Implements
Rules that combine TAP results with other bot signals
Nonce storage and replay alerts
Credential hash comparison at key-entered checkout
Must trust
The CDN's verification results
Visa's agent onboarding
VIC's passkey approval of the user's instruction
Questions, first steps, metrics and a day in the life
Questions they ask
Is a valid browse signature enough to skip a challenge?
What should I do with a payment container whose key I cannot find?
Can an unsalted credential hash leak card data?
First three steps
Log TAP verification results next to existing bot scores
Turn on nonce tracking with an 8-minute retention
Treat unverified consumer data as untrusted in risk scoring
Metrics they care about
Fraud rate on TAP-verified versus unverified traffic
Replay attempts blocked
False declines on agent checkouts
A day in the life
Sam tunes fraud rules for an acquirer's merchants. A valid TAP signature proves an approved agent signed this host and path in the last 8 minutes, but nothing about the method or body. He scores TAP as one strong signal among others, keeps nonce records so a copied request fails, and refuses payment containers that fail verification. When a merchant asks to use unverified consumer data to skip login, he says no. He also flags the credential hash: without a stated salt, the hash of a card number and a three-digit code is weak.
Defines agentic payments as transactions started and completed by AI agents, sets out how they work across retail, e-commerce and decentralized finance, and classifies their technical, legal and societal risks, including liability gaps and regulatory non-compliance.
Why it matters here: One of the few peer-reviewed legal analyses aimed at agent payments specifically, useful for the compliance and liability questions every protocol in the atlas leaves to implementers. AP2: Risks and regulation of agent payments. Mastercard Agent Pay: Survey of risks and regulation for AI agents in payments that covers card-network programs. Agentic Commerce Protocol (ACP): Risks and regulation of AI agents in payments, covering ACP.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@article{amariles2026payments,
title = {{AI Agents in Payments: Applications, Risks and Regulations}},
author = {David Restrepo Amariles and Damien Charlotin and Liyun He-Guelton},
year = {2026},
journal = {European Journal of Risk Regulation},
volume = {17},
number = {3},
pages = {884--907},
publisher = {Cambridge University Press},
doi = {10.1017/err.2026.10103},
url = {https://doi.org/10.1017/err.2026.10103}
}
Defines the agentic clearing problem, deciding whether an agent met its delegated obligation and which settlement action follows, and argues that MCP, A2A, x402, AP2 and the Visa and Mastercard network agent protocols all assume that determination without producing it. RAILS specifies seven primitives and a formal model of admissibility-graded verification yielding a soundness property that no financially material settlement rests on evidence below the obligation's admissibility floor. The abstract names Visa and Mastercard generically rather than by protocol name.
Why it matters here: Names x402, ap2 and the Visa and Mastercard agent programs as rails that lack a clearing layer; useful for the atlas comparison of where disputes and fulfillment evidence live. Visa Trusted Agent Protocol: The only paper found that names TAP; places it as the network's edge attestation layer.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{valoisfranklin2026rails,
title = {{RAILS: Verification-Native Clearing For Agentic Commerce}},
author = {Adrian de Valois-Franklin and Alex Bogdan},
year = {2026},
eprint = {2606.08790},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2606.08790}
}
Argues that Know Your Agent regimes modeled on human identity verification and credit scores are incomplete because language model agents are assemblages of mutable modules (models, prompts, tool policies, memory) with fluid personas that may not internalize sanctions, so identifiability, predictability, credibility and rehabilitability lack grounding. It proposes observability-based, ex ante, protocol-level behavioral harnesses in place of ex post reputation.
Why it matters here: A direct critique of the premise behind ERC-8004's Reputation Registry and of KYA-style identity checks in TAP and Agent Pay: if the sanctioned identity can be swapped out, reputation does not discipline the agent. ERC-8004: Trustless Agents: Questions whether LLM agents have the stable identity reputation needs.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{hu2026dissociative,
title = {Dissociative Identity: Language Model Agents Lack Grounding for Reputation Mechanisms},
author = {Botao Amber Hu and Helena Rong and Max Van Kleek},
year = {2026},
booktitle = {Proceedings of the 2026 ACM Conference on Fairness, Accountability, and Transparency (FAccT '26)},
publisher = {ACM},
pages = {4199-4219},
doi = {10.1145/3805689.3806748},
eprint = {2605.30169},
archivePrefix = {arXiv},
url = {https://arxiv.org/abs/2605.30169}
}
Specifies OpenID Connect for Agents (OIDC-A) 1.0, an extension to OpenID Connect Core that adds standard claims, endpoints and flows for agent identity, attestation verification, delegation-chain validation and capability-based authorization while staying compatible with OAuth 2.0 infrastructure. A specification proposal is published on GitHub.
Why it matters here: A concrete OIDC-based alternative to the HTTP message signature approach of visa-tap and to the mandate chain in ap2. AP2: Agent identity extension for OpenID Connect.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{nagabhushanaradhya2025oidca,
title = {{OpenID Connect for Agents (OIDC-A) 1.0: A Standard Extension for LLM-Based Agent Identity and Authorization}},
author = {Subramanya Nagabhushanaradhya},
year = {2025},
eprint = {2509.25974},
archivePrefix = {arXiv},
primaryClass = {cs.NI},
url = {https://arxiv.org/abs/2509.25974}
}
Gives the first provable-security analysis of FIDO2, covering WebAuthn and the CTAP2 authenticator protocol; it proves security properties of WebAuthn, finds weaknesses in CTAP2 and proposes a stronger replacement.
Why it matters here: Passkey and FIDO-based consent is how card networks propose to confirm a cardholder before an agent pays; this paper pins down what the underlying protocol does and does not guarantee. Mastercard Agent Pay: Security analysis of FIDO2, the basis of the passkeys used for Agent Pay consent.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{barbosa2021fido2,
title = {{Provable Security Analysis of FIDO2}},
author = {Manuel Barbosa and Alexandra Boldyreva and Shan Chen and Bogdan Warinschi},
year = {2021},
booktitle = {Advances in Cryptology -- CRYPTO 2021},
series = {Lecture Notes in Computer Science},
pages = {125--156},
publisher = {Springer},
eprint = {2020/756},
doi = {10.1007/978-3-030-84252-9_5},
url = {https://doi.org/10.1007/978-3-030-84252-9_5}
}
John R. Douceur. 2002. IPTPS 2002 (1st International Workshop on Peer-to-Peer Systems), Lecture Notes in Computer Science, Springer, pp. 251-260. Peer reviewedDOI 10.1007/3-540-45748-8_24 (external link)
Shows that in a large peer-to-peer system without a logically centralized authority, a single faulty entity can present many identities and defeat the redundancy the system relies on, and that such Sybil attacks remain possible except under unrealistic assumptions of resource parity and coordination among entities.
Why it matters here: Defines the attack every permissionless agent registry inherits: ERC-8004 identities and feedback without a trusted issuer are exposed to it, which is why TAP and the card networks keep a certifying authority in the loop. ERC-8004: Trustless Agents: The original Sybil attack result behind the reviewer-filter design.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{douceur2002sybil,
title = {The Sybil Attack},
author = {John R. Douceur},
year = {2002},
booktitle = {Peer-to-Peer Systems: First International Workshop (IPTPS 2002)},
series = {Lecture Notes in Computer Science},
publisher = {Springer},
pages = {251-260},
doi = {10.1007/3-540-45748-8_24},
url = {https://www.microsoft.com/en-us/research/publication/the-sybil-attack/}
}
Presents a conceptual framework and prototype in which each agent holds a ledger-anchored W3C Decentralized Identifier and third-party-issued Verifiable Credentials, so agents can authenticate and establish cross-domain trust at the start of a dialogue. Evaluation shows feasibility but also limits when the agent's LLM alone controls the security procedures. The arXiv preprint is dated 2025; the ICAART proceedings appeared in 2026.
Why it matters here: Peer-reviewed DID and VC approach to agent identity that contrasts with the on-chain registry model of erc-8004 and the network-issued credentials of visa-tap. ERC-8004: Trustless Agents: DID and verifiable credential alternative to registry identity.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{garzon2026didvc,
title = {{AI Agents with Decentralized Identifiers and Verifiable Credentials}},
author = {Sandro Rodriguez Garzon and Awid Vaziry and Enis Mert Kuzu and Dennis Enrique Gehrmann and Buse Varkan and Alexander Gaballa and Axel Küpper},
year = {2026},
booktitle = {Proceedings of the 18th International Conference on Agents and Artificial Intelligence (ICAART 2026), Volume 1},
publisher = {SCITEPRESS},
pages = {252-259},
doi = {10.5220/0014234400004052},
eprint = {2511.02841},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2511.02841}
}
Replays 4,371 human-written attacks from a capture-the-flag event against a live payment agent across 14 models, five policy levels and two tracks, with and without a deterministic pre-action check implementing the author's Open Agent Passport specification. Transfers to recipients the passport did not permit occurred 140 times in 76,842 model-alone evaluations and zero times in 69,297 behind the layer, while 25,370 legitimate payments still executed.
Why it matters here: A benchmark of the authorization boundary that AP2 mandates, x402 payment headers and TAP delegation all depend on: deterministic policy enforcement outside the model stopped recipient hijacks that prompting alone did not. The Open Agent Passport is the author's own specification, so read the comparison with that in mind.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{uchibeke2026aport,
title = {APort Vault: Benchmarking AI Agent Payment Authorization with the Open Agent Passport},
author = {Uchi Uchibeke},
year = {2026},
eprint = {2609.22076},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.22076},
note = {arXiv preprint}
}
A structured narrative review of 89 sources from 2023 to 2026 on authorization for tool-using agents, organized around a principal hierarchy (human, operator, orchestrator, sub-agent, tool endpoint) and five layers: identity and credential lifecycle, multi-hop delegation and scope propagation, runtime enforcement at policy enforcement points, prompt injection as authorization bypass, and auditability. It derives seven structural requirements and a four-layer reference architecture.
Why it matters here: A map of the delegation literature that the mandate chains of ap2 and the agent identity in visa-tap and openai-acp draw on.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{surapani2026authorization,
title = {{Authorization Architectures for Tool-Using AI Agents}},
author = {Rakesh Kumar Surapani and Pradeep Kumar Dolabehera Kakitapelli and Arun Morampudi and Praveena Padi},
year = {2026},
eprint = {2609.15906},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.15906}
}
BIND binds a user's biometric data to an AI agent identifier and authority scope at authorization time using a fuzzy commitment over face features with turbo error-correcting codes, so an identity auditor can authenticate the user and recover the agent ID and scope, giving non-repudiable proof of human delegation; experiments report a 96% true match rate at zero false matches with 1024-bit agent tokens. The arXiv comment reports acceptance at IJCB 2026; no publisher record confirms it yet.
Why it matters here: A biometric route to the human-presence and delegation evidence that visa-tap consumer recognition and ap2 mandates rely on.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{benjamin2026bind,
title = {{Binding Biometrics with AI Agent Identifiers for Delegation of Authority}},
author = {Joseph Geo Benjamin and Anil K Jain and Karthik Nandakumar},
year = {2026},
eprint = {2608.04292},
archivePrefix = {arXiv},
primaryClass = {cs.CV},
url = {https://arxiv.org/abs/2608.04292}
}
Proposes Issuer-Sovereign Agentic Payments, in which the cardholder approves a spending rule once with the issuing bank's own authentication component, and at payment time the bank checks the merchant against that rule and generates the card authentication value only if allowed, so the transaction rides normal card rails with issuer validation and no extra execution-time dependency.
Why it matters here: A counterproposal to network-led designs such as visa-tap and mastercard-agent-pay, where spending controls are enforced by the network or a credential provider rather than the issuer. Mastercard Agent Pay: Closest academic work to Agent Pay: issuer control over agent payments. No paper analyzes Agent Pay or Verifiable Intent directly. Visa Trusted Agent Protocol: Argues for issuer-side controls, contrasting with network-run agent recognition.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{sharma2026issuer,
title = {{Issuer-Sovereign Agentic Payments}},
author = {Dishant Sharma and Rajneesh Kaushal and Ashu Kanaujia},
year = {2026},
eprint = {2609.27452},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.27452}
}
Introduces multi-step indirect prompt injection, in which an adversarial goal is split into innocuous sub-steps spread across pages along the agent's navigation path, and a benchmark of 480 cases. Across six computer-use agents, decomposition raises attack success, for one model from 41.7 percent single-step to 72.9 percent at three steps.
Why it matters here: Computer-use agents that shop across several merchant pages are the deployment TAP and Agent Pay credentials are issued to; staged injections evade per-page defenses.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{zhan2026stepjack,
title = {StepJack: Benchmarking Computer-Use Agent Safety Against Multi-Step Indirect Prompt Injection},
author = {Zhuoxin Zhan and Akbar Rafiey and Avery Ma and Leila Pishdad and Layla El Asri},
year = {2026},
eprint = {2608.06477},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2608.06477},
note = {arXiv preprint}
}
Proposes the Verifiable Action Card, which rebuilds the confirmation prompt in an agentic browser from the action that will actually execute, shows it in trusted browser chrome and binds approval to that exact action at dispatch. On a 24-scenario benchmark it cuts attack success from 68% to 100% down to 0% across the tested models.
Why it matters here: Human confirmation is the step-up that card agent programs and AP2 rely on for higher-risk purchases; this shows how that confirmation can be forged and one way to bind it to the real transaction.
Metadata verified 2026-10-11 through arxiv.
Show BibTeX
@misc{irshad2026vac,
title = {{The Verifiable Action Card: Trustworthy Human-in-the-Loop Control for Secure Autonomous Agents}},
author = {Hasnain Irshad and Anam Mughees and Neelam Mughees and Abdullah Mughees and Imtiaz Ali Soomro},
year = {2026},
eprint = {2609.18411},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.18411}
}
Proposes an evaluation that scores trust (nothing happens the user did not agree to, including spend limits and ignoring strangers' instructions) and task completion on the same runs in a simulated world of businesses with websites, inboxes and phone lines. The authors' assistant harness completes 71 percent of errands and keeps trust on 94 percent of trap runs versus 50 to 64 and 59 to 75 percent for base models; the study is a vendor evaluating its own product.
Why it matters here: Operationalizes the consumer-side guarantees that delegation designs such as AP2 intent and cart mandates and TAP promise, and shows how much of the result comes from the harness rather than the model.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{olieslagers2026trust,
title = {Trust and Task Completion in the World of Consumer AI Agents},
author = {Jeroen Olieslagers and Eduardo Pujol and Gal Zahavi and Lukas Ingemarsson and Shivani Poddar},
year = {2026},
eprint = {2609.33017},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2609.33017},
note = {arXiv preprint}
}
Argues that OAuth, OIDC and SAML style IAM is inadequate for ephemeral, interdependent AI agents and proposes a framework built on verifiable agent identities using DIDs and VCs, an Agent Naming Service for discovery, fine-grained dynamic access control, a global session and policy enforcement layer for revocation, and zero-knowledge proofs for selective disclosure.
Why it matters here: A frequently cited zero-trust identity blueprint that overlaps with the discovery and identity roles of erc-8004 and the agent recognition goals of visa-tap. Visa Trusted Agent Protocol: A decentralized alternative to a network-controlled agent identity.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{huang2025zerotrust,
title = {{A Novel Zero-Trust Identity Framework for Agentic AI: Decentralized Authentication and Fine-Grained Access Control}},
author = {Ken Huang and Vineeth Sai Narajala and John Yeoh and Jason Ross and Ramesh Raskar and Youssef Harkati and Jerry Huang and Idan Habler and Chris Hughes},
year = {2025},
eprint = {2505.19301},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2505.19301}
}
Introduces Agentic JWT, an intent token that binds each agent action to verifiable user intent and optionally to a workflow step, carrying an agent identity hash derived from prompt, tools and configuration, a chained delegation assertion and per-agent proof-of-possession keys, with a Python proof of concept that blocks scope violations, replay, impersonation and prompt-injection paths.
Why it matters here: An OAuth-aligned intent token that parallels the mandate concept in ap2 and the agent identity assertions in visa-tap.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{goswami2025agenticjwt,
title = {{Agentic JWT: A Secure Delegation Protocol for Autonomous AI Agents}},
author = {Abhishek Goswami},
year = {2025},
eprint = {2509.13597},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2509.13597}
}
Proposes a framework for authenticated, authorized and auditable delegation of authority from humans to AI agents, extending OAuth 2.0 and OpenID Connect with agent-specific credentials and metadata, and a method for translating natural-language permissions into auditable access control configurations.
Why it matters here: The reference design for delegation chains that ap2 mandates, visa-tap agent identity and openai-acp checkout each assume but implement differently. AP2: Delegation credentials for agents, the idea behind open mandates. Visa Trusted Agent Protocol: Delegated agent credentials, the user-to-agent link that TAP leaves to VIC.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{south2025delegation,
title = {{Authenticated Delegation and Authorized AI Agents}},
author = {Tobin South and Samuele Marro and Thomas Hardjono and Robert Mahari and Cedric Deslandes Whitney and Dazza Greenwood and Alan Chan and Alex Pentland},
year = {2025},
eprint = {2501.09674},
archivePrefix = {arXiv},
primaryClass = {cs.CY},
url = {https://arxiv.org/abs/2501.09674}
}
Buys traffic from 20 bot services against a honey site protected by two commercial anti-bot products and finds that about half the requests evade detection by altering browser fingerprints; inconsistencies among altered attributes then help detect them.
Why it matters here: Measures how weak fingerprint-based bot detection is, which is the problem Visa TAP and Mastercard Agent Pay address by having trusted agents sign their requests instead of hiding as browsers. Visa Trusted Agent Protocol: Why fingerprint-based bot detection fails and cryptographic agent identity appeals.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{venugopalan2025fpinconsistent,
title = {{FP-Inconsistent: Measurement and Analysis of Fingerprint Inconsistencies in Evasive Bot Traffic}},
author = {Hari Venugopalan and Shaoor Munir and Shuaib Ahmed and Tangbaihe Wang and Samuel T. King and Zubair Shafiq},
year = {2025},
booktitle = {Proceedings of the 2025 ACM Internet Measurement Conference},
pages = {134--149},
publisher = {ACM},
doi = {10.1145/3730567.3732919},
url = {https://doi.org/10.1145/3730567.3732919}
}
Ivan Evtimov, Arman Zharmagambetov, Aaron Grattafiori and others. 2025. NeurIPS 2025 Datasets and Benchmarks Track (poster). Peer reviewedarXiv 2504.18575 (open access, external link)
An end-to-end benchmark for web agents facing realistic, low-effort human-written injections in tasks such as paying bills. Even top reasoning models were partially deceived in up to 86 percent of cases yet rarely completed the attacker's full goal, which the authors call security by incompetence.
Why it matters here: Web agents that pay bills are the use case TAP and AP2 target; WASP's finding that attacks succeed partially but not fully is a warning that capability gains will remove the accidental protection.
Metadata verified 2026-10-10 through publisher.
Show BibTeX
@inproceedings{evtimov2025wasp,
title = {WASP: Benchmarking Web Agent Security Against Prompt Injection Attacks},
author = {Ivan Evtimov and Arman Zharmagambetov and Aaron Grattafiori and Chuan Guo and Kamalika Chaudhuri},
year = {2025},
booktitle = {Advances in Neural Information Processing Systems 38 (NeurIPS 2025), Datasets and Benchmarks Track},
url = {https://openreview.net/forum?id=Ip1cCUAllL},
eprint = {2504.18575},
archivePrefix = {arXiv}
}
Introduces indirect prompt injection: adversaries plant instructions in data that an LLM-integrated application will retrieve, so the model is attacked without any direct interface. The paper gives a security taxonomy of impacts, including data theft, worming and contamination of the information ecosystem, and demonstrates attacks on real systems.
Why it matters here: The founding paper for the threat every agentic payment protocol must contain; AP2 mandates, x402 pre-execution filters, TAP intent signatures and ACP's structured checkout all exist partly because retrieved merchant content can hijack the buying agent. Agentic Commerce Protocol (ACP): Indirect prompt injection, relevant to merchant text rendered by the agent.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{greshake2023injection,
title = {Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection},
author = {Kai Greshake and Sahar Abdelnabi and Shailesh Mishra and Christoph Endres and Thorsten Holz and Mario Fritz},
year = {2023},
booktitle = {Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security (AISec '23)},
publisher = {ACM},
pages = {79-90},
doi = {10.1145/3605764.3623985},
eprint = {2302.12173},
archivePrefix = {arXiv},
url = {https://arxiv.org/abs/2302.12173}
}
Analyzes relay attacks on contactless EMV, including a relay of Apple Pay transit transactions to locked iPhones, and proposes a relay protection protocol with a formal proof that would fit within existing EMV deployments.
Why it matters here: Relay is the card-present version of an agent acting far from the cardholder; the paper shows why binding a payment to its context, not just to valid credentials, matters. Mastercard Agent Pay: Relay protection in EMV; background for binding a token to an authorized interaction.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{radu2022relay,
title = {{Practical EMV Relay Protection}},
author = {Andreea-Ina Radu and Tom Chothia and Christopher J.P. Newton and Ioana Boureanu and Liqun Chen},
year = {2022},
booktitle = {2022 IEEE Symposium on Security and Privacy (SP)},
pages = {1737--1756},
publisher = {IEEE},
doi = {10.1109/SP46214.2022.9833642},
url = {https://doi.org/10.1109/SP46214.2022.9833642}
}
Shows that an attacker can make a terminal treat a Mastercard contactless card as a Visa card, routing the transaction so that the earlier Visa PIN bypass applies; the authors demonstrated it with an Android app in real transactions.
Why it matters here: A mismatch between card brand and network routing breaks assumptions on both sides; agent payment designs that span Visa and Mastercard credentials must bind the brand and network explicitly. Mastercard Agent Pay: Cross-brand confusion attacks; relevant where Mastercard and Visa agent tokens travel through the same SPT and edge.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@inproceedings{basin2021mixup,
title = {{Card Brand Mixup Attack: Bypassing the PIN in non-Visa Cards by Using Them for Visa Transactions}},
author = {David Basin and Ralf Sasse and Jorge Toro-Pozo},
year = {2021},
booktitle = {30th USENIX Security Symposium (USENIX Security 21)},
publisher = {USENIX Association},
url = {https://www.usenix.org/conference/usenixsecurity21/presentation/basin}
}
Builds a Tamarin model of the EMV contactless protocol and finds that unauthenticated card data lets an attacker bypass the PIN for high-value Visa contactless payments; the authors propose and verify fixes that terminals can deploy.
Why it matters here: The method, formal modeling of a payment network protocol that exposes a deployable attack, is what recent work applies to agent payment specs; it also shows how fragile unauthenticated fields are. Mastercard Agent Pay: Formal analysis of EMV, the card protocol family behind the tokens and cryptograms Agent Pay relies on.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{basin2021emv,
title = {{The EMV Standard: Break, Fix, Verify}},
author = {David Basin and Ralf Sasse and Jorge Toro-Pozo},
year = {2021},
booktitle = {2021 IEEE Symposium on Security and Privacy (SP)},
pages = {1766--1781},
publisher = {IEEE},
doi = {10.1109/SP40001.2021.00037},
url = {https://doi.org/10.1109/SP40001.2021.00037}
}
Presents Privacy Pass, in which a client solves one challenge, receives blindly signed tokens, and redeems them later to skip further challenges without the server linking redemptions to issuance.
Why it matters here: Privacy Pass is the earlier anonymous-token approach to telling trusted clients from bots; Visa TAP instead identifies agents with signed HTTP messages, and comparing the two shows the trade between accountability and privacy. Visa Trusted Agent Protocol: Privacy Pass, a CDN-world alternative for telling clients apart without identifying them.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@article{davidson2018privacypass,
title = {{Privacy Pass: Bypassing Internet Challenges Anonymously}},
author = {Alex Davidson and Ian Goldberg and Nick Sullivan and George Tankersley and Filippo Valsorda},
year = {2018},
journal = {Proceedings on Privacy Enhancing Technologies},
volume = {2018},
number = {3},
pages = {164--180},
doi = {10.1515/popets-2018-0026},
url = {https://doi.org/10.1515/popets-2018-0026}
}
Mike Bond, Omar Choudary, Steven J. Murdoch and others. 2014. IEEE Symposium on Security and Privacy 2014. Peer reviewedDOI 10.1109/SP.2014.11 (external link)
Finds that many EMV terminals and ATMs generate weak or predictable "unpredictable numbers", which lets an attacker who briefly accesses a card harvest authorization cryptograms in advance and replay them later as if the card were present (the pre-play attack).
Why it matters here: Replay of pre-computed authorizations is the same failure class that agent payment specs try to block with nonces, timestamps and per-request signatures, as in Visa TAP signatures and network tokens. Mastercard Agent Pay: Unpredictable-number weaknesses: a reminder that cryptogram freshness matters for DSRP payloads too.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{bond2014chipandskim,
title = {{Chip and Skim: Cloning EMV Cards with the Pre-play Attack}},
author = {Mike Bond and Omar Choudary and Steven J. Murdoch and Sergei Skorobogatov and Ross Anderson},
year = {2014},
booktitle = {2014 IEEE Symposium on Security and Privacy},
pages = {49--64},
publisher = {IEEE},
doi = {10.1109/SP.2014.11},
url = {https://doi.org/10.1109/SP.2014.11}
}
Steven J. Murdoch, Saar Drimer, Ross Anderson and others. 2010. IEEE Symposium on Security and Privacy 2010. Peer reviewedDOI 10.1109/SP.2010.33 (external link)
Shows a man-in-the-middle attack on EMV chip cards in which a device between card and terminal makes the terminal believe the PIN was verified while the card believes signature verification was used, so a stolen card works with any PIN.
Why it matters here: A reminder that card security fails at the seams between parties that each see half the transaction; agent payment schemes add another party, the agent, between cardholder and merchant. Mastercard Agent Pay: Shows how card protocol flaws persist when issuers, networks and merchants each assume someone else checks.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{murdoch2010chipandpin,
title = {{Chip and PIN is Broken}},
author = {Steven J. Murdoch and Saar Drimer and Ross Anderson and Mike Bond},
year = {2010},
booktitle = {2010 IEEE Symposium on Security and Privacy},
pages = {433--446},
publisher = {IEEE},
doi = {10.1109/SP.2010.33},
url = {https://doi.org/10.1109/SP.2010.33}
}
Criticizes the original 3-D Secure schemes (Verified by Visa and MasterCard SecureCode) for training users to enter passwords into unverifiable inline frames, shifting liability onto cardholders, and weakening security in the name of convenience.
Why it matters here: 3-D Secure is the existing step-up and liability mechanism that card-based agent payments build on or bypass; this paper explains why authentication that users cannot verify fails. Mastercard Agent Pay: An earlier network-run authentication layer and how liability design shaped it; Agent Pay faces the same liability question. Visa Trusted Agent Protocol: Lessons from an earlier network-run authentication layer and its liability design.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{murdoch20103dsecure,
title = {{Verified by Visa and MasterCard SecureCode: Or, How Not to Design Authentication}},
author = {Steven J. Murdoch and Ross Anderson},
year = {2010},
booktitle = {Financial Cryptography and Data Security},
series = {Lecture Notes in Computer Science},
pages = {336--342},
publisher = {Springer},
doi = {10.1007/978-3-642-14577-3_27},
url = {https://doi.org/10.1007/978-3-642-14577-3_27}
}
Builds the standard model of competition between two-sided platforms that must attract both buyers and sellers, showing how price structure, not just price level, determines adoption, with payment cards as a leading example.
Why it matters here: Every agentic checkout protocol is a two-sided platform bet; this model explains the subsidy and fee choices behind merchant and agent adoption of ACP, UCP and card network programs. Agentic Commerce Protocol (ACP): Two-sided market economics behind platform fees on merchants. UCP: Two-sided platform economics behind a protocol that joins agent surfaces and merchants.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@article{rochet2003platform,
title = {{Platform Competition in Two-Sided Markets}},
author = {Jean-Charles Rochet and Jean Tirole},
year = {2003},
journal = {Journal of the European Economic Association},
volume = {1},
number = {4},
pages = {990--1029},
doi = {10.1162/154247603322493212},
url = {https://doi.org/10.1162/154247603322493212}
}
Models a payment card association in which issuers and acquirers cooperate on a network but compete for cardholders and merchants, and studies how the interchange fee balances use and acceptance of cards.
Why it matters here: Interchange is the economic engine that card-based agent payments inherit; the paper explains why networks set fees on one side to grow the other, which shapes who pays for agent checkout. Mastercard Agent Pay: Card network economics and interchange; Agent Pay leaves card economics unchanged so far.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@article{rochet2002cooperation,
title = {{Cooperation among Competitors: Some Economics of Payment Card Associations}},
author = {Jean-Charles Rochet and Jean Tirole},
year = {2002},
journal = {The RAND Journal of Economics},
volume = {33},
number = {4},
publisher = {Wiley},
doi = {10.2307/3087474},
url = {https://doi.org/10.2307/3087474}
}
Documents a national agent-identity system in China, scheduled for public launch in Q3 2026, in which an agent is bound to a verified legal principal that is not disclosed to business-layer participants and can be re-identified only by compelling two separate government agencies, a mechanism the authors call split-knowledge binding and describe as institutional rather than cryptographic. The paper is a pre-launch v1 and promises post-launch measurements.
Why it matters here: A state-run alternative to erc-8004 style permissionless identity and to network-issued agent identity in visa-tap and mastercard-agent-pay; status is announced, not yet measured.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{he2026accountable,
title = {{Accountable yet Anonymous AI Agents - Split-Knowledge Binding in National Agent-Identity Layer in China}},
author = {Yifan He and Zhiguang Shan and Le Luo and Wei Wang},
year = {2026},
eprint = {2607.23207},
archivePrefix = {arXiv},
primaryClass = {cs.CY},
url = {https://arxiv.org/abs/2607.23207}
}
Defines AI identity as the continuous relationship between what an agent is declared to be and what it is observed to do, compares human and AI identity on substrate, persistence, verifiability and legal standing, evaluates current technical and regulatory documents against agent identity requirements, and identifies five structural gaps including recursive delegation accountability and agent identity integrity.
Why it matters here: A gap analysis that the identity claims in visa-tap, erc-8004 and ap2 can be checked against. Visa Trusted Agent Protocol: Survey of agent identity standards and gaps.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{otsuka2026aiidentity,
title = {{AI Identity: Standards, Gaps, and Research Directions for AI Agents}},
author = {Takumi Otsuka and Kentaroh Toyoda and Alex Leung},
year = {2026},
eprint = {2604.23280},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2604.23280}
}
Specifies terms.txt, a robots.txt-style file for per-path, per-purpose machine-access terms, and an origin-enforced exchange combining Web Bot Auth signatures, signed intent, delegation tokens, HTTP 402 negotiation and signed receipts, with a dependency-free implementation adding 0.20 to 0.65 ms per request. The arXiv comment reports submission to IEEE Internet Computing; it is not accepted as of the arXiv record.
Why it matters here: Combines the Web Bot Auth signatures that visa-tap builds on with HTTP 402 negotiation in the style of x402 and stripe-mpp, for content access rather than checkout.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{chowdhury2026termstxt,
title = {{terms.txt: A Consent and Compensation Protocol for Agentic Web Access}},
author = {Rajarshi Chowdhury},
year = {2026},
eprint = {2609.11152},
archivePrefix = {arXiv},
primaryClass = {cs.NI},
url = {https://arxiv.org/abs/2609.11152}
}
Argues that the agentic web needs normative infrastructure, laws, terms of service and norms that distinguish malicious bots from agents acting with a user's delegated authority, because platforms currently block or degrade agent access, often covertly; proposes normative principles and policies enabling appropriately delegated agents to act online.
Why it matters here: Policy context for visa-tap and openai-acp, which exist partly so that merchants can admit delegated agents while refusing abusive bots.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{pattison2026normative,
title = {{The Agentic Web Requires New Normative Infrastructure}},
author = {Cameron Pattison and Matthew Boulos and Noam Kolt and Changbai Li and Tiziano Piccardi and Seth Lazar},
year = {2026},
eprint = {2606.10711},
archivePrefix = {arXiv},
primaryClass = {cs.CY},
url = {https://arxiv.org/abs/2606.10711}
}
Introduces the concept of agent infrastructure, technical systems and shared protocols external to agents that mediate their interactions, and identifies three functions: attributing actions and properties to agents and their principals, shaping agent interactions, and detecting and remedying harm. Provides a catalog of research directions with analysis of adoption and links to existing internet infrastructure. Confirmed as a TMLR paper through the jmlr.org BibTeX record (OpenReview id Ckh17xN2R2).
Why it matters here: The framing paper for treating x402, ap2, erc-8004 and the card-network protocols as infrastructure rather than model behavior. Visa Trusted Agent Protocol: Attribution and interaction infrastructure for agents, of which signed requests are one piece.
Metadata verified 2026-10-10 through publisher.
Show BibTeX
@article{chan2025infrastructure,
title = {{Infrastructure for AI Agents}},
author = {Alan Chan and Kevin Wei and Sihao Huang and Nitarshan Rajkumar and Elija Perrier and Seth Lazar and Gillian K. Hadfield and Markus Anderljung},
year = {2025},
journal = {Transactions on Machine Learning Research},
eprint = {2501.10114},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2501.10114},
note = {ISSN 2835-8856; OpenReview forum Ckh17xN2R2}
}
Proposes a framework in which IDs are ascribed to instances of AI systems, such as a particular agent session, with associated information accessible to parties that interact with them, and argues that demand for IDs is strongest where systems can make financial transactions or contact real people. The arXiv comment reports acceptance at the RegML workshop at NeurIPS 2024; no publisher record confirms it, so no venue is shown.
Why it matters here: Direct conceptual ancestor of per-agent identity in visa-tap, erc-8004 registrations and the agent credentials in ap2 mandates. Visa Trusted Agent Protocol: Agent identifiers, the general problem TAP solves for one network.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{chan2024ids,
title = {{IDs for AI Systems}},
author = {Alan Chan and Noam Kolt and Peter Wills and Usman Anwar and Christian Schroeder de Witt and Nitarshan Rajkumar and Lewis Hammond and David Krueger and Lennart Heim and Markus Anderljung},
year = {2024},
eprint = {2406.12137},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2406.12137}
}
Analyzes personhood credentials, privacy-preserving digital credentials that let users prove to online services that they are real people without revealing personal information, issued by governments or other trusted institutions, and discusses benefits, deployment risks and design challenges as AI becomes indistinguishable from humans online.
Why it matters here: The complement to agent identity: visa-tap and openai-acp need to tell delegated agents from both humans and malicious bots, and personhood credentials sit at one end of that spectrum.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{adler2024personhood,
title = {{Personhood credentials: Artificial intelligence and the value of privacy-preserving tools to distinguish who is real online}},
author = {Steven Adler and Zoë Hitzig and Shrey Jain and Catherine Brewer and Wayne Chang and Renée DiResta and Eddy Lazzarin and Sean McGregor and Wendy Seltzer and Divya Siddarth and Nouran Soliman and Tobin South and Connor Spelliscy and Manu Sporny and Varya Srivastava and John Bailey and Brian Christian and Andrew Critch and Ronnie Falcon and Heather Flanagan and Kim Hamilton Duffy and Eric Ho and Claire R. Leibowicz and Srikanth Nadhamuni and Alan Z. Rozenshtein and David Schnurr and Evan Shapiro and Lacey Strahm and Andrew Trask and Zoe Weinberg and Cedric Whitney and Tom Zick},
year = {2024},
eprint = {2408.07892},
archivePrefix = {arXiv},
primaryClass = {cs.CY},
url = {https://arxiv.org/abs/2408.07892}
}
Assesses three measures for visibility into AI agents, agent identifiers, real-time monitoring and activity logging, outlines implementations that vary in intrusiveness and informativeness, and analyzes how they apply across centralized and decentralized deployments, including implications for privacy and concentration of power.
Why it matters here: Foundation for the agent identifier idea that visa-tap, erc-8004 and ap2 each implement in their own way.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{chan2024visibility,
title = {{Visibility into AI Agents}},
author = {Alan Chan and Carson Ezell and Max Kaufmann and Kevin Wei and Lewis Hammond and Herbie Bradley and Emma Bluemke and Nitarshan Rajkumar and David Krueger and Noam Kolt and Lennart Heim and Markus Anderljung},
year = {2024},
booktitle = {Proceedings of the 2024 ACM Conference on Fairness, Accountability, and Transparency (FAccT '24)},
publisher = {ACM},
pages = {958-973},
doi = {10.1145/3630106.3658948},
eprint = {2401.13138},
archivePrefix = {arXiv},
primaryClass = {cs.CY},
url = {https://arxiv.org/abs/2401.13138}
}
Grey literature: central banks, standards drafts and white papers
Global Legal Entity Identifier Foundation (GLEIF). 2026. GLEIF Working Paper Series. Not peer reviewed
A working paper (cover dated September 2026, written by contributors from GLEIF, Curvy Protocol, zERC20, Terminal 3 and an independent expert) arguing that existing law can allocate liability for agent payments but practical proof of delegated authority is missing. It proposes Agent Mandate Credentials anchored in the verifiable LEI to show which organization stands behind an agent and what it may do.
Why it matters here: Offers an organizational-identity answer to the "who is behind this agent" question that ERC-8004 registries, Visa TAP keys and Agent Pay tokens each answer differently.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@techreport{gleif2026agenticpayments,
title = {{Agentic AI in Payments: Establishing Interoperable Trust and Control}},
author = {{Global Legal Entity Identifier Foundation (GLEIF)}},
year = {2026},
institution = {Global Legal Entity Identifier Foundation},
type = {GLEIF Working Paper Series},
month = {sep},
url = {https://www.gleif.org/organizational-identity/research-publications/2026-08-13_agentic_ai_in_payments_v1.0-1.pdf}
}
Prem Munday. 2026. Bank Underground (Bank of England staff blog). Not peer reviewed
A Bank of England staff blog post (2026-05-21) on how agentic commerce could reshape payment design, stressing that deployers stay legally responsible for their agents and asking how existing frameworks apply to card, account-to-account and tokenized rails. Views are the author's, not the Bank's.
Why it matters here: Shows how a payment system operator and overseer frames the contest between card-network agent programs and newer rails such as stablecoin-based x402.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{munday2026bankunderground,
title = {{Agentic commerce and the battleground for new payments infrastructure}},
author = {Prem Munday},
year = {2026},
howpublished = {Bank Underground blog, Bank of England},
note = {Published 2026-05-21},
url = {https://bankunderground.co.uk/2026/05/21/agentic-commerce-and-the-battleground-for-new-payments-infrastructure/}
}
Reshmi Suresh. 2026. Worldpay Insights article. Not peer reviewed
An acquirer's analysis (2026-07-30) noting that Visa, Mastercard and American Express have all launched frameworks for agent transactions while the question of who bears the loss in a dispute remains largely open.
Why it matters here: Liability allocation is the unresolved commercial question behind TAP and Agent Pay; this is the merchant-acquirer view of it. Visa Trusted Agent Protocol: Acquirer view that no agent liability shift exists yet.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{suresh2026worldpay,
title = {{Agentic commerce liability is still being written}},
author = {Reshmi Suresh},
year = {2026},
howpublished = {Worldpay},
note = {Article, 2026-07-30},
url = {https://worldpay.com/en/insights/articles/agentic-commerce-liability-is-still-being-written}
}
Visa, Artemis. 2026. Visa and Artemis joint research report. Not peer reviewed
A joint report (summary page last updated 2026-07-14) that splits agentic commerce into agent purchases on behalf of people and small machine-to-machine payments, and measures x402 at about $15.0 million adjusted volume over 109.6 million transactions and MPP at about $25,000 over 115,000 transactions, using Artemis data as of 2026-04-21.
Why it matters here: The main vendor-published measurement of x402 and MPP volumes; the adjusted figures exclude activity Artemis classed as wash or test traffic, and they are self-reported, not independently audited.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{visa2026groundup,
title = {{Agentic Payments from the Ground Up: What the Onchain Data Tells Us}},
author = {{Visa} and {Artemis}},
year = {2026},
howpublished = {Visa},
note = {Research report with Artemis; data as of 2026-04-21},
url = {https://www.visa.com/en-us/thought-leadership/innovation/agentic-payments-from-the-ground-up}
}
Examines how agentic AI could change authorization, liquidity, settlement, compliance and resilience in payments, using a three-layer model of intent, authorization and settlement. It stresses the tension between probabilistic AI behavior and the deterministic requirements of payment systems.
Why it matters here: The IMF view of where agent decisions should stop and rule-based payment execution should begin, a split visible in how AP2 mandates and card network tokens separate intent from settlement.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@techreport{davidovic2026imfnote,
title = {{How Agentic AI Will Reshape Payments}},
author = {Sonja Davidovic and Hervé Tourpe},
year = {2026},
institution = {International Monetary Fund},
type = {IMF Notes},
number = {2026/004},
month = {apr},
doi = {10.5089/9781513533308.068},
url = {https://doi.org/10.5089/9781513533308.068}
}
T. Meunier, S. Major. 2026. IETF Internet-Draft draft-ietf-webbotauth-httpsig-protocol-00 (Web Bot Auth working group). Not peer reviewed
The first Web Bot Auth working group draft (revision 00, 2026-09-01) for identifying automated HTTP clients with HTTP Message Signatures. It defines the Signature-Agent header for in-band key discovery, a JWKS-based key directory format and a well-known URI for serving it.
Why it matters here: The Visa TAP spec calls itself aligned with Web Bot Auth, Cloudflare says the Visa and Mastercard agent protocols build on it, and UCP offers an optional Web Bot Auth profile; this working group draft, posted almost a year after TAP launched, is the standards-track form of that request signing. Mastercard Agent Pay: The HTTP Message Signatures draft for automated traffic that Agent Pay's edge verification resembles. Visa Trusted Agent Protocol: The IETF working group draft TAP is compared against.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{meunier2026webbotauth,
title = {{HTTP Message Signatures for automated traffic}},
author = {T. Meunier and S. Major},
year = {2026},
howpublished = {Internet-Draft draft-ietf-webbotauth-httpsig-protocol-00, IETF},
note = {Work in progress, 2026-09-01},
url = {https://datatracker.ietf.org/doc/draft-ietf-webbotauth-httpsig-protocol/}
}
Christopher J. Waller. 2026. Speech at Sibos 2026, Miami, Florida. Not peer reviewed
A Federal Reserve Governor speech separating agent-assisted commerce, where the buyer decides and pays, from agent-delegated commerce, where an agent shops and pays within guardrails, and naming authentication, liability and fraud as the main barriers to the delegated model. The Board speech feed dates it 2026-09-29.
Why it matters here: States in policy terms the shift every protocol in the atlas addresses: proving that an agent holds authority to pay, not only that the cardholder is genuine.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{waller2026sibos,
title = {{Payments in the Age of AI Agents}},
author = {Christopher J. Waller},
year = {2026},
howpublished = {Speech, Board of Governors of the Federal Reserve System},
note = {Sibos 2026, Miami, Florida, 2026-09-29},
url = {https://www.federalreserve.gov/newsevents/speech/waller20260928a.htm}
}
An OpenID Foundation white paper that surveys the authentication, authorization and identity resources available for today's agents, including MCP-centered practice, and sets out a strategic agenda for scalable access control, agent-centric identities, workload differentiation and delegated authority. Grey literature: the venue is the arXiv journal reference, not a peer-reviewed outlet.
Why it matters here: Standards-community baseline for the identity layer under visa-tap, ap2 and openai-acp; it records what OAuth and OIDC already cover and what is missing. AP2: OpenID Foundation white paper on agent identity and authorization. Visa Trusted Agent Protocol: Survey of agent identity that discusses Web Bot Auth.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@techreport{south2025identity,
title = {{Identity Management for Agentic AI: The new frontier of authorization, authentication, and security for an AI agent world}},
author = {Tobin South and Subramanya Nagabhushanaradhya and Ayesha Dissanayaka and Sarah Cecchetti and George Fletcher and Victor Lu and Aldo Pietropaolo and Dean H. Saxe and Jeff Lombardo and Abhishek Maligehalli Shivalingaiah and Stan Bounev and Alex Keisner and Andor Kesselman and Zack Proser and Ginny Fahs and Andrew Bunyea and Ben Moskowitz and Atul Tulshibagwale and Dazza Greenwood and Jiaxin Pei and Alex Pentland},
year = {2025},
institution = {OpenID Foundation},
type = {Whitepaper},
eprint = {2510.25819},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2510.25819}
}
TAP proves that a key from a payment scheme's store signed this host and path, for a stated purpose, within 8 minutes. Everything else is trust placed in a party: Visa's non-public onboarding and its key store, the verifier's choice to keep nonces, and the merchant's handling of personal data. The minimum signature leaves the method, the query and the body unbound, body objects have no canonical form, and the published key store and examples do not line up. No CVE or advisory names TAP, and no academic attack on it has been published; the threats below come from reading the specification and the sample code.
STRIDE threats (11)
STRIDE
Threat
Spec mitigation
Implementer notes
S Spoofing
Stolen agent signing keyAn attacker who obtains an Agent Provider's private key signs requests that verify as a trusted agent, browsing or paying. Source [1, 10]Preconditions: Access to the agent's key material; The key is still in the key store.Impact: Requests from the attacker pass every TAP check; merchants extend agent-level trust to them.
Left to implementers
TAP specifies no revocation list or key status endpoint; removal from the key store or expiry is the only stop. Merchants should combine TAP with other signals and cache keys briefly.
S Spoofing
Replay inside the 8-minute windowA captured signed request is resent while it is still valid. Source [1, 37]Preconditions: The attacker can observe or obtain a signed request; The verifier keeps no nonce record.Impact: The replay is accepted as a trusted agent request.
Partly
TAP makes nonce tracking conditional. Keep nonces for at least 8 minutes, shared across edge nodes, and record them only after the signature verifies.
S Spoofing
Key store confusionThe published JWKS held one RSA key from a sandbox CA and no Ed25519 key, so verifiers may source keys elsewhere or accept keys loosely. Source [1, 10]Preconditions: The verifier cannot resolve the agent's keyid from the published JWKS; An out-of-band key path is used.Impact: Keys from an untrusted path could be accepted as Visa's.
Left to implementers
Accept keys only from a channel Visa documents; pin the key store origin; alert on unknown keyids.
T Tampering
Method, query or body changed under a valid signatureThe minimum signature covers only @authority and @path. An intermediary can change the method, the query string or the body, including the signed objects' transport, without breaking the header signature. Source [1, 14, 32]Preconditions: An attacker on the path or a misbehaving intermediary; The verifier relies on the minimum covered set.Impact: A browse-tagged signature can be reused against other methods or bodies on the same path until it expires.
Partly
Ask agents to cover @method, @query and Content-Digest as extra fields; verify body objects separately; keep windows short.
T Tampering
Unverified consumer data used for decisionsThe specification lets a merchant use consumer recognition data even when verification fails. Source [1]Preconditions: The merchant follows the discretionary wording; An attacker forges an agenticConsumer object.Impact: Account matching or risk decisions based on forged identity data.
Partly
Use consumer data only after the nonce and signature verify; never log a user in on unverified data.
T Tampering
browsingIOU without settlement termsThe merchant grants access on a signed IOU expecting funds at settlement, but TAP defines no settlement or default rule. Source [1]Preconditions: The merchant serves paid content against IOUs.Impact: Unpaid access with no protocol remedy.
Left to implementers
Limit IOU amounts and exposure per agent; agree settlement terms with the payment service and acquirer.
R Repudiation
No receipt or evidence from TAPTAP defines no receipt, so a verified request leaves no portable evidence of what the agent was allowed to do. Source [1, 9]Preconditions: A dispute about an agent purchase.Impact: Disputes rest on VIC signals and card rules, not on TAP records.
Left to implementers
Log verification results with the signature parameters; rely on VIC confirmations for transaction evidence.
I Information disclosure
Consumer data exposed to every merchant visitedThe consumer object carries IP address, device data, country and postal code, plus obfuscated contact values, to each merchant the agent visits. Source [1, 5]Preconditions: The agent attaches agenticConsumer while browsing.Impact: Profiling and cross-site tracking of the consumer; data protection duties for merchants.
Left to implementers
The specification has no minimization or retention rule; agents should send the object only where needed and merchants should treat it as personal data.
I Information disclosure
Unsalted credential hash reveals card dataThe payment credential hash covers a 16-digit account number, expiry and a 3-digit code with no stated algorithm or salt, so the input space is small. Source [1]Preconditions: The attacker sees a payment container with a credential hash; The hash is a plain digest.Impact: Card data could be recovered by trying candidate values.
Left to implementers
Treat the hash as sensitive card data, protect it in transit and logs, and ask Visa for the algorithm and any salt.
D Denial of service
Key store or verification as a single point of failureEvery verification needs Visa's key store or a cached key; an outage or a CDN error blocks agents at many merchants at once. Source [10, 27]Preconditions: Key cache expired during an outage.Impact: Legitimate agents blocked; merchants fall back to bot rules.
Left to implementers
Cache keys with a reasonable lifetime; the published JWKS uses a one-hour cache-control; monitor fetch failures.
E Elevation of privilege
Interoperability gaps bypass verificationSample code builds non-RFC signature bases, uses an unregistered algorithm name, and its CDN proxy protects only /product/ paths, skipping the tag and window checks. Implementations copied from it can be bypassed. Source [8, 30, 37, 38]Preconditions: A deployment reuses the sample code.Impact: Checkout and API paths left unverified; old or mis-tagged signatures accepted.
Left to implementers
Use a conformant RFC 9421 library, verify every path that matters, and check the tag and window explicitly.
Attack scenarios
A browse signature reused against checkout data Source [1, 14]
Preconditions: The attacker captures a browse-tagged request to a path that also accepts POST; The verifier checks only the minimum components.
The attacker copies Signature-Input and Signature
Within 8 minutes it sends a POST to the same host and path with its own body
The header signature verifies because method and body are not covered
A verifier without a nonce record accepts it
Impact: Requests with attacker-chosen content inherit trusted agent status.
Card data recovered from a credential hash Source [1]
Preconditions: A payment container with paymentCredentialsHash is logged or leaked; The hash is an unsalted digest.
The attacker learns the card's bank identification range and expiry candidates
It hashes candidate numbers and security codes
It finds the input that matches the hash
Impact: Usable card data for card-not-present fraud.
A sample-code edge lets checkout through unchecked Source [37]
Preconditions: A merchant deploys the sample CDN proxy.
The proxy verifies only paths starting with /product/
An attacker posts directly to the checkout path
No signature is required and rate limiting is off
Impact: Bot traffic reaches checkout as if it had passed the agent gate.
Published research findings
A Formal Analysis of Agent Payment Protocols: Models x402, MPP, ACP and AP2 in Tamarin; TAP is not modeled, so no formal analysis of TAP exists. (paper (not listed in section G)) Source [34]
RAILS: Verification-Native Clearing For Agentic Commerce: Argues that the Visa and Mastercard network agent protocols, along with MCP, A2A, x402 and AP2, assume rather than produce a determination of whether an agent met its obligation; its full text names Visa's TAP, the only paper found that does. (paper in section G) Source [46]
FP-Inconsistent: fingerprint inconsistencies in evasive bot traffic: About half of the traffic bought from 20 bot services evaded two commercial anti-bot products by altering browser fingerprints, the weakness that signed agent requests aim to replace. (paper in section G) Source [47]
Verified by Visa and MasterCard SecureCode: Or, How Not to Design Authentication: Criticizes 3-D Secure for unverifiable password frames and for shifting liability onto cardholders; a reference point for any network-run authentication layer. (paper in section G) Source [48]
CVEs and advisories
No CVE or advisory is recorded for this protocol as of the last verification.
TAP natively verifies agent identity and bounds every signature to 8 minutes. Replay protection, payee scoping, revocation and monitoring are partial, and consent, limits, step-up and disputes sit in Visa Intelligent Commerce. The best places for an independent controls layer are the edge, where the signature is checked, and the merchant, where the body objects and payment data are checked.
RFC 9421 signature with a key from the payment scheme's key store; the tag states browse or pay intent. Source [1]
Agent registration (know your agent)
External
Agents are onboarded to Visa Intelligent Commerce and approved by the scheme; the process is not public. The Agentic Directory (2026-06-10) lists agents Visa has verified. Source [1, 9, 19]
User consent capture
External
Consent lives in VIC, where the user approves each Payment Instruction with a passkey; the ID Token can carry auth_time and amr. Source [1, 9]
Spending caps
External
No amounts or limits in TAP; VIC Payment Instructions and network controls apply. Source [1, 9]
Merchant or payee scoping
Partial
@authority binds the signature to one merchant host and @path to a page; the method and body are not bound. Source [1]
Time windows and expiry
Native
created and expires at most 8 minutes apart; created must be past and expires future. Source [1]
Revocation
Partial
An expired or missing key blocks verification; no revocation list or key status endpoint is specified. Source [1]
Step-up authentication
External
Step-up verification and Visa Payment Passkeys happen in VIC. Source [7, 9]
Replay protection
Partial
Nonce plus time window, but nonce tracking is optional for the verifier. Source [1]
Receipts and evidence
None
TAP defines no receipt; VIC confirmations and commerce signals serve as transaction evidence. Source [9, 31]
Dispute support
External
VIC signals support dispute resolution; no agent-specific liability shift is published. Source [9, 24]
Reputation
None
No reputation mechanism for agents; Agent Score rates merchant sites for agent readiness, not agents. Source [19]
Monitoring signals
Partial
Visa says TAP feeds telemetry into its fraud and risk models; CDNs expose verification results to zone owners. Source [25, 49]
Kill switch
Partial
Visa can remove a key from its store and merchants can block untagged or failing requests; no emergency procedure is documented. Source [1]
Request content is not bound. Method, query and body are outside the minimum signature, so a valid signature does not prove what the agent asked for. Source [1, 14]
Replay protection depends on the verifier. Nonce tracking is conditional, and the nonce is a session value shared across signatures. Source [1]
No revocation channel. There is no revocation list or status endpoint; a compromised key stays valid until Visa removes it. Source [1]
No user limits in the protocol. Spending limits and consent live in VIC and are invisible to the merchant in the TAP request. Source [1, 9]
No evidence record. TAP produces no receipt; merchants must log verification results themselves. Source [1]
Where an independent controls layer can act
Before authorization
Approve the purchase instruction. VIC passkey approval of the Payment Instruction before the agent fetches credentials. Source [9]
At signing
Choose the tag and what to cover. The agent platform can add @method, @query and Content-Digest beyond the minimum and refuse to send consumer data to merchants the user did not pick. Source [1]
At the edge
Verify agent identity and freshness. CDN checks tag, window, nonce, key and signature, then applies bot policy. Source [1, 27]
At settlement
Authorize the card payment. Issuer and network risk decisions on the agent-specific token; Visa feeds TAP telemetry into its risk models. Source [9, 25]
After the fact
Evidence and disputes. VIC confirmations, merchant logs of verification results and ordinary card dispute rules. Source [24, 31]
Implementer checklist
Keep a nonce record for at least 8 minutes, shared across all verifier nodes. TAP makes it optional, and without it replays pass. Source [1]
Reject windows over 8 minutes and check the tag against the page type. The sample proxy skips both checks. Source [1, 37]
Verify every path that matters, including checkout and API routes. The sample proxy protects only /product/ paths. Source [37]
Do not use payment containers or consumer data that fail verification. The specification leaves this to merchant discretion. Source [1]
Ask agents to cover @method and Content-Digest where possible. The minimum set leaves method and body unbound. Source [1, 32]
Treat credential hashes and contextualData as sensitive data in logs. They describe card data and personal data. Source [1]
Use a conformant RFC 9421 library rather than the sample code. The sample deviates from RFC 9421 serialization and algorithm names. Source [8, 30]
J. Compliance and regulation
Not legal advice. This is a study summary of public rules as of the dates cited. Ask counsel about your situation.
TAP identifies agents on card-not-present purchases and moves no money, so the rules that bite are card-payment rules: who authorized the transaction (Regulation E and Z, PSD2, UK PSRs), strong customer authentication when the user is absent, and data protection for the IP address, device data and contact values that the consumer object sends to merchants. Visa has published no agent-specific liability rule. The Product Terms put consumer disclosures and consents on the implementer. Rows are dated; check each source before relying on it.
Rules by topic and jurisdiction
Jurisdiction
What applies
Confidence
Consumer protection and liability
United States
Card-not-present purchases by a recognized agent fall under Regulation Z for credit cards: unauthorized use means use without actual, implied or apparent authority, with cardholder liability capped at the lesser of $50 or the amount before notice. Whether an agent acting outside its instruction has apparent authority is untested. Source [50]
Verified
United States
For debit cards, Regulation E excludes transfers by a person the consumer gave the access device to, until the consumer revokes that authority, so a consumer may carry an agent's transfers until notice. TAP itself carries no consent record. Source [51]
Verified
European Union
PSD2 makes a payment authorized only with the payer's consent and caps payer liability for unauthorized transactions. How consent to a specific transaction applies to an agent instruction is untested; PSD3 and the PSR (provisional agreement 2025-11-27) add no agent rules and are not yet in the Official Journal. Source [55, 56]
Reported
United Kingdom
The Payment Services Regulations 2017 treat a payment as authorized only with the payer's consent (regulation 67) and cap payer liability at GBP 35 in many cases (regulation 77). Source [60, 61]
Verified
Canada
No agent-specific payment liability rule was found in Canada; consumer-driven banking phase 2 is targeted for mid-2027. Source [65]
Reported
Singapore
MAS's E-Payments User Protection Guidelines allocate liability for unauthorized and erroneous e-payments; they do not address agents specifically. Source [66]
Verified
Card network rules
No public agent-specific dispute, chargeback or liability rule from Visa was found as of 2026-10-11; Worldpay wrote on 2026-07-30 that no liability shift exists and that properly tokenized agent transactions follow existing rules. Source [24, 69]
Reported
AML and sanctions
United States
TAP adds no sanctions or AML layer; card payments it accompanies follow the issuer's and acquirer's existing programs. OFAC obligations are the same whatever the channel. Source [1, 52]
Verified
Strong customer authentication
European Union
The RTS on strong customer authentication requires two factors and dynamic linking for remote payments. Visa says every Agentic Ready transaction in Europe used Visa Payment Passkeys to support SCA; that authentication sits in VIC, not in TAP. Source [7, 54]
Verified
United Kingdom
HM Treasury's consultation on modernising payment services regulation (2026-07-14 to 2026-10-06) asks how authentication, consent and liability should adapt for agentic payments; no response yet. Source [62]
Verified
Card network rules
EMVCo published a draft EMV Agentic Payments framework on 2026-09-01 and lists Know Your Agent and agentic transaction indicators as possible future work; TAP is not an EMVCo document. Source [3, 70]
Verified
AI-specific rules
European Union
The AI Act's Article 50 transparency duties apply from 2026-08-02; the Digital Omnibus moved Annex III high-risk duties to 2027-12-02. A shopping agent is not high-risk by default, but its operator may need to tell people they deal with an AI system. Source [58, 59]
Verified
United Kingdom
The FCA said on 2026-03-25 it will consider with HM Treasury whether regulation must change to support agentic AI payments; there is no AI statute. Source [63]
Verified
Singapore
MAS issued Guidelines on AI Risk Management on 2026-10-07, effective 2027-10-07, naming agentic AI systems; Ant International, Mastercard and Visa announced Know Your Agent work through a MAS-convened platform on 2026-09-11, building on TAP (reported). Source [67, 68]
Reported
Data protection
United States
California's CCPA regulations on automated decisionmaking technology take effect from 2026-01-01; a merchant that uses contextualData or the ID Token in automated decisions should check them. Source [1, 53]
Verified
European Union
contextualData sends the consumer's IP address, device data, country and postal code to each merchant, and the ID Token carries a stable subject id and obfuscated contact values; under the GDPR these are generally personal data. The TAP Product Terms put disclosures and consents on the implementer. Source [1, 5, 57]
Verified
Canada
PIPEDA governs the personal information in the consumer object that Canadian merchants receive. Source [1, 64]
Verified
Card network rules
A merchant that decrypts the payment payload receives a payment token, expiry and cardholder name, and key-entered checkout handles card numbers; the TAP specification says nothing about PCI DSS scope, while Visa offers Intelligent Commerce Connect to handle PCI compliance for enablers. Source [1, 13]
Verified
K. Observability lens
1 of 5 observability score
The key store at https://mcp.visa.com/.well-known/jwks is public and can be polled, but on 2026-10-11 it held one RSA sandbox key that does not match the specification's examples.
TAP is off-chain and defines no events, receipts or public logs.
Signature-Input parameters (keyid, tag, nonce, timestamps) are visible only to the merchant, the CDN and intermediaries on the path.
The Agentic Directory has no public list or endpoint, and no count of verifying merchants or signed requests is published.
The sample repository and its pull requests are public, which shows spec activity but not deployment.
Publicly observable
Public signals
What
Where
How
Visa key store
https://mcp.visa.com/.well-known/jwks
HTTP GET returns a JWK Set; served with cache-control public, max-age=3600. Poll it to watch for key additions or removals. Source [1, 10]
Key retrieval operation
GET /keys with a keyID parameter (host not named in the specification)
Returns one JWK with kty, kid, use, alg, n and e. Source [1]
Specification and terms
developer.visa.com trusted-agent-protocol pages
Unversioned pages; diff them over time to detect changes. Source [1, 5]
Sample repository activity
https://github.com/visa/trusted-agent-protocol
Commits, pull requests, issues and the GitHub advisories list. Source [6]
Announcements of adopters
Visa newsroom and partner releases
Named merchants, issuers and CDNs with dates. Source [7, 28]
Private by design
Per-request signature headers. Seen only by the merchant, its CDN and intermediaries on the request path.
Consumer object and ID Token. Personal data sent only to the merchant in the request body.
Payment container and decrypted payload. Card data for the merchant only.
Visa telemetry and risk scores. Visa feeds TAP data into internal fraud models.
Cloudflare verification results. Exposed to the zone owner, for example through cf.bot_management.signed_agent on Enterprise Bot Management.
VIC instructions and confirmations. Bilateral calls between the agent and Visa under /vacp/v1.
What an indexer or monitor could capture
Key additions and removals in the Visa JWKS from https://mcp.visa.com/.well-known/jwks: kid, kty, x5c certificate subjectSource [10]
Specification and sample code changes from GitHub API for visa/trusted-agent-protocol and the specification page: commit sha, pull request number, page hashSource [1, 6]
Own-site TAP traffic (for a merchant or CDN) from Signature-Input headers in access logs: keyid, tag, nonce, created, expiresSource [1, 27]
L. Ecosystem and adoption
Stewards
Visa: Writes the specification and Product Terms, onboards agents, hosts the key store and signs the ID Token. Source [1, 5]
Cloudflare: Co-developed TAP with Visa and verifies TAP signatures at the edge. Source [3, 27]
Implementers and deployments
Implementers (8)
Name
Role
Status
Cloudflare
Edge verification; planned Agents SDK support and managed rules (announced 2025-10-24). Source [7, 27]
Live
Akamai
TAP support across Akamai Cloud, announced 2025-12-17. Source [28, 29]
Announced
lastminute.com, Frasers, Cleverbridge, BrickDepot
Merchants in Visa's live European agent transactions (2026-07-02). Source [7]
Live
eDreams ODIGEO (eDreams, Opodo, GO Voyages, Travellink)
Said it uses TAP and the Agentic Directory to recognize verified agents (2026-07-03, secondary report). Source [21]
Announced
Worldpay
Acquirer that announced collaboration with Visa and Cloudflare on TAP at launch. Source [71]
Announced
Launch feedback partners
Adyen, Ant International, Checkout.com, Coinbase, CyberSource, Elavon, Fiserv, Microsoft, Nuvei, Shopify, Stripe and Worldpay gave feedback; not a list of deployments. Source [3]
Unknown
Visa Intelligent Commerce Connect
Visa on-ramp that accepts agent payments initiated through TAP, MPP, ACP and UCP. Source [13]
Pilot
mppx (Tempo, wevm)
MPP SDK with a TAP attestation signer and verifier. Source [22, 23]
Live
SDKs and packages
npmmppx (external link) version 0.13.4: MIT; mppx/attestation/tap signs and verifies TAP attestations. Not a Visa package.
Stars on the sample repository. Source [6] Caveat: Interest, not usage; 45 forks.
Merchants named as live with TAP
4 merchants
Merchants Visa named in its live European agent transactions. Source [7] Caveat: No total count of verifying merchants is published.
European issuers with live agent purchases
31 issuers
Issuers named in Visa's release; the text says over 30. Source [7] Caveat: VIC program metric, not TAP traffic.
Agent-initiated transactions completed with partners
hundreds transactions
Visa's own description of completed agent transactions. Source [29] Caveat: Self-reported VIC figure; named transactions are pilots or first transactions.
Partners working with Visa on agentic commerce
more than 100 partners
Visa said over 30 build in the VIC sandbox and over 20 agents and enablers integrate directly. Source [29] Caveat: Self-reported; not TAP-specific.
Rise in malicious bot-initiated transactions
25 percent (US 40 percent) change over six months
Visa internal data on bot-initiated transactions. Source [25] Caveat: Problem context, not TAP adoption.
AI-driven traffic to US retail sites
over 4,700 percent change in a year
Adobe Data Insights figure for August 2025, cited in Visa launch release of 2025-10-14. Source [3] Caveat: Adobe figure quoted by Visa; month-level date only.
Card economics unchanged: merchant pays its usual acquiring fees
Reported Evidence of absence from Visa's pages and two secondary reviews; treat agent purchases as ordinary tokenized card-not-present payments until Visa publishes otherwise.
Edge verification
Cloudflare's signed-agent field needs an Enterprise plan with Bot Management; no TAP-specific price Source [49]
Sign requests with a TAP attestation (agent)mppx (mppx/attestation/tap) 0.13.4Client sidetypescript
import * as Tap from 'mppx/attestation/tap'import { Mppx, tempo } from 'mppx/client'import type { Account } from 'viem'declare const account: Accountdeclare const agentPrivateKey: CryptoKeyconst client = Mppx.create({ attestation: { tap: Tap.Client.signer({ intent: 'payment', key: agentPrivateKey, keyId: 'agent-provider-key-1', }), }, methods: [tempo({ account })], polyfill: false,})const response = await client.fetch('https://merchant.example/checkout')
From the MPP identity docs (MIT). Intent payment maps to the tag agent-payer-auth and browse to agent-browser-auth; the signer uses an 8-minute lifetime by default. Visa publishes no TAP SDK of its own; the visa/trusted-agent-protocol sample is under Visa's Product Terms and is not reproduced here. mppx (mppx/attestation/tap) documentation (external link)Source [22, 23]
Verify TAP attestations on a servermppx (mppx/attestation/tap) 0.13.4Server sidetypescript
import * as Tap from 'mppx/attestation/tap'import { Mppx, Store, tempo } from 'mppx/server'declare const trustedAgentKeys: ReadonlyMap<string, CryptoKey>const payment = Mppx.create({ attestation: { tap: Tap.Server.verifier({ keyResolver({ keyId }) { return trustedAgentKeys.get(keyId) }, nonceStore: Store.memory(), }), }, methods: [tempo.charge()],})export const handler = payment.charge({ amount: '12.50' })
RFC 9421 TAP signature builder and verifier (playground): /p/visa-tap/#o-playground (planned)
O. Playground
Sign a request with an ephemeral Ed25519 key, see the exact RFC 9421 signature base and headers, then walk the CDN checks (key, 8-minute window, nonce replay, tag, signature) while tampering in transit, inspect the consumer and payment objects field by field, and compare the same request signed as TAP and as Web Bot Auth, all simulated in the browser with fixture keys and no network.
Simulation, no real fundsFollows spec version TAP spec, unversioned (read 2026-10-11)
Loading the simulation.
Keys are generated in this browser for this session only, on test chain identifiers or fixture data. No wallet connects and nothing is sent to a network.
P. Compare and compose
Mastercard Pay is the closest sibling. Cloudflare describes both as building on with a in Signature-Input and a required , verified by the same edge checks.Source [27] The details differ: Mastercard’s guide gives one tag, Agent-pay-auth, where Visa has two, and each network hosts its own key directory.Source [27, 42] Mastercard’s directory location is not publicly known, because the only host named in its guide did not resolve on 2026-10-11.Source [27, 42] Both networks also say “”, for different products: Visa’s agentic network tokens in , Mastercard’s Agentic Tokens in Agent Pay.Source [9, 15, 16]
Against the IETF Web Bot Auth draft, is aligned in direction and different in detail. The draft requires the tag web-bot-auth, a covered Signature-Agent header, a keyid that is a thumbprint and a directory at /.well-known/http-message-signatures-directory; TAP uses its own tags, does not require Signature-Agent, a mandatory nonce, an 8-minute rather than 24-hour limit and Visa’s JWKS.Source [1, 14] TAP launched almost eleven months before the draft, so the draft is not its basis.Source [3, 14] UCP’s own signing, with Content-Digest and an optional Web Bot Auth profile, sits closer to the draft than TAP does, and the UCP specification never names TAP.Source [14, 43]
With Stripe MPP, TAP is an optional layer. Visa’s card method draft has said since its first commit that a client may add TAP signature headers for extra identity assurance; that commit was authored on 2026-01-05 and published on 2026-03-18.Source [12] Visa’s 2026-03-18 post frames the card specification and SDK as built on VIC and TAP.Source [11] In mppx, a TAP attestation identifies the agent but authorizes no payment and proves nothing about the user, so it pairs with an MPP credential rather than replacing it.Source [44]
With x402, the link is a shared status code and shared membership, not a shared format. TAP’s browsingIOU answers a with card-acquiring data, the sample merchant’s 402 uses ad hoc X-Payment headers, and Visa said at launch that it was working with Coinbase to align on interoperability.Source [1, 3, 45] For ACP and UCP, Visa’s is the meeting point: it accepts payments initiated through either, alongside TAP and MPP.Source [13]
Relations to other protocols
Competes withfrom Mastercard Agent Pay: Same edge pattern (RFC 9421 signature with a tag and nonce, network-hosted key directory), different tag and directory; both networks issue their own agentic tokens, which mean different products. Source [42, 73, 74]
Compatible withfrom Agentic Commerce Protocol (ACP): No documented protocol link. Stripe says it might use Visa Intelligent Commerce tokens under SPT card payments, so Visa agent tokens can sit under an ACP payment. Source [75]
Embedsfrom Stripe MPP (Machine Payments Protocol): The Visa-authored card method lets a client add TAP signature headers (in the spec since 2026-03-18); Visa says the card spec and SDK are built on VIC and TAP; mppx adds TAP request attestation. Source [76, 77, 78, 79]
Complementsfrom UCP: Both use RFC 9421 HTTP Message Signatures and UCP added optional Web Bot Auth interop; the UCP spec never names TAP and no bridge is documented. Visa is a listed endorser. Source [43, 80]
Compatible withVisa Trusted Agent Protocol to Stripe MPP (Machine Payments Protocol): Visa authored the MPP card method; draft-card-charge-00 lets a client add TAP signature headers, Visa says the card spec and mpp-card SDK are built on VIC and TAP, and mppx signs and verifies TAP attestations. Source [11, 12, 23]
Competes withVisa Trusted Agent Protocol to Mastercard Agent Pay: Same pattern on another network: RFC 9421 signatures with a network tag and a nonce, verified at the CDN. Mastercard uses one tag, Agent-pay-auth, and its own key directory, whose location is not public. Source [27, 42]
ComplementsVisa Trusted Agent Protocol to Agentic Commerce Protocol (ACP): Visa says TAP complements ACP and Intelligent Commerce Connect accepts ACP payments; no wire-level binding is published. Source [3, 13]
ComplementsVisa Trusted Agent Protocol to UCP: Intelligent Commerce Connect accepts UCP payments and Visa is listed as a UCP endorser; UCP has its own RFC 9421 signing, closer to the Web Bot Auth draft, and never names TAP. Source [13, 43, 80]
ComplementsVisa Trusted Agent Protocol to x402: TAP's browsingIOU answers an HTTP 402 with card-acquiring data but uses none of x402's headers or payloads; Visa is a Premier member of the x402 Foundation and said at launch it was working with Coinbase on interoperability. Source [1, 3, 35]
Complementsfrom x402: The TAP specification defines a browsingIOU object an agent sends when a merchant answered with 402; TAP samples use non-standard X-Payment headers rather than the x402 wire format. Visa is a Premier member of the x402 Foundation. Source [1, 35, 81]
Visa Trusted Agent Protocol in the compare matrix (34 dimensions)
Dimension
Value
Confidence
Primary job
Agent identification on merchant web requests The agent signs each request with RFC 9421, tagged browse or pay, and may add signed consumer and payment objects.Source [1, 3]
Verified
Layers covered
Identity and trust; carries payment credentials at checkout No settlement, consent or dispute layer; those sit in VIC and card rails.Source [1, 9]
Proprietary Visa specification Visa changes it alone; licensees apply updates within six months; Visa says it will align with IETF, OpenID Foundation and EMVCo.Source [3, 5]
Verified
License (spec and code)
Visa Developer Center Terms plus TAP Product Terms (revocable, no modification) Sample files carry MIT-style headers, conflicting with LICENSE.md.Source [5, 17]
No version number; launched 2025-10-14 Sample repository last changed 2025-10-28.Source [1, 6]
Verified
Maturity
Live at named merchants, still in development Live European purchases 2026-07-02; overview says development and deployment, not in all markets.Source [4, 7]
Verified
Transports
HTTP headers and request body No published MCP or ACP binding.Source [1]
Verified
Settlement rails
Card (Visa network) TAP itself moves no money.Source [1, 9]
Verified
Agent identity model
RFC 9421 signature with a key registered by the payment scheme Key store at mcp.visa.com/.well-known/jwks; onboarding not public.Source [1, 10]
Verified
User authorization model
None in TAP; passkey-approved Payment Instructions in VIC The ID Token can carry auth_time and amr.Source [1, 9]
Verified
Human-present and human-not-present support
Agent acting for a consumer who approved an instruction in VIC TAP has no presence indicator.Source [1, 9]
Verified
Merchant of record
The merchant TAP does not change who sells.Source [1]
Verified
Credential type
Agent signing key; VIC agent-specific network token in the payment container Credential hash, encrypted payload or browsingIOU depending on processing path.Source [1, 9]
Verified
Cryptography
RFC 9421 (Ed25519 in examples), PS256 body objects, JWT and JWS ID Token Source [1, 8]
Verified
Replay protection
8-minute window plus nonce; nonce tracking optional Source [1]
Centralized: one Visa-controlled key store Source [1, 27]
Verified
Observability score
1 of 5 Public JWKS and repository; no events, logs or counts.Source [7, 10]
Verified
Fees and who pays them
No TAP fee stated; VIC production fees on request; no agent-specific interchange published Evidence of absence from Visa pages and secondary reviews (2026).Source [5, 9, 69, 72]
Reported
Who pays (short)
Card economics unchanged Merchant pays usual acquiring fees.Source [24, 69]
No. TAP is a Visa specification on the Visa Developer Center under Visa's own revocable Product Terms. Visa says it will align with the IETF, the OpenID Foundation and EMVCo, but none of them publishes TAP. Source [1, 3, 5]
MisconceptionDoes TAP move money?
No. TAP identifies the agent and can carry payment data in a signed container. The payment itself runs through Visa Intelligent Commerce tokens and ordinary card authorization. Source [1, 9]
MisconceptionIs TAP the same as Web Bot Auth?
No. Both use RFC 9421, and TAP says it is aligned with web-bot-auth, but TAP predates the 2026-09-01 working group draft and differs from it: its own two tags, no required Signature-Agent header, a mandatory nonce, an 8-minute window and Visa's own key store. Source [1, 3, 14]
MisconceptionIs a Visa agentic token the same as a Mastercard agentic token?
No. Visa's agent credentials are agentic network tokens in Visa Intelligent Commerce; Mastercard Agentic Tokens are a separate Agent Pay product on another network. Source [9, 15, 16]
Which tags does TAP use?
agent-browser-auth for browsing and agent-payer-auth for checkout and payment. A request with neither was not signed by a trusted agent. Mastercard uses a single tag, Agent-pay-auth. Source [1, 42]
MisconceptionCan I verify the specification's example request?
No. The example values come from a Web Bot Auth test vector that signs a different base, the browsing and checkout examples share one signature, and the example window is 3,600 seconds against TAP's 8-minute limit. Source [1, 14]
Where do I get the agent's public key?
The specification points to https://mcp.visa.com/.well-known/jwks. On 2026-10-11 that JWKS held one RSA key from a Visa sandbox CA and no Ed25519 key, and Visa has not said how production agent keys are distributed. Source [1, 10]
MisconceptionDoes the signature protect the request body?
No. The minimum covered components are @authority and @path; method, query and a content digest are not required. The body objects carry their own signatures, linked by the nonce and key. Source [1, 32]
MisconceptionMust a merchant adopt TAP to accept agent purchases?
No. Merchants are not required to use TAP or register with a payment scheme, and those that have not adopted it can ignore the signatures. Source [1]
MisconceptionIs the sample code open source?
Not clearly. LICENSE.md binds users to Visa's terms while the source files carry MIT-style headers, and GitHub reports no recognized license. Which text governs is not stated; treat the code as covered by Visa's terms until Visa clarifies. Source [6, 17]
MisconceptionDoes TAP shift chargeback liability?
No agent-specific liability shift has been published. Worldpay wrote on 2026-07-30 that none exists yet, and properly tokenized agent transactions follow existing rules. Source [24]
R. Open questions and research frontier
How do production agent keys reach merchants and CDNs?
The published JWKS held one RSA sandbox key on 2026-10-11, while the examples use Ed25519. Visa has not documented another channel. Source [1, 10]
Will TAP converge on the Web Bot Auth working group draft?
Visa says it will align with the IETF, and the draft -00 appeared on 2026-09-01, but tags, key discovery and nonce rules differ today. Source [3, 14]
What is the canonical byte form for body object signatures?
The specification says fields in the order received, with no canonicalization and no test vector; an open issue asks for one. Source [1, 6]
Who carries the loss when an agent buys the wrong thing?
No agent-specific liability rule exists; Worldpay says none yet, and regulators in the UK are consulting. Source [24, 62]
Will Visa and Mastercard share one key directory?
The TAP specification names a shared approach as a goal, but each network hosts its own today, and Mastercard's location is unknown. Source [1, 27, 42]
How many merchants verify TAP, and how much traffic is signed?
No count is published; only four merchants were named live on 2026-07-02. Source [7]
How is a browsingIOU settled, and what happens on default?
The merchant grants access expecting funds at settlement, but TAP defines no settlement or default rule. Source [1]
What standing does a payment instruction keep after its agent is revoked?
An open repository issue asks this, and TAP defines no revocation channel. Source [1, 6]
S. Self-test
Quiz
0 of 10 answered.
Flashcards
0 of 15 marked known. Card 1 of 15.
Prompt
Signature-Input
T. Notes
Notes stay in this browser. Nothing is sent anywhere.