FIDO Alliance (Payments Technical Working Group and Agentic Authentication Technical Working Group), Google (code samples and SDK in google-agentic-commerce/AP2)
Status
Draft v0.2 is a published specification with JSON Schemas, a Python SDK and samples. Production use of mandates is unverified anywhere, including inside UCP.
AP2 defines signed mandates that prove what a user approved an agent to buy. Version 0.2 has Checkout and Payment Mandates, each closed (exact values) or open (constraints), carried inside a commerce protocol such as UCP.
Why it exists
When an agent pays, the merchant, the card issuer and the network cannot tell whether the person behind it agreed to this purchase. Today's payment systems assume a human clicked buy. AP2 gives every party a signed, checkable record of what the user approved: either the exact checkout and amount, or a set of limits (merchants, items, price range, budget, dates) inside which the agent may close a purchase on its own. The record later serves as evidence in a dispute.
What it is not
Not a payment rail. AP2 moves no money; it carries authorization evidence on top of cards, bank transfers or stablecoins. Source [8, 13]
Not A2A. A2A is one transport that the samples use; v0.2 treats AP2 as a security feature inside a commerce protocol. Source [7, 13]
Not a Google-only project any more. Google donated it to the FIDO Alliance on 2026-04-28, and specification work now sits with FIDO working groups. Source [1, 2, 3, 5]
Not the three mandates of 2025. Version 0.2 has no Intent Mandate and no Cart Mandate, only Checkout and Payment Mandates. Source [13, 19, 21, 22]
Not proven in production. No primary source shows live use of AP2 mandates, inside UCP or anywhere else. Source [1, 12]? unverified
Not Stripe's MPP and not Visa's TAP. In AP2, MPP is the Merchant Payment Processor role, and Trusted Agent Provider is a delegation model. Source [7, 13, 15, 23]
Not built on W3C VC 2.0 or DIDs. v0.2 uses SD-JWT VC, OpenID4VP and the Digital Credentials API; VC 2.0 and DIDs are only the wider family. Source [15]
Key facts as of 2026-10-11
Steward
FIDO Alliance working groups for the specification; Google for the GitHub samples and SDK Source [1, 2, 3, 4]
Governance
Donated to FIDO on 2026-04-28; the Agentic Authentication group was new that day, the Payments group already existed; no FIDO deliverable published Source [2, 4, 5, 6]? unverified
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 3 field tables and wire examples.
STE mode: section B is hidden; the Simplified Technical English version (section D) is shown first.
Imagine you send a helper to the shops with a signed note from you. There are two kinds of note.
The first kind is exact: “Buy this pair of boots, from this shop, for this price, paid with my blue card.” You read it on your own phone, which you trust, and you sign it there. The helper cannot change a word, because the shop, the bank and the card company can all check your signature and see that the note matches the receipt the shop wrote.
The second kind is a list of limits: “Buy one tent from this shop or that one, spend no more than three hundred, and do it before Friday.” You sign that list and also write down the helper’s own stamp. Later, when the helper finds a good tent, it writes an exact note itself and stamps it. Anyone can check two things: that the stamp is the one you named, and that the exact note stays inside your limits. If something looks odd, the shop can say “please ask the owner,” and you approve the exact purchase yourself.
At the end, the shop and the bank each give a signed receipt that points back to the note. If there is an argument later, everyone can line up the notes and the receipts and see what you agreed to.
That is AP2. The notes are called , your phone is the trusted surface, and the helper is a shopping agent. AP2 does not move the money itself. The money still travels over cards, bank transfers or digital tokens. And there is one thing the notes cannot do yet: you cannot tear up a note early. It simply runs out at the time written on it.
AP2 (the Agent Payments Protocol) answers one question: when an agent pays, how can the merchant, the card issuer and the network tell what the person behind it actually agreed to? Its answer is the mandate, a signed record of user approval.Source [13] Version 0.2 has two kinds, Checkout Mandates and Payment Mandates, and each comes closed (the exact checkout and amount) or open ( such as merchants, items, a price range or a budget).Source [13, 16, 19, 21, 31] A user signs closed mandates on a non-agentic , or signs open mandates that name the agent’s key, so the agent can later sign closed ones itself.Source [13, 32] Hashes of the merchant-signed checkout tie every mandate and every receipt to one transaction.Source [15, 19, 21, 33, 34] What AP2 does not give you: a payment rail, a way to revoke a mandate early, step-up authentication in v0.2, or proof that it runs in production anywhere.Source [1, 8, 12, 13, 15, 32, 35]? unverified Money still moves over cards, bank transfers or stablecoins, and the checkout messages come from a commerce protocol such as the Universal Commerce Protocol (UCP).Source [8, 13]
Problem and design goals
AP2, the Agent Payments Protocol, was announced by Google on 2025-09-16, with more than 60 organizations named as collaborators.Source [8] The problem it targets is evidence. Card and bank systems were built on the assumption that a person pressed the buy button, so when software presses it, nobody downstream can tell whether the purchase matches what the person wanted. AP2 adds a signed artifact that every party can check in code and keep for later disputes.Source [13]
Three design choices follow from that goal. First, AP2 assumes that cannot be prevented, so it treats every large language model (LLM) and every agent as a potential attacker.Source [36] The person approves on a Trusted Surface that must be non-agentic, and every role validates in deterministic code, agentic or not.Source [13] Second, AP2 is a security layer, not a commerce or payment protocol. Version 0.2 describes itself as a feature inside a commerce protocol and leaves catalog, cart and checkout calls to that protocol; it is designed to fit UCP.Source [7, 13] Third, it is rail-agnostic: the mandate carries authorization evidence on top of whatever payment method the parties already use, and AP2 defines no fee of its own.Source [8, 13]
Read the version label carefully. Most explanations written in 2025 describe v0.1, which had Intent, Cart and Payment Mandates. Version 0.2 removed the Intent and Cart Mandates entirely.Source [13, 19, 21, 22]
Actors and roles
Version 0.2 defines five roles.Source [13] The (SA) finds products, builds the checkout and presents mandates; the specification expects it to be agentic. The (CP) holds payment credentials, verifies the and issues a token scoped to the purchase. The Merchant signs the checkout and verifies the . The processes the payment and checks that the credential belongs to this checkout. The Trusted Surface (TS) shows the user what they are approving and obtains their consent before any user-signed mandate exists; it must be non-agentic.Source [13] The payment network is not one of the five roles, but it can verify Payment Mandates and receives Payment Receipts.Source [13, 32]
Two naming traps sit here. AP2 abbreviates Merchant Payment Processor as MPP, which has nothing to do with the Machine Payments Protocol from Stripe and Tempo.Source [13, 23] And one entity may play several roles at once, while any role may hand its verification duties to a provider, for example a merchant to its processor.Source [13] A Credential Provider can be a digital wallet, a payment network, or an instrument store run by the agent or the merchant.Source [35] A Trusted Surface can be a deterministic part of the agent app, a standalone wallet or issuer app, or a trusted user agent such as a mobile platform or a browser.Source [35]
Who signs depends on the delegation model. Under the , a credential issued to the user (for example a payment credential in a wallet) signs, and verifiers trust the issuer to vouch for the Trusted Surface. Under the model, the agent’s provider signs with a key the agent itself must not be able to use without the Trusted Surface, and verifiers keep a list of trusted providers.Source [13, 15] Despite the name, Trusted Agent Provider has no link to Visa’s Trusted Agent Protocol.Source [7, 15] Version 0.1 had six differently named roles, including a separate Network and Issuer role.Source [37]
Core objects
Every v0.2 mandate is an (a secured as a Selective Disclosure JSON Web Token), and its type travels in the vct claim.Source [15] The type strings carry a version suffix, mandate.checkout.1 for example, and implementations must match the whole string.Source [13]
The (mandate.checkout.1) wraps the merchant-signed checkout. It requires vct, checkout_jwt and checkout_hash, and allows iat and exp.Source [21]checkout_jwt is the merchant’s signed checkout as a JSON Web Token (JWT), and it may be disclosed selectively. checkout_hash is its hash, using SHA-256 unless the SD-JWT names another algorithm.Source [21, 33] AP2 does not care what is inside the checkout, except that it must be a UCP Checkout object when AP2 runs inside UCP.Source [33]
The closed Payment Mandate (mandate.payment.1) defines ten fields: vct, transaction_id, payee, pisp, payment_amount, payment_instrument, execution_date, risk_data, iat and exp.Source [19] Five are required: vct, transaction_id, payee, payment_amount and payment_instrument.Source [19]transaction_id is the same hash of checkout_jwt, which is what binds the payment to one checkout.Source [19] Amounts are integers in minor units of an ISO 4217 currency: 279.99 USD is 27999.Source [19, 38]risk_data carries signals the Trusted Surface collected, and a missing execution_date means pay now.Source [19]pisp names a , a European open-banking role.Source [38]
Open mandates replace exact values with constraints. The open Checkout Mandate (mandate.checkout.open.1) requires constraints and cnf, and its constraints must include at least one checkout.line_items.Source [31] The open Payment Mandate (mandate.payment.open.1) requires the same two fields and must include a payment.reference constraint.Source [16]cnf is the confirmation claim that holds the agent’s public key.Source [15, 16] An open Payment Mandate may also pre-set a payee, amount, instrument or PISP; the closed mandate made from it must then carry every required field.Source [15, 16, 17]
There are ten constraint types. Checkout has checkout.allowed_merchants and checkout.line_items.Source [31] Payment has payment.agent_recurrence, payment.allowed_payees, payment.allowed_payment_instruments, payment.allowed_pisps, payment.amount_range, payment.budget, payment.execution_date and payment.reference.Source [16] A verifier must treat any constraint type it does not recognize as failed.Source [15]
Two receipts close the loop. The , signed by the processor, requires status, iss, iat, reference and payment_id, plus confirmation ids on success or an error code on failure.Source [34] The Checkout Receipt, signed by the merchant, carries order_id on success.Source [34] Each reference is the hash of the closed mandate it answers.Source [15, 34]
Field tables. Spec version v0.2, generated from the JSON Schemas under code/sdk/schemas/ap2/ at commit e1ea56d, which are identical to tag v0.2.0 for these files. Descriptions are paraphrased. “Required” follows each schema’s required array.
Closed Checkout Mandate (checkout_mandate.json)Spec version v0.2
Two schema quirks to know. The vct descriptions say, for example, “MUST be ‘mandate.payment’” while the constant is mandate.payment.1; the constant is what validates.Source [19, 21]payment.amount_range is typed as integer minor units, but the documentation example uses 100.50, and payment.budget has no stated unit at all.Source [16, 17]
Illustrative example, spec version v0.2: the decoded disclosure of an open Payment Mandate. Hashes and key coordinates are shortened.
Verifiers always receive closed mandates, whatever the mode; what changes is how they trust the signature.Source [13] The main sequence in section C plays the human-present mode, which the specification calls direct.Source [13, 32]
The agent builds a cart with the merchant over the commerce protocol, and the merchant returns a signed checkout and asks for a mandate.Source [13, 21]
The agent fetches instrument options from the Credential Provider and picks one.Source [32]
The agent sends the Checkout and Payment Mandate Content to the Trusted Surface, which shows it, authenticates the user (for example with a biometric) and signs both closed mandates. The hash of checkout_jwt sits in both, linking them for good.Source [13, 19, 21, 32, 33]
The agent presents the Payment Mandate to the Credential Provider, which verifies it and creates a payment token, possibly getting a scoped credential from the network.Source [32] The token is released only after a final Payment Mandate is verified.Source [36]
The agent sends the token and the Checkout Mandate to the merchant. The merchant checks the mandate against the current cart and checkout_hash, then starts the payment.Source [13, 32] For a push payment method it instead waits for confirmation that the funds were sent.Source [13]
The processor checks the Payment Mandate inside the token and its binding to the checkout hash.Source [13, 32]
The processor returns a signed Payment Receipt to the agent, the Credential Provider and the network; the merchant returns a signed Checkout Receipt to the agent.Source [13, 32]
The specification itself notes that, because the user approves the exact checkout, this mode can often be replaced by an ordinary e-commerce journey between merchant and Trusted Surface.Source [13] The interesting mode is the other one. In human-not-present (autonomous) mode the user signs open mandates that include the agent’s key in cnf, and leaves.Source [13, 32] Later the agent finds a checkout, signs closed mandates with its own key, and sd_hash binds each closed mandate to its open parent.Source [15, 24, 32] Verifiers check the chain, check that the closed mandate keeps every value the open one fixed, and evaluate each constraint.Source [15] The agent must present only the disclosures needed for that evaluation.Source [13]
Failures come back as signed receipts with one of four codes: invalid_credential, unresolved_constraint, invalid_mandate and mandates_not_supported.Source [13, 15] The first and third are terminal; the other two may signal a fallback.Source [15] A merchant that cannot confirm the constraints answers unresolved_constraint, and the agent can turn the purchase into a human-present one by bringing the user back.Source [32] Section C plays that fallback, a broken chain and an unsupported verifier, plus the dispute check and the delegation path.
Action authorization errors (agent_authorization.md, Errors)Spec version v0.2
Unknown constraint, or conformance cannot be confirmed. May signal a fallback to a user-approved closed mandate or a non-agentic flow. Spec reference for unresolved_constraint
Delegation with OpenID4VP. Under the User Credential model the agent places a delegation object in the transaction_data array of an OpenID for Verifiable Presentations (OpenID4VP) request, and the wallet’s covers delegate_payload.Source [15] The is the recommended channel.Source [15] The example asks for a credential with vctcom.emvco.dpc and uses response_modedc_api with ES256.Source [15]
OpenID4VP transaction_data entry for delegationSpec version v0.2
Verification order (Agent Authorization, Verification and Processing Rules): process the chain under ; check that the closed Mandate Content keeps the open values unchanged; evaluate each constraint, failing unknown ones.
Lifecycle and states
AP2 v0.2 defines no session status enum, but its objects move through clear states. A mandate is open (bound to an agent key, with constraints) or closed (bound to one transaction).Source [15] A presentation ends in a receipt whose status is Success or Error.Source [34] After a success, the agent stores the , the closed mandate and the receipt together. It then narrows the open mandate, often so that it cannot be used again.Source [15]payment.budget and payment.agent_recurrence allow bounded reuse, which means somebody must remember earlier presentations.Source [16, 17]
Two rules keep the states honest. The agent must not present a new closed mandate from the same open mandate until it holds a rejection receipt for the previous one, which prevents one approval from paying for several checkouts.Source [13] And open mandates should expire as soon as the task allows, because expiry is the only exit: v0.2 defines no way to revoke a mandate before exp.Source [13, 15, 35]
Security and trust model (summary)
The notes are hard to fake and hard to reuse: each one names the exact checkout, and a note written by the helper only counts if it carries the stamp you named. But a note cannot stop the helper from being tricked into choosing a bad tent within your limits, and you cannot cancel a note early.
The guarantees are strong where hashes reach. A stolen Payment Mandate is useless for another checkout because transaction_id names this one; a reused open mandate fails because closed mandates carry sd_hash and must be signed with the key in cnf.Source [15, 16, 19, 32] Selective disclosure is mandatory for constraints, digests are salted, and decoy digests are allowed, so a merchant need not learn the rest of the user’s limits.Source [13, 36]
The gaps sit before the signature and after it. Research on v0.2 found 48 threats, eight in the High band, and its central point is that a valid signature does not prove the transaction reflects intent if the context before authorization was manipulated.Source [12] Prompt-injection studies on AP2 sample agents steered product choice and extracted data.Source [39, 40] Replay across retries and concurrency needs consume-once checks that the specification does not define.Source [25, 41] Version 0.2 specifies no step-up authentication: a failed check falls back through unresolved_constraint, while v0.1 let any party demand a 3DS2 or one-time-password challenge.Source [15, 32, 37] The non-normative Executive Summary still mentions 3DS2, which is legacy wording.Source [15, 42] Liability stays with the payment networks.Source [1, 37] No CVE (Common Vulnerabilities and Exposures) entry or GitHub advisory exists for the repository.Source [43] Section H has the full threat table.
Versioning and governance
Two tagged versions exist: v0.1.0 on 2025-09-16 and v0.2.0 on 2026-04-28.Source [9, 10] The v0.2 document is titled “Agentic Payment Protocol (v0.2)”, though the project name everywhere else is Agent Payments Protocol.Source [13] Inside a version, each mandate type versions itself through its vct suffix.Source [13] The figure in section C shows the v0.1 to v0.2 model change.
Governance moved on the day v0.2 shipped. Google donated AP2 to the on 2026-04-28 to keep it platform-agnostic and community-led, and Mastercard contributed its framework at the same time.Source [4, 5] FIDO formed one new group that day, the Agentic Authentication Technical Working Group, chaired by members from CVS Health, Google and OpenAI.Source [4, 6] The payments group, chaired by Mastercard and Visa, already existed since 2025-04-29 and is where the contributions are to be developed.Source [4, 6] FIDO gave no deliverable or date, and no public FIDO draft based on AP2 was found as of 2026-10-11.Source [2, 4]? unverified So governance sits with FIDO, not with Google alone; Google keeps improving the samples and SDK.Source [1, 2, 3] The repository is Apache-2.0 and exported from Google’s internal tree.Source [7] No commit has landed on main since 2026-04-29, while outside contributors opened 43 issues and 58 pull requests up to 2026-10-11, none merged.Source [11, 25]
Extensibility
The specification names four extension points: constraints, the checkout object, payment instruments and credential formats.Source [13, 15, 33, 38] New constraints need a unique type, a schema that marks which fields are selectively disclosable, and an evaluation algorithm.Source [13] New payment instruments define a new type in the instrument object.Source [38] The checkout is opaque to AP2, so other checkout formats can be signed, though UCP’s own extension points are the recommended route.Source [33] And SD-JWT is the specified format, with other verifiable credential formats possible.Source [15] W3C Verifiable Credentials 2.0 and decentralized identifiers (DIDs) belong to the wider credential family; v0.2 does not depend on them.Source [15] Agent-to-agent delegation is conceptually possible and explicitly out of scope.Source [13]
How it composes with the other seven
AP2 needs a commerce protocol around it, and UCP is the one it was built for. UCP’s extension was renamed dev.ucp.common.payment.ap2_mandate in v2026-08-25. It puts the merchant’s signature in ap2.merchant_authorization, the Checkout Mandate in ap2.checkout_mandate and the Payment Mandate in the payment credential token.Source [14, 27, 28, 44] x402 joins through the a2a-x402 extension, whose embedded flow targets AP2 v0.1 objects.Source [18, 19] Mastercard’s Verifiable Intent shares AP2’s mandate types.Source [20, 21] The AP2 repository does not mention ERC-8004, Visa TAP, OpenAI ACP or the Machine Payments Protocol.Source [7] Section P covers each pairing.
Limitations and open issues
The specification has visible loose ends. The signature rule contradicts itself: the main text forbids deterministic signatures such as Ed25519, while the security considerations allow them with enough salt; issue 268 has tracked this since 2026-05-26.Source [3, 13, 36] The Mandate Receipt prose uses a result field where the schemas use status.Source [15, 34, 45] The security document writes mandate.payment.reference where the schema says payment.reference.Source [16, 36] The specification dates RFC 9901 to February 2025; the RFC Editor says November 2025.Source [15, 46] Mandate chaining depends on Delegate SD-JWT, an individual draft posted to the IETF on 2026-04-22.Source [24]
Practical gaps matter more. There is no revocation, no agent registry and no agent identification beyond the key in cnf; who the agent is belongs to the commerce layer.Source [15, 35] Stateful constraints need a party to track history, and the specification does not say who.Source [16, 17] Dispute retention, retrieval and adjudication are out of scope.Source [13] The Python SDK is not on PyPI, and the PyPI and npm packages named ap2 belong to strangers.Source [7, 47] Above all, production use of AP2 mandates is unverified anywhere, including inside UCP; one third party self-reports a deployment.Source [1, 12, 48]? unverified
What changed in 2025 and 2026
2025-09-16: launch with v0.1 (Intent, Cart and Payment Mandates) and the a2a-x402 extension built with Coinbase, the Ethereum Foundation and MetaMask.Source [8, 22, 49]
2025-10-30 and 2025-12-15: Tether, Solana and OKX joined the partners page; x402 support reached the Python samples.Source [11, 50]
2026-01-11: UCP’s first commit already carried an AP2 mandates extension.Source [14, 29]
2026-04-28: v0.2 replaced the three mandates with open and closed Checkout and Payment Mandates, removed the partners page, dropped step-up authentication (v0.1 had 3DS2 and OTP challenges), and moved to the FIDO Alliance.Source [5, 9, 10, 13, 15, 19, 21, 32, 37, 50, 51, 52]
2026-05-19: Google said AP2 would come to Google products, starting with Gemini Spark.Source [26]
Main flow: AP2 v0.2 human present: the user signs closed mandates on a Trusted Surface
The direct mode. The merchant signs the checkout, the user approves the exact Checkout and Payment Mandates on a non-agentic Trusted Surface, the Credential Provider verifies the Payment Mandate and issues a token, the merchant and its processor verify the hash bindings, and both sides return signed receipts.
User
Shopping Agent
Trusted Surface
Merchant
Credential Provider
Network
Merchant Payment Processor
1
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 16User toto Shopping Agent
Start shopping
The user asks the Shopping Agent to find and buy something. AP2 defines nothing about this exchange; the flows in the specification assume enrollment and any user credential already exist.
Step 1 of 16: User to Shopping Agent. Start shopping.
Sequence diagram: AP2 v0.2 human present: the user signs closed mandates on a Trusted Surface
Scroll to see the whole diagram
Generated from the flow definition (spec version v0.2, 2026-04-28). The player above uses the same data.
Text alternative
Sequence diagram: AP2 v0.2 human present: the user signs closed mandates on a Trusted Surface. 7 participants: User, Shopping Agent, Trusted Surface, Merchant, Credential Provider, Network, and Merchant Payment Processor. 16 steps, 12 crossing a trust boundary, 8 failure branches. Based on ap2 v0.2 (2026-04-28). Step 1: User to Shopping Agent: Start shopping. Step 2: Shopping Agent to Merchant: Build a cart over the commerce protocol. This step crosses a trust boundary. If The merchant does not accept mandates for this action: It can answer mandates_not_supported, a signal to fall back to a non-agentic flow. Step 3: Merchant to Shopping Agent: Signed checkout (checkout_jwt); mandate required. This step crosses a trust boundary. If The cart changes after this point: The merchant will reject any mandate whose checkout_hash does not match its latest checkout_jwt. Step 4: Shopping Agent to Credential Provider: Fetch instrument options. This step crosses a trust boundary. Step 5: Shopping Agent to Trusted Surface: Request approval of Checkout and Payment Mandate Content. This step crosses a trust boundary. Step 6: Trusted Surface to User: Show the content; authenticate and get consent. If The user declines: No mandate is signed and nothing is presented. Step 7: Trusted Surface to Trusted Surface: Sign closed mandates with user_sk. Step 8: Trusted Surface to Shopping Agent: Return the signed mandates. This step crosses a trust boundary. Step 9: Shopping Agent to Credential Provider: Present the closed Payment Mandate. This step crosses a trust boundary. If The signature or chain does not verify: Payment Receipt with status Error and error invalid_credential; terminal. If The mandate does not approve this payment: Payment Receipt with error invalid_mandate; terminal. Step 10: Credential Provider to Network: Share the mandate, get a scoped credential (optional). This step crosses a trust boundary. Step 11: Credential Provider to Shopping Agent: Payment token. This step crosses a trust boundary. Step 12: Shopping Agent to Merchant: Token plus closed Checkout Mandate. This step crosses a trust boundary. If The hash of the merchant's checkout_jwt does not equal checkout_hash: The merchant returns a Checkout Receipt JWT with status Error. If A verification step fails for any other reason: The merchant must return a Checkout Receipt JWT carrying the error. Step 13: Merchant to Merchant Payment Processor: Initiate payment with the token and the checkout_jwt hash. This step crosses a trust boundary. Step 14: Merchant Payment Processor to Merchant Payment Processor: Verify the Payment Mandate inside the token. If transaction_id does not match the checkout_jwt hash: The payment is refused and a Payment Receipt with status Error goes back. Step 15: Merchant Payment Processor to Shopping Agent: Payment Receipt (also to the Credential Provider and Network). This step crosses a trust boundary. Step 16: Merchant to Shopping Agent: Checkout Receipt. This step crosses a trust boundary.
Step 1: User to Shopping Agent: Start shopping.
Step 2: Shopping Agent to Merchant: Build a cart over the commerce protocol. This step crosses a trust boundary. If The merchant does not accept mandates for this action: It can answer mandates_not_supported, a signal to fall back to a non-agentic flow.
Step 3: Merchant to Shopping Agent: Signed checkout (checkout_jwt); mandate required. This step crosses a trust boundary. If The cart changes after this point: The merchant will reject any mandate whose checkout_hash does not match its latest checkout_jwt.
Step 4: Shopping Agent to Credential Provider: Fetch instrument options. This step crosses a trust boundary.
Step 5: Shopping Agent to Trusted Surface: Request approval of Checkout and Payment Mandate Content. This step crosses a trust boundary.
Step 6: Trusted Surface to User: Show the content; authenticate and get consent. If The user declines: No mandate is signed and nothing is presented.
Step 7: Trusted Surface to Trusted Surface: Sign closed mandates with user_sk.
Step 8: Trusted Surface to Shopping Agent: Return the signed mandates. This step crosses a trust boundary.
Step 9: Shopping Agent to Credential Provider: Present the closed Payment Mandate. This step crosses a trust boundary. If The signature or chain does not verify: Payment Receipt with status Error and error invalid_credential; terminal. If The mandate does not approve this payment: Payment Receipt with error invalid_mandate; terminal.
Step 10: Credential Provider to Network: Share the mandate, get a scoped credential (optional). This step crosses a trust boundary.
Step 11: Credential Provider to Shopping Agent: Payment token. This step crosses a trust boundary.
Step 12: Shopping Agent to Merchant: Token plus closed Checkout Mandate. This step crosses a trust boundary. If The hash of the merchant's checkout_jwt does not equal checkout_hash: The merchant returns a Checkout Receipt JWT with status Error. If A verification step fails for any other reason: The merchant must return a Checkout Receipt JWT carrying the error.
Step 13: Merchant to Merchant Payment Processor: Initiate payment with the token and the checkout_jwt hash. This step crosses a trust boundary.
Step 14: Merchant Payment Processor to Merchant Payment Processor: Verify the Payment Mandate inside the token. If transaction_id does not match the checkout_jwt hash: The payment is refused and a Payment Receipt with status Error goes back.
Step 15: Merchant Payment Processor to Shopping Agent: Payment Receipt (also to the Credential Provider and Network). This step crosses a trust boundary.
Step 16: Merchant to Shopping Agent: Checkout Receipt. This step crosses a trust boundary.
Lifecycle: AP2 v0.2 mandate lifecycle (open and closed mandates, presentation and receipts)
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.
Transition
Mandate Content drafted to Open mandate signed
Trigger
User approves constraints on the Trusted Surface
API call
Trusted Surface signs with user_sk (or OpenID4VP transaction_data type delegate)
Spec reference
flows.md Human Not Present, Phase 1a step 4
About Open mandate signed
vct mandate.checkout.open.1 or mandate.payment.open.1, signed by the user or a trusted agent provider. Bound to the agent key, not to a transaction.
State notes
Mandate Content drafted
Unsigned content built by the Shopping Agent: closed (exact checkout and payment) or open (constraints plus the agent key in cnf).
Open mandate signed
vct mandate.checkout.open.1 or mandate.payment.open.1, signed by the user or a trusted agent provider. Bound to the agent key, not to a transaction.
Closed mandate signed
vct mandate.checkout.1 or mandate.payment.1. Bound to one checkout through checkout_hash and transaction_id; agent-signed closed mandates carry sd_hash over the open parent.
Presented to a verifier
Merchant, Credential Provider, Network or processor. The agent must not present another closed mandate from the same open mandate until it holds an error receipt.
Accepted (receipt status Success)
Signed Payment or Checkout Receipt whose reference is the hash of the closed mandate.
Rejected, fallback possible
unresolved_constraint or mandates_not_supported: a signal to fall back to a user-approved closed mandate or a non-agentic flow.
Rejected, terminal
invalid_credential or invalid_mandate.
Open mandate narrowed or used up
The agent stores the open, closed and receipt tuple and reduces the open mandate's scope; payment.budget and payment.agent_recurrence allow bounded reuse.
Purchase evidence stored
Both mandates and both receipts can later be checked by a dispute verifier.
Expired
exp passed. v0.2 defines no revocation, so expiry is the only built-in end for an open mandate.
Spec version v0.2.
State diagram: AP2 v0.2 mandate lifecycle (open and closed mandates, presentation and receipts)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Generated from the state machine definition (spec version v0.2).
Text alternative
State diagram: AP2 v0.2 mandate lifecycle (open and closed mandates, presentation and receipts). 10 states: Mandate Content drafted, Open mandate signed, Closed mandate signed, Presented to a verifier, Accepted (receipt status Success), Rejected, fallback possible, Rejected, terminal, Open mandate narrowed or used up, Purchase evidence stored, and Expired. Starts in Mandate Content drafted. Ends in Rejected, terminal, Purchase evidence stored, and Expired. 14 transitions. From Mandate Content drafted to Open mandate signed when User approves constraints on the Trusted Surface (Trusted Surface signs with user_sk (or OpenID4VP transaction_data type delegate)). From Mandate Content drafted to Closed mandate signed when User approves the exact checkout on the Trusted Surface (Trusted Surface signs mandate.checkout.1 and mandate.payment.1 with user_sk). From Open mandate signed to Closed mandate signed when Agent finds a checkout that fits the constraints (Agent signs a key-binding JWT with the key in cnf (sd_hash over the open mandate)). From Closed mandate signed to Presented to a verifier when Agent presents the mandate chain (Payment Mandate to the Credential Provider; Checkout Mandate with the token to the Merchant). From Presented to a verifier to Accepted (receipt status Success) when Verifier checks chain, bindings and constraints (Receipt JWT with status Success). From Presented to a verifier to Rejected, fallback possible when Constraint cannot be confirmed, unknown constraint, or mandates not used (Receipt JWT with status Error, error unresolved_constraint or mandates_not_supported). From Presented to a verifier to Rejected, terminal when Signature or chain fails, or the mandate does not approve the action (Receipt JWT with status Error, error invalid_credential or invalid_mandate). From Rejected, fallback possible to Mandate Content drafted when Fallback: user brought back to approve a closed mandate (New request to the Trusted Surface). From Rejected, fallback possible to Open mandate signed when Agent may try a different closed mandate from the same open mandate (Error receipt held by the agent). From Accepted (receipt status Success) to Open mandate narrowed or used up when Success receipt for an agent-signed mandate (Agent stores open, closed and receipt tuple). From Accepted (receipt status Success) to Purchase evidence stored when Both receipts returned (Payment Receipt from the processor, Checkout Receipt from the Merchant). From Open mandate narrowed or used up to Closed mandate signed when Budget or recurrence still allows another purchase (payment.budget and payment.agent_recurrence evaluated against earlier presentations). From Open mandate signed to Expired when exp reached before use (exp (Unix epoch) on the mandate). From Open mandate narrowed or used up to Expired when exp reached (exp (Unix epoch) on the mandate).
From Mandate Content drafted to Open mandate signed when User approves constraints on the Trusted Surface (Trusted Surface signs with user_sk (or OpenID4VP transaction_data type delegate)).
From Mandate Content drafted to Closed mandate signed when User approves the exact checkout on the Trusted Surface (Trusted Surface signs mandate.checkout.1 and mandate.payment.1 with user_sk).
From Open mandate signed to Closed mandate signed when Agent finds a checkout that fits the constraints (Agent signs a key-binding JWT with the key in cnf (sd_hash over the open mandate)).
From Closed mandate signed to Presented to a verifier when Agent presents the mandate chain (Payment Mandate to the Credential Provider; Checkout Mandate with the token to the Merchant).
From Presented to a verifier to Accepted (receipt status Success) when Verifier checks chain, bindings and constraints (Receipt JWT with status Success).
From Presented to a verifier to Rejected, fallback possible when Constraint cannot be confirmed, unknown constraint, or mandates not used (Receipt JWT with status Error, error unresolved_constraint or mandates_not_supported).
From Presented to a verifier to Rejected, terminal when Signature or chain fails, or the mandate does not approve the action (Receipt JWT with status Error, error invalid_credential or invalid_mandate).
From Rejected, fallback possible to Mandate Content drafted when Fallback: user brought back to approve a closed mandate (New request to the Trusted Surface).
From Rejected, fallback possible to Open mandate signed when Agent may try a different closed mandate from the same open mandate (Error receipt held by the agent).
From Accepted (receipt status Success) to Open mandate narrowed or used up when Success receipt for an agent-signed mandate (Agent stores open, closed and receipt tuple).
From Accepted (receipt status Success) to Purchase evidence stored when Both receipts returned (Payment Receipt from the processor, Checkout Receipt from the Merchant).
From Open mandate narrowed or used up to Closed mandate signed when Budget or recurrence still allows another purchase (payment.budget and payment.agent_recurrence evaluated against earlier presentations).
From Open mandate signed to Expired when exp reached before use (exp (Unix epoch) on the mandate).
From Open mandate narrowed or used up to Expired when exp reached (exp (Unix epoch) on the mandate).
Five roles in four trust zones. The Trusted Surface must be non-agentic and holds the user's signing key; the Shopping Agent is treated as a potential attacker; merchant and payment parties verify mandates in deterministic code. Catalog and checkout messages belong to the surrounding commerce protocol.
Text alternative
Flowchart. The user zone holds the user and the Trusted Surface with user_sk; the user gives consent to the surface. The agent zone holds the Shopping Agent with its key in cnf. The agent sends Mandate Content to the Trusted Surface and gets signed mandates back. The agent shops through a commerce protocol such as UCP or A2A, which talks to the Merchant. The agent sends the Payment Mandate to the Credential Provider, which may ask the Network for a scoped credential and returns a token. The agent sends the token and the Checkout Mandate to the Merchant, which sends the token and the checkout_jwt hash to the Merchant Payment Processor. The processor returns a Payment Receipt and the Merchant a Checkout Receipt to the agent.
Field names from the JSON Schemas in code/sdk/schemas/ap2 at commit e1ea56d (identical to v0.2.0). Closed mandates bind to one checkout; open mandates carry constraints and the agent key. Receipts point back to the closed mandate by hash. Optional fields of the open Payment Mandate (pisp, execution_date, risk_data, iat, exp) are left out for space.
Text alternative
Class diagram. CheckoutMandate has vct mandate.checkout.1, checkout_jwt, checkout_hash, iat and exp. OpenCheckoutMandate has vct mandate.checkout.open.1, constraints, cnf, iat and exp. PaymentMandate has vct mandate.payment.1, transaction_id, payee, pisp, payment_amount, payment_instrument, execution_date, risk_data, iat and exp. OpenPaymentMandate has vct mandate.payment.open.1, constraints, cnf and optional pre-set payee, payment_amount and payment_instrument. Amount has amount and currency; Merchant has id, name, website; PaymentInstrument has id, type, description; PISP has legal_name, brand_name, domain_name. Closed mandates link to their open parents by sd_hash; the open Payment Mandate links to the open Checkout Mandate by payment.reference; PaymentMandate links to CheckoutMandate because transaction_id equals checkout_hash. PaymentReceipt (status, iss, iat, reference, payment_id) and CheckoutReceipt (status, iss, iat, reference, order_id) reference the closed mandates.
From three mandates (v0.1) to two mandate types, open or closed (v0.2)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
v0.1 chained an Intent Mandate, a merchant-signed Cart Mandate and a Payment Mandate. v0.2 removed Intent and Cart: a natural-language intent became machine-checkable constraints, and the cart became a merchant-signed checkout_jwt. Tutorials written in 2025 describe the v0.1 model.
Text alternative
Flowchart in two parts. The v0.1 part shows IntentMandate with natural_language_description, merchants, skus, requires_refundability and intent_expiry, leading to CartMandate with CartContents, a W3C PaymentRequest and a merchant_authorization JWT carrying cart_hash, leading to PaymentMandate with payment_mandate_contents and user_authorization. The v0.2 part shows Open Checkout Mandate (mandate.checkout.open.1, constraints and cnf) and Open Payment Mandate (mandate.payment.open.1) linked by payment.reference, each extended by sd_hash into Closed Checkout Mandate (mandate.checkout.1 with checkout_jwt and checkout_hash) and Closed Payment Mandate (mandate.payment.1 with transaction_id, payee, payment_amount), which are linked because transaction_id equals checkout_hash. Dotted arrows show that IntentMandate was replaced by constraints, CartMandate by the merchant-signed checkout_jwt, and the v0.1 PaymentMandate split into closed and open forms.
Four bindings hold an AP2 purchase together. checkout_hash and transaction_id are both the hash of the merchant-signed checkout_jwt. cnf names the agent key that may close an open mandate, and sd_hash ties each closed mandate to its open parent. payment.reference links the two open mandates. Receipt references point to the closed mandates.
Text alternative
Flowchart. The merchant-signed checkout_jwt is hashed with sha-256 or the _sd_alg algorithm. The hash becomes checkout_hash in the Closed Checkout Mandate and transaction_id in the Closed Payment Mandate. In the open group, the Open Checkout Mandate and Open Payment Mandate both carry constraints and cnf with the agent key; the open checkout digest becomes conditional_transaction_id in payment.reference of the open payment mandate. Each open mandate is linked to its closed mandate by sd_hash in the key-binding JWT. The hash of the closed Checkout Mandate is the Checkout Receipt reference and the hash of the closed Payment Mandate is the Payment Receipt reference.
The order of checks from the Verification and Processing Rules: the chain first, then unchanged values, then every constraint. An unknown constraint type always fails. Which error a given failure maps to is partly an interpretation: the specification defines the four codes but does not map each individual check to one of them. Mapping a violated known constraint to unresolved_constraint, rather than invalid_mandate, is this site's reading of the error definitions.
Text alternative
Flowchart. Receive open and closed mandates. If the chain does not verify under Delegate SD-JWT (closed mandate signed by the key in cnf, sd_hash matches), return invalid_credential, terminal. If the closed mandate changes a value the open mandate fixed, return invalid_mandate, terminal. Otherwise take each constraint in turn: an unknown type returns unresolved_constraint; a known constraint that is not satisfied or cannot be checked, for example an amount outside amount_range, a payee outside allowed_payees or unmatched line items, also returns unresolved_constraint. When all constraints pass, return a receipt with status Success. unresolved_constraint may signal a fallback to a user-approved closed mandate or a non-agentic flow.
AP2 v0.2 human not present: the agent closes user-signed open mandates
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The autonomous mode. The user signs open mandates with constraints and the agent public key in cnf, then leaves. Later the agent finds a fitting checkout, signs closed mandates with its own key, and verifiers check the chain (sd_hash), the checkout binding and every constraint.
Text alternative
Sequence diagram: AP2 v0.2 human not present: the agent closes user-signed open mandates. 6 participants: User, Shopping Agent, Trusted Surface, Merchant, Credential Provider, and Merchant Payment Processor. 16 steps, 10 crossing a trust boundary, 4 failure branches. Based on ap2 v0.2 (2026-04-28). Step 1: User to Shopping Agent: Set a shopping task. Step 2: Shopping Agent to Trusted Surface: Request approval of open Mandate Content. This step crosses a trust boundary. If A constraint type the verifier will not know is included: Every verifier must fail it later with unresolved_constraint. Step 3: Trusted Surface to User: Show the constraints; authenticate and get consent. Step 4: Trusted Surface to Trusted Surface: Sign open mandates with user_sk. Step 5: Trusted Surface to Shopping Agent: Return the open mandates; the user leaves. This step crosses a trust boundary. Step 6: Shopping Agent to Merchant: Build a cart autonomously. This step crosses a trust boundary. Step 7: Merchant to Shopping Agent: Signed checkout (checkout_jwt); mandate required. This step crosses a trust boundary. Step 8: Shopping Agent to Shopping Agent: Select open mandates that fit. Step 9: Shopping Agent to Shopping Agent: Sign closed mandates with agent_sk. Step 10: Shopping Agent to Credential Provider: Present open and closed Payment Mandates. This step crosses a trust boundary. If The amount is outside payment.amount_range or the payee is not allowed: Payment Receipt with status Error. The error the specification gives for a closed mandate that cannot be shown to meet the constraints is unresolved_constraint. If The closed mandate is not signed by the key in cnf, or sd_hash does not match: invalid_credential; terminal. Step 11: Credential Provider to Shopping Agent: Payment token. This step crosses a trust boundary. Step 12: Shopping Agent to Merchant: Token plus open and closed Checkout Mandates. This step crosses a trust boundary. If A line item cannot be matched, or the merchant is not in checkout.allowed_merchants: Checkout Receipt with error unresolved_constraint; the agent may bring the user back to approve a closed mandate. Step 13: Merchant to Merchant Payment Processor: Initiate payment with the token and both hashes. This step crosses a trust boundary. Step 14: Merchant Payment Processor to Shopping Agent: Payment Receipt. This step crosses a trust boundary. Step 15: Merchant to Shopping Agent: Checkout Receipt. This step crosses a trust boundary. Step 16: Shopping Agent to Shopping Agent: Store the tuple and narrow the open mandate.
Step 1: User to Shopping Agent: Set a shopping task.
Step 2: Shopping Agent to Trusted Surface: Request approval of open Mandate Content. This step crosses a trust boundary. If A constraint type the verifier will not know is included: Every verifier must fail it later with unresolved_constraint.
Step 3: Trusted Surface to User: Show the constraints; authenticate and get consent.
Step 4: Trusted Surface to Trusted Surface: Sign open mandates with user_sk.
Step 5: Trusted Surface to Shopping Agent: Return the open mandates; the user leaves. This step crosses a trust boundary.
Step 6: Shopping Agent to Merchant: Build a cart autonomously. This step crosses a trust boundary.
Step 7: Merchant to Shopping Agent: Signed checkout (checkout_jwt); mandate required. This step crosses a trust boundary.
Step 8: Shopping Agent to Shopping Agent: Select open mandates that fit.
Step 9: Shopping Agent to Shopping Agent: Sign closed mandates with agent_sk.
Step 10: Shopping Agent to Credential Provider: Present open and closed Payment Mandates. This step crosses a trust boundary. If The amount is outside payment.amount_range or the payee is not allowed: Payment Receipt with status Error. The error the specification gives for a closed mandate that cannot be shown to meet the constraints is unresolved_constraint. If The closed mandate is not signed by the key in cnf, or sd_hash does not match: invalid_credential; terminal.
Step 11: Credential Provider to Shopping Agent: Payment token. This step crosses a trust boundary.
Step 12: Shopping Agent to Merchant: Token plus open and closed Checkout Mandates. This step crosses a trust boundary. If A line item cannot be matched, or the merchant is not in checkout.allowed_merchants: Checkout Receipt with error unresolved_constraint; the agent may bring the user back to approve a closed mandate.
Step 13: Merchant to Merchant Payment Processor: Initiate payment with the token and both hashes. This step crosses a trust boundary.
Step 14: Merchant Payment Processor to Shopping Agent: Payment Receipt. This step crosses a trust boundary.
Step 15: Merchant to Shopping Agent: Checkout Receipt. This step crosses a trust boundary.
Step 16: Shopping Agent to Shopping Agent: Store the tuple and narrow the open mandate.
Step 1 of 16: User to Shopping Agent. Set a shopping task.
AP2 failure: unresolved_constraint and fallback to human present
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
A verifier cannot confirm that the agent-signed closed mandate meets the open mandate constraints, or meets an unknown constraint type. It returns unresolved_constraint, and the agent brings the user back to approve a closed mandate. This is the only step-up path in v0.2.
Text alternative
Sequence diagram: AP2 failure: unresolved_constraint and fallback to human present. 4 participants: User, Shopping Agent, Trusted Surface, and Merchant. 7 steps, 5 crossing a trust boundary, 1 failure branch. Based on ap2 v0.2 (2026-04-28). Step 1: Shopping Agent to Merchant: Token plus open and closed Checkout Mandates. This step crosses a trust boundary. Step 2: Merchant to Merchant: Evaluate every constraint. Step 3: Merchant to Shopping Agent: Checkout Receipt: status Error, unresolved_constraint. This step crosses a trust boundary. Step 4: Shopping Agent to Trusted Surface: Fall back: request approval of closed Mandate Content. This step crosses a trust boundary. Step 5: Trusted Surface to User: Show the exact checkout; authenticate. If The user declines: The purchase stops; the open mandate remains bounded by its exp. Step 6: Trusted Surface to Shopping Agent: User-signed closed mandates. This step crosses a trust boundary. Step 7: Shopping Agent to Merchant: Present the user-signed closed Checkout Mandate. This step crosses a trust boundary.
Step 1: Shopping Agent to Merchant: Token plus open and closed Checkout Mandates. This step crosses a trust boundary.
Step 2: Merchant to Merchant: Evaluate every constraint.
Step 3: Merchant to Shopping Agent: Checkout Receipt: status Error, unresolved_constraint. This step crosses a trust boundary.
Step 4: Shopping Agent to Trusted Surface: Fall back: request approval of closed Mandate Content. This step crosses a trust boundary.
Step 5: Trusted Surface to User: Show the exact checkout; authenticate. If The user declines: The purchase stops; the open mandate remains bounded by its exp.
Step 6: Trusted Surface to Shopping Agent: User-signed closed mandates. This step crosses a trust boundary.
Step 7: Shopping Agent to Merchant: Present the user-signed closed Checkout Mandate. This step 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 7Shopping Agent toto Merchant
Token plus open and closed Checkout Mandates
The agent presents a checkout it built autonomously. Here the checkout swaps the tent for a model that is not among acceptable_items, or the open mandate carries a constraint type the merchant does not know.
Step 1 of 7: Shopping Agent to Merchant. Token plus open and closed Checkout Mandates. Crosses a trust boundary.
AP2 failure: invalid_credential on a broken mandate chain
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The Credential Provider rejects a Payment Mandate chain whose closed mandate is not signed by the key in cnf or whose sd_hash does not match. The error is terminal and no token is issued.
Text alternative
Sequence diagram: AP2 failure: invalid_credential on a broken mandate chain. 2 participants: Shopping Agent and Credential Provider. 4 steps, 2 crossing a trust boundary, 1 failure branch. Based on ap2 v0.2 (2026-04-28). Step 1: Shopping Agent to Credential Provider: Present open and closed Payment Mandates. This step crosses a trust boundary. Step 2: Credential Provider to Credential Provider: Verify the chain under Delegate SD-JWT. If The chain verifies but the closed mandate changes a value the open mandate fixed, such as the payee: invalid_mandate: the mandate does not approve this action; terminal. Step 3: Credential Provider to Shopping Agent: Payment Receipt: status Error, invalid_credential. This step crosses a trust boundary. Step 4: Shopping Agent to Shopping Agent: Record the rejection.
Step 1: Shopping Agent to Credential Provider: Present open and closed Payment Mandates. This step crosses a trust boundary.
Step 2: Credential Provider to Credential Provider: Verify the chain under Delegate SD-JWT. If The chain verifies but the closed mandate changes a value the open mandate fixed, such as the payee: invalid_mandate: the mandate does not approve this action; terminal.
Step 3: Credential Provider to Shopping Agent: Payment Receipt: status Error, invalid_credential. This step crosses a trust boundary.
Step 4: Shopping Agent to Shopping Agent: Record the rejection.
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 4Shopping Agent toto Credential Provider
Present open and closed Payment Mandates
A compromised or buggy agent presents a closed mandate signed with a key other than the one in the open mandate's cnf, or edits a disclosure so that sd_hash no longer matches.
Step 1 of 4: Shopping Agent to Credential Provider. Present open and closed Payment Mandates. Crosses a trust boundary.
AP2 failure: mandates_not_supported and fallback to a non-agentic flow
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
A verifier that does not use mandates for an action answers mandates_not_supported. The agent hands the purchase back to the user.
Text alternative
Sequence diagram: AP2 failure: mandates_not_supported and fallback to a non-agentic flow. 3 participants: User, Shopping Agent, and Merchant. 3 steps, 2 crossing a trust boundary. Based on ap2 v0.2 (2026-04-28). Step 1: Shopping Agent to Merchant: Present a Checkout Mandate. This step crosses a trust boundary. Step 2: Merchant to Shopping Agent: Checkout Receipt: status Error, mandates_not_supported. This step crosses a trust boundary. Step 3: Shopping Agent to User: Hand the checkout to the user.
Step 1: Shopping Agent to Merchant: Present a Checkout Mandate. This step crosses a trust boundary.
Step 2: Merchant to Shopping Agent: Checkout Receipt: status Error, mandates_not_supported. This step crosses a trust boundary.
Step 3: Shopping Agent to User: Hand the checkout to the user.
Spec version v0.2 (2026-04-28). Sources: [15], [34]
Step 1 of 3: Shopping Agent to Merchant. Present a Checkout Mandate. Crosses a trust boundary.
AP2 alternative path: verifying mandates and receipts in a dispute
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
After the fact, a dispute verifier collects both mandates and both receipts, recomputes the hash bindings and checks each receipt reference. AP2 defines these checks but leaves retention, retrieval and adjudication to others.
Text alternative
Sequence diagram: AP2 alternative path: verifying mandates and receipts in a dispute. 3 participants: Merchant, Credential Provider, and Dispute verifier. 7 steps, 2 crossing a trust boundary, 1 failure branch. Based on ap2 v0.2 (2026-04-28). Step 1: Merchant to Dispute verifier: Checkout Mandate and Checkout Receipt. This step crosses a trust boundary. Step 2: Credential Provider to Dispute verifier: Payment Mandate and Payment Receipt. This step crosses a trust boundary. Step 3: Dispute verifier to Dispute verifier: Verify the Checkout Mandate under the Merchant rules. If The mandate does not verify: It cannot serve as evidence of what the user approved. Step 4: Dispute verifier to Dispute verifier: Recompute the hash of the included checkout_jwt. Step 5: Dispute verifier to Dispute verifier: Match the Checkout Receipt reference. Step 6: Dispute verifier to Dispute verifier: Verify the Payment Mandate with checkout_hash. Step 7: Dispute verifier to Dispute verifier: Match the Payment Receipt reference.
Step 1: Merchant to Dispute verifier: Checkout Mandate and Checkout Receipt. This step crosses a trust boundary.
Step 2: Credential Provider to Dispute verifier: Payment Mandate and Payment Receipt. This step crosses a trust boundary.
Step 3: Dispute verifier to Dispute verifier: Verify the Checkout Mandate under the Merchant rules. If The mandate does not verify: It cannot serve as evidence of what the user approved.
Step 4: Dispute verifier to Dispute verifier: Recompute the hash of the included checkout_jwt.
Step 5: Dispute verifier to Dispute verifier: Match the Checkout Receipt reference.
Step 6: Dispute verifier to Dispute verifier: Verify the Payment Mandate with checkout_hash.
Step 7: Dispute verifier to Dispute verifier: Match the Payment Receipt reference.
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 7Merchant toto Dispute verifier
Checkout Mandate and Checkout Receipt
Either the Shopping Agent or the Merchant may supply them. Retention and retrieval are out of scope; the specification suggests a future lookup keyed on transaction_id.
Spec version v0.2 (2026-04-28). Sources: [1], [13], [15]
Step 1 of 7: Merchant to Dispute verifier. Checkout Mandate and Checkout Receipt. Crosses a trust boundary.
AP2 alternative path: User Credential delegation with OpenID4VP and the Digital Credentials API
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
How a user credential signs AP2 mandates. The agent puts the Mandate Content in an OpenID4VP transaction_data entry of type delegate; the wallet, acting as Trusted Surface, returns a presentation whose key binding covers delegate_payload.
Text alternative
Sequence diagram: AP2 alternative path: User Credential delegation with OpenID4VP and the Digital Credentials API. 4 participants: Shopping Agent, Browser or OS (Digital Credentials API), Wallet (Trusted Surface), and User. 5 steps, 4 crossing a trust boundary, 1 failure branch. Based on ap2 v0.2 (2026-04-28). Step 1: Shopping Agent to Browser or OS (Digital Credentials API): OpenID4VP request with a delegate entry in transaction_data. This step crosses a trust boundary. Step 2: Browser or OS (Digital Credentials API) to Wallet (Trusted Surface): Route the request to the user's wallet. This step crosses a trust boundary. Step 3: Wallet (Trusted Surface) to User: Show the purchase; authenticate. If No credential matches the DCQL query: No response is returned; the agent cannot obtain a user-signed mandate this way. Step 4: Wallet (Trusted Surface) to Browser or OS (Digital Credentials API): Authorization response: vp_token with key binding over delegate_payload. This step crosses a trust boundary. Step 5: Browser or OS (Digital Credentials API) to Shopping Agent: Return the response to the agent. This step crosses a trust boundary.
Step 1: Shopping Agent to Browser or OS (Digital Credentials API): OpenID4VP request with a delegate entry in transaction_data. This step crosses a trust boundary.
Step 2: Browser or OS (Digital Credentials API) to Wallet (Trusted Surface): Route the request to the user's wallet. This step crosses a trust boundary.
Step 3: Wallet (Trusted Surface) to User: Show the purchase; authenticate. If No credential matches the DCQL query: No response is returned; the agent cannot obtain a user-signed mandate this way.
Step 4: Wallet (Trusted Surface) to Browser or OS (Digital Credentials API): Authorization response: vp_token with key binding over delegate_payload. This step crosses a trust boundary.
Step 5: Browser or OS (Digital Credentials API) to Shopping Agent: Return the response to the agent. This step 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 5Shopping Agent toto Browser or OS (Digital Credentials API)
OpenID4VP request with a delegate entry in transaction_data
Under the User Credential model the agent asks the user's wallet to sign the Mandate Content. The delegate object needs type delegate, format and delegate_payload; delegate_disclosures is optional. The Digital Credentials API is the recommended channel.
Spec version v0.2 (2026-04-28). Sources: [15], [24]
Step 1 of 5: Shopping Agent to Browser or OS (Digital Credentials API). OpenID4VP request with a delegate entry in transaction_data. Crosses a trust boundary.
UCP decides where AP2 artifacts travel; AP2 decides what they contain. The business advertises the extension and its keys in /.well-known/ucp, signs each checkout in ap2.merchant_authorization, and requires ap2.checkout_mandate on complete; the Payment Mandate rides in the payment credential token. Once negotiated, neither side may fall back to an unprotected checkout. This is specified; live use is unverified.
Text alternative
Sequence diagram with Platform, Business, Trusted Surface and Credential Provider. 1, the platform fetches /.well-known/ucp. 2, the business lists the capability dev.ucp.common.payment.ap2_mandate and its keys. 3, the platform creates or updates a checkout. 4, the business returns the checkout with ap2.merchant_authorization, a detached JWS over the JCS-canonical checkout. 5, the platform verifies that signature before showing the checkout. 6, the platform sends Mandate Content to the Trusted Surface. 7, the surface returns signed mandates as SD-JWTs with key binding. 8, the platform sends the Payment Mandate to the Credential Provider. 9, it returns a token carrying the Payment Mandate. 10, the platform completes the checkout with ap2.checkout_mandate and the token in payment.instruments[*].credential.token. 11, the business returns the order or an error such as mandate_required or mandate_scope_mismatch.
The a2a-x402 v0.2 extension can nest x402 objects inside AP2 mandates: the payment requirements inside a CartMandate artifact and the signed payment inside a PaymentMandate message part. Those are AP2 v0.1 objects. AP2 v0.2 has no Cart mandate, and neither specification defines the v0.2 mapping, so the documented embedding is out of step with the current AP2.
Text alternative
Flowchart. An A2A Task from the merchant agent in state input-required carries metadata x402.payment.status payment-required and, in task.artifacts, an AP2 CartMandate (a v0.1 object) holding the x402PaymentRequiredResponse. The client agent answers with a Message whose metadata says payment-submitted and whose message.parts hold an AP2 PaymentMandate (v0.1) with the signed x402 PaymentPayload. The final metadata holds x402.payment.receipts with status payment-completed or payment-failed. A dotted arrow from the CartMandate points to a note that AP2 v0.2 has no CartMandate, only Checkout and Payment Mandates, and no v0.2 equivalent is defined.
Solid lines are documented links: UCP embeds AP2 as an extension, a2a-x402 nests x402 inside AP2 v0.1 mandates, and Verifiable Intent shares AP2's mandate types and now sits with it at FIDO. Dotted lines mark analogies or the absence of any documented link. The AP2 repository does not mention TAP, ACP, Shared Payment Tokens, the Machine Payments Protocol or ERC-8004.
Text alternative
Flowchart. UCP embeds AP2 through the extension dev.ucp.common.payment.ap2_mandate. AP2 links to x402 through the a2a-x402 Embedded Flow, which targets AP2 v0.1. AP2 and Mastercard Verifiable Intent share vct values with different constraint prefixes. The FIDO Alliance governs AP2 specification work and also received Verifiable Intent. AP2 samples run over A2A. ERC-8226, a draft on-chain mandate standard, is an analogue that does not reference AP2 and names ERC-8004 as its identity layer. Visa TAP, OpenAI ACP and Stripe MPP have no documented link to AP2.
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.
AP2 is an open protocol for agent payments. A mandate is a signed record. It shows what a user lets an agent buy. AP2 does not move money. Cards, bank transfers or tokens move the money.
Google started AP2 in 2025. Since 2026-04-28, groups of the FIDO Alliance control the specification.
Version 0.2 has two types of mandate: the Checkout Mandate and the Payment Mandate. Version 0.2 has no Intent Mandate and no Cart Mandate. Each mandate is closed or open. A closed mandate shows one checkout and one exact amount. An open mandate shows limits and the public key of the agent.
AP2 has five roles. The agent buys for the user. The Credential Provider gives a payment token. The Merchant signs the checkout. The Merchant Payment Processor processes the payment.
The Trusted Surface shows the mandate to the user and gets the approval. The Trusted Surface must not use an AI model.
The hash of the signed checkout is in each mandate. Thus, each mandate is for one checkout only. AP2 has no procedure to cancel a mandate before it expires. AP2 version 0.2 has no step-up authentication.
Procedure Approve a purchase for an agent (user)
Open the request on your Trusted Surface, for example your bank app.
Read the merchant, the items and the amount.
If the request has limits, read the maximum amount and the expiry time.
Make sure that the merchants are the merchants that you expect.
Approve the request with your fingerprint or your PIN.
Keep the receipts that the agent shows you.
Procedure Verify a Checkout Mandate (merchant)
Sign each checkout with an ECDSA key, for example ES256.
When the agent sends a Checkout Mandate, verify the signature chain.
Calculate the hash of your latest signed checkout.
Make sure that this hash is equal to the checkout_hash value.
If the agent also sends an open mandate, examine each constraint.
If you do not know a constraint type, reject the mandate.
If a check fails, send a Checkout Receipt with the error code.
If all checks are correct, complete the checkout and send a Checkout Receipt.
Procedure Close an open mandate (agent developer)
Find the open mandates that agree with the checkout.
Make sure that the amount is in the amount range.
Make sure that the merchant and the items are in the allowed lists.
Sign the closed mandates with the agent key from the cnf claim.
Send only the data that the verifier must have.
Send the Payment Mandate to the Credential Provider.
Send the token and the Checkout Mandate to the merchant.
If you get the error unresolved_constraint, ask the user to approve the purchase.
Keep the open mandate, the closed mandate and the receipt together.
Technical nouns and technical verbs
mandate: A signed record that shows what a user lets an agent buy.
closed mandate: A mandate for one checkout and one exact amount.
open mandate: A mandate with limits and the public key of the agent.
constraint: A limit in an open mandate, for example a maximum amount or a list of merchants.
Trusted Surface: The screen where the user reads and approves a mandate. It does not use an AI model.
Credential Provider: The company that gives a payment token after it verifies the Payment Mandate.
checkout_hash: The hash of the checkout that the merchant signed.
receipt: A signed record that shows if the payment or the checkout is complete.
expire (IV): To stop being valid at a set time.
STE check report
Sentences
68
Longest procedural sentence
19 words (limit 20)
Longest descriptive sentence
15 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)
AP2 (the Agent Payments Protocol) answers one question: when an agent pays, how can the merchant, the card issuer and the network tell what the person behind it actually agreed to? Its answer is the mandate, a signed record of user approval. Version 0.2 has two kinds, Checkout Mandates and Payment Mandates, and each comes closed (the exact checkout and amount) or open (constraints such as merchants, items, a price range or a budget). A user signs closed mandates on a non-agentic Trusted Surface, or signs open mandates that name the agent's key, so the agent can later sign closed ones itself. Hashes of the merchant-signed checkout tie every mandate and every receipt to one transaction. What AP2 does not give you: a payment rail, a way to revoke a mandate early, step-up authentication in v0.2, or proof that it runs in production anywhere. Money still moves over cards, bank transfers or stablecoins, and the checkout messages come from a commerce protocol such as the Universal Commerce Protocol (UCP).
AP2, the Agent Payments Protocol, was announced by Google on 2025-09-16, with more than 60 organizations named as collaborators. The problem it targets is evidence. Card and bank systems were built on the assumption that a person pressed the buy button, so when software presses it, nobody downstream can tell whether the purchase matches what the person wanted. AP2 adds a signed artifact that every party can check in code and keep for later disputes.
Simplified Technical English
AP2 is an open protocol for agent payments. A mandate is a signed record. It shows what a user lets an agent buy. AP2 does not move money. Cards, bank transfers or tokens move the money.
Google started AP2 in 2025. Since 2026-04-28, groups of the FIDO Alliance control the specification.
Version 0.2 has two types of mandate: the Checkout Mandate and the Payment Mandate. Version 0.2 has no Intent Mandate and no Cart Mandate. Each mandate is closed or open. A closed mandate shows one checkout and one exact amount. An open mandate shows limits and the public key of the agent.
E. Main personas
Delegating consumer
Approves mandates on a Trusted Surface: exact purchases when present, limits for the agent when not. Source [13, 32, 35]
Goals
Let an agent buy within limits I set
See exactly what I approve
Have evidence if a purchase goes wrong
Pains
No way to cancel an open mandate before it expires
Limits written in constraint terms are hard to read
Unclear who pays if the agent misreads me
Implements
Nothing technical: approves on a wallet, issuer app, browser or agent app that acts as Trusted Surface
Must trust
The Trusted Surface to show the real checkout
The agent to stay inside its constraints
The network rules for disputes
Questions, first steps, metrics and a day in the life
Questions they ask
What exactly did I approve, and for how long?
Can the agent spend twice from one approval?
What happens when the agent finds something outside my limits?
First three steps
Read the merchant, items, amount range and expiry before approving an open mandate
Prefer short expiry times for autonomous tasks
Keep the receipts the agent stores
Metrics they care about
Time from task to approved purchase
Number of fallbacks to manual approval
Disputes resolved with mandate evidence
A day in the life
Priya asks her assistant to buy a two-person tent before Friday, under 300 dollars, from one of two outdoor stores. Her banking app opens and shows the limits in plain words, the stores, the price ceiling and an expiry on Friday night. She confirms with her fingerprint and goes to work. On Wednesday the agent finds the green tent for 249 dollars and buys it without asking. On Thursday it tries a matching groundsheet, but the store answers that the item is outside the approved line items, so her phone asks her to approve that one directly. She declines. Both receipts sit in the app.
Credential Provider: verifies Payment Mandates and issues a token scoped to the purchase; often also hosts the Trusted Surface. Source [13, 15, 17, 36]
Goals
Release credentials only for approved purchases
Offer agent payments without new fraud exposure
Reuse existing tokenization
Pains
Stateful constraints (budget, recurrence) need presentation history
No revocation primitive for open mandates
Specification moved to FIDO with no public draft
Implements
Delegate SD-JWT chain verification
Constraint evaluation for payment.* types
Payment Receipt handling and error codes
OpenID4VP delegation with type delegate when acting as wallet
Must trust
The user credential issuer or the trusted agent provider list
The network to honor scoped credentials
Its own deterministic code, never an LLM
Questions, first steps, metrics and a day in the life
Questions they ask
How do I track payment.budget across presentations?
Which delegation model do my verifiers accept?
How do I invalidate tokens from overlapping mandates?
First three steps
Read agent_authorization.md and payment_mandate.md at v0.2.0
Run the Python SDK chain verification against the schema examples
Map each failure to invalid_credential, invalid_mandate or unresolved_constraint
Metrics they care about
Share of presentations rejected by error code
Token issuance latency after mandate verification
Fraud rate on mandate-backed tokens
A day in the life
Marco runs the agent payments team at a digital wallet. Each morning he reviews rejected presentations by error code. Most invalid_credential cases come from one agent provider whose closed mandates are signed with a rotated key that no longer matches cnf. The unresolved_constraint cases are mostly budget checks: his service is the one that has to remember earlier presentations, and the specification never said whose job that was. He files a note for the FIDO payments group about revocation, then adds a rule that invalidates outstanding tokens when the agent presents an overlapping mandate. The release goes out with ES256 keys only.
Card issuer or bank: may receive the Payment Mandate through the network or act as Credential Provider, and uses mandates as dispute evidence. Source [1, 13, 58]
Goals
Know an agent purchase was user-approved
Fewer first-party disputes
Clear liability
Pains
Liability stays with network rules that are not yet agent specific
No step-up mechanism in v0.2
Production evidence missing
Implements
Mandate verification where it acts as Credential Provider or behind the network
Dispute verification of mandates and receipts
Risk decisions using risk_data
Must trust
The network to pass mandates intact
The Trusted Surface to have authenticated the user
Receipts to be signed by the right parties
Questions, first steps, metrics and a day in the life
Questions they ask
Does a mandate change chargeback rights?
How do I challenge the user if v0.2 has no step-up?
Who retains mandates for disputes?
First three steps
Read the Dispute Evidence and Verification: Dispute sections
Check how your network plans to carry mandates
Decide how unresolved_constraint fallbacks reach your authentication flow
Metrics they care about
Disputes with mandate evidence attached
Approval rate on mandate-backed transactions
Fallback rate to manual approval
A day in the life
Helen handles disputes at a regional bank. A customer says her agent bought the wrong concert tickets. The merchant supplies the Checkout Mandate and receipt, and the network passes the Payment Mandate. Helen's tool recomputes the hash of the checkout JWT, matches both receipt references and confirms that the agent's closed mandate sits inside the customer's open one, with the venue and price allowed. The evidence shows the agent stayed inside its limits, so the dispute turns on whether those limits matched what the customer meant. AP2 cannot answer that, and the network rules say nothing specific about agents yet. She escalates it.
Merchant: signs every checkout, verifies Checkout Mandates and open-mandate constraints, and returns Checkout Receipts. Source [3, 13, 14, 33]
Goals
Accept agent orders with proof of user approval
Keep their own checkout and payment stack
Clear errors when agents misbehave
Pains
Signature rule conflict for the Checkout JWT (issue 268)
Line-item matching needs a max-flow style check
No proof of production use to justify the work
Implements
checkout_jwt signing with ECDSA
Checkout Mandate and constraint verification
Checkout Receipt JWT with status and errors
The UCP extension when selling through UCP
Must trust
Its processor to verify the Payment Mandate
The agent to forward the exact checkout_jwt
Its signing key custody
Questions, first steps, metrics and a day in the life
Questions they ask
Should I sign checkouts with ES256 or Ed25519?
How strictly do I match line items?
Which UCP errors do I return?
First three steps
Sign checkouts with ES256 and include enough entropy
Implement checkout_hash comparison against the latest checkout_jwt
Add UCP dev.ucp.common.payment.ap2_mandate to /.well-known/ucp if you sell through UCP
Metrics they care about
Share of agent orders with valid mandates
Constraint rejections per day
Chargebacks on agent orders
A day in the life
Tomas leads checkout engineering at an outdoor retailer that sells through UCP. His team signs every checkout with ES256 because the specification forbids deterministic signatures, even though their bot-auth setup already uses Ed25519, so they now manage two key types. Today an agent presents a closed Checkout Mandate for a tent, but the cart has a different color than the open mandate allows. His service evaluates checkout.line_items, finds no match and returns a Checkout Receipt with unresolved_constraint. Ten minutes later the same order comes back with a user-signed closed mandate and goes through. He logs the round trip for the weekly report.
Shopping Agent developer: builds Mandate Content, gets it signed, presents mandates, and handles receipts and fallbacks. Source [13, 15, 36, 59]
Goals
Complete purchases without asking the user each time
Pass every verifier on the first try
Keep the LLM away from keys
Pains
Selecting the right open mandate is left to the agent
Overlapping presentations are forbidden until a rejection arrives
The SDK is not on PyPI
Implements
Mandate Content assembly
Key-binding JWTs signed with the key in cnf
Selective disclosure choices
Receipt storage and scope reduction
Must trust
The Trusted Surface to sign what it showed
Its own deterministic signer to stay out of the model's reach
Verifiers to return signed receipts
Questions, first steps, metrics and a day in the life
Questions they ask
Which disclosures does this verifier need?
How do I reduce an open mandate after success?
What do I do on unresolved_constraint?
First three steps
Clone the AP2 repository and run the human-not-present Python sample
Read the SDK README for MandateClient create, present and verify
Put signing behind a deterministic service with no LLM access
Metrics they care about
Purchases completed without fallback
Error receipts by code
Average disclosures per presentation
A day in the life
Aiko builds a grocery agent. Her signer is a small service the model cannot call directly: the model proposes a basket, deterministic code checks it against the open mandates and only then signs a closed mandate with the key in cnf. Today a store returned unresolved_constraint because a substitute brand was not in acceptable_items. Her code stored the error receipt, asked the user's phone for approval of the exact basket, and finished. She is also adding scope reduction: after each success the agent records the open, closed and receipt tuple, so the weekly budget is never presented twice.
Compliance or risk officer: judges whether mandates support consent, liability and data-protection duties. Source [1, 23, 36, 60]
Goals
Evidence of consent that holds up
Data minimization
Know who is accountable
Pains
AP2 makes no regulatory claims
Liability left to network rules
Governance in transition to FIDO
Implements
Retention policy for mandates and receipts
Review of Trusted Surface consent screens
Mapping to SCA, Regulation E and Z, and GDPR
Must trust
The Trusted Surface consent capture
Signed receipts from merchant and processor
Network dispute rules
Questions, first steps, metrics and a day in the life
Questions they ask
Does an open mandate count as consent to a specific transaction under PSD2?
Who keeps mandates and for how long?
Does risk_data contain personal data?
First three steps
Read Dispute Evidence and Security and Privacy Considerations
Map open mandates to your SCA and authorization rules
Set a retention rule for mandates and receipts
Metrics they care about
Disputes resolved with mandate evidence
Data fields disclosed per presentation
Open policy questions closed
A day in the life
Sophie reviews a plan to accept agent purchases at a European retailer. The mandates help: a signed record of what the customer saw and approved, with only the needed fields disclosed. But AP2 itself claims no compliance. Its glossary defines Strong Customer Authentication and dynamic linking without saying a mandate satisfies them, and whether a standing open mandate counts as consent to a specific transaction under PSD2 is untested. She asks the team to keep mandates and receipts for the dispute window, to treat risk_data as personal data, and to follow the FIDO working group because the specification no longer evolves on GitHub.
Builds Tamarin models of x402, MPP, ACP and AP2 from their specifications, schemas and reference code using one shared abstraction of the agent payment lifecycle, then asks source-backed verification questions to expose missing bindings and cross-stage correspondences, which it consolidates into 18 security principles. Across 86 verification cases it reproduces 46 known or calibration cases, reports 40 new formal-consistency findings, and validates ten of them against x402 implementations with proofs of concept.
Why it matters here: The only side-by-side formal model of x402, stripe-mpp, openai-acp and ap2 so far; it shows where each specification leaves delegated authority, settlement and fulfillment unbound. AP2: Tamarin models that include AP2. ERC-8004: Trustless Agents: Formal models of agent payment protocols around ERC-8004. Agentic Commerce Protocol (ACP): Models ACP in Tamarin with x402, MPP and AP2; the only formal analysis that names it. Stripe MPP (Machine Payments Protocol): Models MPP in Tamarin alongside x402, ACP and AP2; the only formal analysis that names MPP. UCP: Formal analysis of agent payment protocols; the abstract does not name UCP but analyzes AP2, which UCP embeds as an extension. x402: Formal Tamarin models of x402 alongside MPP, ACP and AP2.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{jiang2026formal,
title = {{A Formal Analysis of Agent Payment Protocols}},
author = {Ke Jiang and Mohan Yu and Yuan Chang and Mohit Kumar Jangid and Jianyu Niu and Cong Wang and Yinqian Zhang},
year = {2026},
eprint = {2609.00060},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.00060}
}
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}
}
Systematic security analysis of AP2 v0.2 across five lifecycle phases and five deployment architectures, using MAESTRO threat modeling to catalog 48 threats in five families and AIVSS scoring to flag eight High-band threats, each demonstrated on a purpose-built testbed with proofs of concept and mitigations, plus a deployment-aware scanner. The central finding is that valid mandate signatures do not guarantee that a transaction reflects user intent when the pre-authorization context is manipulated.
Why it matters here: Most complete threat catalog for ap2 to date, and it covers the A2A and MCP inputs that sit outside the signed mandates. AP2: The main security analysis of AP2 v0.2; source of the 48-threat count in section H.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{aviv2026mandate,
title = {{Beyond the Mandate: A Systematic Security Analysis of the Agent Payments Protocol (AP2)}},
author = {Avital Aviv and Parth A. Gandh and Ron Bitton and Asaf Shabtai},
year = {2026},
eprint = {2608.23858},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2608.23858}
}
A vision paper arguing that once buyers are agents paying over agent-native rails such as x402 and AP2, the scarce resource becomes trustworthy product information rather than product matching. It sketches a market in which buyer agents pay fractions of a cent to unlock seller- and reviewer-supplied evidence, with reviewer trust scored reputationally, and lists the NLP problems this creates.
Why it matters here: Names x402 and AP2 directly as the rails that make per-fact micropayments feasible, and ties paid information to the reputation scoring that ERC-8004 registries aim to provide. Stripe MPP (Machine Payments Protocol): Micro-transaction markets for product information, a use case for per-request MPP charges.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{ventirozos2026paying,
title = {Paying to Know: Micro-Transaction Markets for Verified Product Information in Agentic E-Commerce},
author = {Filippos Ventirozos and Matthew Shardlow},
year = {2026},
eprint = {2606.24783},
archivePrefix = {arXiv},
primaryClass = {cs.CL},
url = {https://arxiv.org/abs/2606.24783},
note = {arXiv preprint}
}
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}
}
Shows that AP2 signs completed transactions but not the decisions leading to them, so ordinary product-description text can steer a shopping agent into fetching another user's payment credentials, assembling a valid cart that differs from what the user saw, or upgrading to a more expensive item, with success rates of 90%, 56% and 73.3% on the Gemini Flash-Lite models that AP2 sample agents use. Proposes A-VIP, a protocol-layer defense that binds credential lookups and cart lines to the session and listing, and releases AP2-WhisperBench with 1,544 scenarios.
Why it matters here: Direct follow-up to the whisper attacks on ap2 with a protocol-layer defense and a benchmark; it sharpens the point that mandate signatures do not cover intent formation. AP2: Shows mandates sign the transaction but not the decision; proposes a binding defense.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{louck2026whisper,
title = {{Signing the Transaction but Not the Decision: Whisper Attacks and a Binding Defense for AP2}},
author = {Yedidel Louck and Amit Dvir and Ariel Stulman},
year = {2026},
eprint = {2609.11757},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.11757}
}
A systematization of knowledge that frames the security of autonomous LLM agents in commerce along five dimensions (agent integrity, transaction authorization, inter-agent trust, market manipulation, regulatory compliance), derives 12 cross-layer attack vectors from a curated corpus of papers, protocol documents, industry reports and incidents, and proposes a layered defense for the authorization gaps in current agent payment protocols. The ACP it lists is written 'Agent Commerce Protocol', which may not be OpenAI's Agentic Commerce Protocol; that mapping is unconfirmed.
Why it matters here: Places erc-8004, ap2, x402 and stripe-mpp in one threat framework and argues that their authorization gaps compound across the reasoning, tooling, custody and settlement layers. AP2: Places AP2 among agent commerce attack vectors. Stripe MPP (Machine Payments Protocol): Includes MPP in its protocol set for agent commerce security. x402: Security SoK of agentic commerce that covers x402.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{mao2026sok,
title = {{SoK: Security of Autonomous LLM Agents in Agentic Commerce}},
author = {Qian'ang Mao and Jiaxin Wang and Ya Liu and Li Zhu and Cong Ma and Jiaqi Yan},
year = {2026},
eprint = {2604.15367},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2604.15367}
}
Red-teams a working AP2 shopping agent built with Gemini 2.5 Flash and the Google ADK and introduces two prompt-injection techniques, the Branded Whisper Attack, which manipulates product ranking, and the Vault Whisper Attack, which extracts sensitive user data, showing that simple adversarial prompts reliably subvert agent behavior. The IEEE version carries the title given here; the arXiv preprint (2601.22569) is titled 'Whispers of Wealth: Red-Teaming Google's Agent Payments Protocol via Prompt Injection'.
Why it matters here: First published attack paper on ap2 and the origin of the whisper-attack line that Louck and colleagues extend in 2026. AP2: Prompt injection against an AP2 shopping agent.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{debi2026whispers,
title = {{Whispers of Wealth: A Systematic Red-Teaming Study of the Agent Payments Protocol (AP2)}},
author = {Tanusree Debi and Wentian Zhu and Pranjol Sen Gupta},
year = {2026},
booktitle = {2026 International Conference on Intelligent Multimedia, Networking, and Security (IMNS)},
publisher = {IEEE},
pages = {1-6},
doi = {10.1109/IMNS67862.2026.11655291},
eprint = {2601.22569},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2601.22569}
}
Analyzes the AP2 mandate lifecycle and finds runtime enforcement gaps created by retries, concurrency and orchestration, then proposes a zero-trust runtime verifier that enforces explicit context binding and consume-once mandate semantics with time-bound nonces. Simulations at up to 10,000 transactions per second show both mechanisms are needed to stop replay and context-redirect attacks, at about 3.8 ms verification latency.
Why it matters here: Shows that ap2 (and ucp, which it also names as a mandate-based protocol) needs execution-time checks on mandates, not just signature validity at issuance. AP2: Replay and context-binding gaps in the mandate lifecycle. UCP: Names UCP and AP2 in its abstract; replay and context-binding failures in mandate-based protocols.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{lan2026zerotrust,
title = {{Zero-Trust Runtime Verification for Agentic Payment Protocols: Mitigating Replay and Context-Binding Failures in AP2}},
author = {Qianlong Lan and Anuj Kaul and Shaun Jones and Stephanie Westrum},
year = {2026},
eprint = {2602.06345},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2602.06345}
}
Compares six trust mechanisms for inter-agent protocols (brief, claim, proof, stake, reputation, constraint) and evaluates A2A, AP2 and ERC-8004 against them on security, privacy, cost and resistance to Sybil, collusion and whitewashing, with attention to LLM-specific weaknesses such as prompt injection and sycophancy. It argues that proof and stake should gate high-impact actions, with claims for discovery and reputation as an overlay. The arXiv record says it was submitted to the AAAI 2026 TrustAgent workshop; acceptance is not confirmed.
Why it matters here: Direct comparative treatment of ap2 and erc-8004 trust assumptions; its warning that claim-only and reputation-only designs are brittle anticipates the empirical ERC-8004 Sybil findings. ERC-8004: Trustless Agents: Places ERC-8004 reputation among other inter-agent trust models.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{hu2025trust,
title = {{Inter-Agent Trust Models: A Comparative Study of Brief, Claim, Proof, Stake, Reputation and Constraint in Agentic Web Protocol Design-A2A, AP2, ERC-8004, and Beyond}},
author = {Botao 'Amber' Hu and Helena Rong},
year = {2025},
eprint = {2511.03434},
archivePrefix = {arXiv},
primaryClass = {cs.HC},
url = {https://arxiv.org/abs/2511.03434}
}
Designs deployer-side attestations so that, after an incident in a multi-agent workflow, a verifier can tell which deployer released given output bytes and whether each cross-deployer delegation was authorized. It compares a signed linked list, a Merkle chain and a co-signed DAG, and only the co-signed DAG rejects a forged parent link after a child key is compromised.
Why it matters here: Gives the evidence model that ERC-8004 validation records and AP2 mandate chains need when work and authority pass through several agents operated by different parties.
Metadata verified 2026-10-11 through arxiv.
Show BibTeX
@misc{liu2026ancestry,
title = {{Attesting Outputs and Delegation Ancestry in Multi-Agent AI Systems}},
author = {Lifei Liu and Haoran Yu},
year = {2026},
eprint = {2608.30387},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2608.30387}
}
Argues that AP2 and ACP lack interoperable, tamper-evident audit trails and proposes a global event timeline built from canonical event schemas, deterministic batching, Merkle commitments and blockchain anchoring, plus signed fraud markers tied to that evidence. A single-author prototype reports throughput figures; a copy is also on Zenodo (DOI 10.5281/zenodo.19060285).
Why it matters here: Names a gap shared by AP2 and ACP, the lack of a common verifiable event log for disputes and fraud signals, and sketches one way to fill it. Agentic Commerce Protocol (ACP): Argues ACP lacks interoperable, tamper-evident audit trails.
Metadata verified 2026-10-11 through arxiv.
Show BibTeX
@misc{srivastava2026timeline,
title = {{Building Trust in Autonomous Commerce: A Verifiable Global Event Timeline and AI-Ready Fraud Intelligence Layer}},
author = {Rajat Srivastava},
year = {2026},
eprint = {2607.19436},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2607.19436}
}
Introduces TessPay, a two-plane verify-then-pay infrastructure for agentic commerce: agents are anchored in a canonical registry and user intent is captured as verifiable mandates, funds are escrowed during execution while the agent produces cryptographic evidence (TLS Notary, TEE) for a Proof of Task Execution, settlement releases funds only when the evidence satisfies verification predicates, and a tamper-evident audit trail supports disputes.
Why it matters here: Combines the mandate idea of ap2 with the registry and validation functions of erc-8004 into one escrow design; a useful comparison for how the protocols split those functions.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{goenka2026tesspay,
title = {{TessPay: Verify-then-Pay Infrastructure for Trusted Agentic Commerce}},
author = {Mehul Goenka and Tejas Pathak and Siddharth Asthana},
year = {2026},
eprint = {2602.00213},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2602.00213}
}
Surveys agent communication protocols with a two-dimensional classification (context-oriented versus inter-agent, general-purpose versus domain-specific), compares them on security, scalability and latency, and lays out directions such as layered architectures, privacy preservation and group interaction.
Why it matters here: Provides the taxonomy into which payment and commerce protocols (x402, AP2, ACP, UCP) slot as domain-specific layers above MCP and A2A. UCP: Survey of AI agent protocols for orientation.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{yang2025protocols,
title = {A Survey of AI Agent Protocols},
author = {Yingxuan Yang and Huacan Chai and Yuanyi Song and Siyuan Qi and Muning Wen and Ning Li and Junwei Liao and Haoyi Hu and Jianghao Lin and Gaowei Chang and Weiwen Liu and Ying Wen and Yong Yu and Weinan Zhang},
year = {2025},
eprint = {2504.16736},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2504.16736},
note = {arXiv preprint}
}
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}
}
Proposes a blockchain-based framework for AI-initiated payments that uses DIDs and verifiable credentials for agent identity, on-chain intent proofs recording user authorization, zero-knowledge proofs for private policy compliance and TEE attestations of agent execution, with a hybrid on-chain and off-chain audit trail; the evaluation is qualitative.
Why it matters here: An early sketch of the intent-binding and identity-attestation ideas that ap2 mandates and erc-8004 validation later formalize.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{acharya2025securepayments,
title = {{Secure Autonomous Agent Payments: Verifying Authenticity and Intent in a Trustless Environment}},
author = {Vivek Acharya},
year = {2025},
eprint = {2511.15712},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2511.15712}
}
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}
}
A design-science study proposing a protocol-agnostic merchant-side architecture for agentic commerce built around a canonical decision envelope, protected dependency and result hashes, Ed25519 or HMAC authentication, live-request rebinding, a generated-claim gate and eleven semantic invariants, evaluated on an open-source JavaScript implementation with eight scenarios and five ablations; the author lists production security and interoperability as not established.
Why it matters here: Addresses what a merchant must keep authoritative when openai-acp, ucp or ap2 checkout messages arrive from agents, complementary to those protocol specifications. Agentic Commerce Protocol (ACP): Merchant-side reference architecture for agent commerce of the kind ACP serves.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{sfiris2026decisioncentered,
title = {{A Decision-Centered Reference Architecture for Trustworthy Agentic Commerce}},
author = {Dimitrios S. Sfiris},
year = {2026},
eprint = {2607.18347},
archivePrefix = {arXiv},
primaryClass = {cs.SE},
url = {https://arxiv.org/abs/2607.18347}
}
Extracts a verified finite-state machine (37 states and 76 transitions from 929 formalized statements) from the A2A specification with LLM assistance and reasons over it to find 11 protocol-level vulnerabilities exploitable by specification-compliant adversaries, including cross-client context injection, credential harvesting through identity loss in multi-hop delegation chains, and exfiltration through unattested capability claims.
Why it matters here: ap2 and the a2a-x402 extension are layered on A2A, so specification-level flaws in A2A delegation and identity flow directly into their trust assumptions.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{lotfi2026a2abreak,
title = {{A2ABreak: Systematic Security Analysis of the A2A Protocol}},
author = {Alireza Lotfi and Mirza Masfiqur Rahman and Imtiaz Karim and Elisa Bertino},
year = {2026},
eprint = {2609.10871},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.10871}
}
Introduces Invocation-Bound Capability Tokens, an append-only token chain that fuses identity, attenuated authorization and provenance binding, in a compact JWT mode and a chained Biscuit mode with Datalog policies for multi-hop delegation across MCP, A2A and HTTP. Python and Rust implementations add sub-millisecond overhead, and all 600 adversarial attempts were rejected.
Why it matters here: Delegation tokens for the A2A and MCP layers that ap2 and the a2a-x402 extension sit on, and a descendant of the Macaroons caveat model. AP2: Verifiable delegation across MCP and A2A.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{prakash2026aip,
title = {{AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A}},
author = {Sunil Prakash},
year = {2026},
eprint = {2603.24775},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2603.24775}
}
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}
}
Develops Authority-Inference Separation, an architecture in which an agent's proposed financial action gains temporary executable authority only after a deterministic control plane validates registered identity, accountable ownership, mandate lineage, policy version and exact economic semantics, with blockchain enforcing granted authority and recording evidence. A 48-fixture prototype rejected all 36 synthetic authorization attacks, and a test of 1,700 Base transactions tied to public x402 facilitator addresses shows that public ledgers evidence settlement but not mandate, accountability or delivery.
Why it matters here: Uses live x402 facilitator traffic to show what on-chain data cannot prove, and frames mandate lineage in terms that map onto ap2 mandates and erc-8004 identity.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{gong2026ais,
title = {{Authority-Inference Separation in Agentic Finance: First-Line Control, Blockchain Enforcement, and Replayable Assurance}},
author = {Hui Gong and Michail Samawi and Francesca Medda},
year = {2026},
eprint = {2608.30519},
archivePrefix = {arXiv},
primaryClass = {q-fin.GN},
url = {https://arxiv.org/abs/2608.30519}
}
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}
}
Characterizes the pre-action authorization problem, enforcing policy on a tool call before it executes, and presents the Open Agent Passport, an open specification and implementation that intercepts tool calls, evaluates a declarative policy and emits signed audit records at a median of 53 ms. In a live adversarial testbed with 4,437 decisions, social engineering succeeded 74.6% of the time under a permissive policy and 0% across 879 attempts under a restrictive one.
Why it matters here: The authorization layer that the APort Vault benchmark later uses for payment authorization; it sits in front of x402 and ap2 spending actions.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{uchibeke2026oap,
title = {{Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents}},
author = {Uchi Uchibeke},
year = {2026},
eprint = {2603.20953},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2603.20953}
}
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}
}
Hypothesizes that agent authorization can be expressed as a cryptographically verifiable relation binding an agent principal, a concrete request, an execution context and policy satisfaction while keeping private attributes confidential, defines candidate properties (authorization soundness, principal, request and policy binding, replay resistance), and provides a Groth16 zk-SNARK proof of concept. Full author names are taken from the Frontiers DOI record; arXiv lists initials.
Why it matters here: Peer-reviewed formalization of the identity, request and execution binding that ap2 mandates approximate and that erc-8004 validation could attest.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@article{llambmorillas2026cva,
title = {{Cryptographically verifiable authorization for autonomous AI agents: a falsifiable hypothesis and proof of concept}},
author = {Mar Llambí-Morillas and Daniel Fernández-Fernández},
year = {2026},
journal = {Frontiers in Computer Science},
volume = {8},
pages = {1966725},
doi = {10.3389/fcomp.2026.1966725},
eprint = {2607.21325},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2607.21325}
}
CaMeL wraps the LLM in a protective system layer that extracts control and data flow from the trusted user query, so retrieved data can never alter program flow, and attaches capabilities to values so tool calls are checked against security policies. It solved 77 percent of AgentDojo tasks with provable security versus 84 percent for an undefended agent.
Why it matters here: The capability model is a natural enforcement point for payment policy: an AP2 cart mandate or an x402 spend limit can be expressed as a CaMeL policy on the payment tool's arguments.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{debenedetti2026camel,
title = {Defeating Prompt Injections by Design},
author = {Edoardo Debenedetti and Ilia Shumailov and Tianqi Fan and Jamie Hayes and Nicholas Carlini and Daniel Fabian and Christoph Kern and Chongyang Shi and Andreas Terzis and Florian Tramèr},
year = {2026},
booktitle = {2026 IEEE Conference on Secure and Trustworthy Machine Learning (SaTML)},
publisher = {IEEE},
pages = {587-618},
doi = {10.1109/SaTML68715.2026.00040},
eprint = {2503.18813},
archivePrefix = {arXiv},
url = {https://arxiv.org/abs/2503.18813}
}
Studies when a principal can safely delegate approval of a long-running agent's actions to a panel of possibly misaligned reviewer agents, and characterizes k-robust coalitional alignment as the necessary and sufficient condition for a threshold approval rule to guarantee the principal does at least as well as a baseline policy, extending the result to sequential control in discounted MDPs and to strategic voting.
Why it matters here: Theory for the human-approval bottleneck that ap2 mandates and openai-acp checkout confirmations encode; it asks when approval itself can be delegated. AP2: Theory of approving actions of possibly misaligned agents.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{collina2026delegating,
title = {{Delegating Authorization to Misaligned Agents: Coalitional Alignment and Safe Control}},
author = {Natalie Collina and Surbhi Goel and Aaron Roth and Sikata Bela Sengupta},
year = {2026},
eprint = {2609.15803},
archivePrefix = {arXiv},
primaryClass = {cs.GT},
url = {https://arxiv.org/abs/2609.15803}
}
KITA keeps the user's signing key and every threshold key share outside all LLM processes; an action is authorized only when t reviewer-signer domains contribute shares bound to the canonical action after authenticated approval, so a prompt-injected proposer cannot forge an authorization. The path is implemented with a structured-output LLM adapter and threshold BLS signatures.
Why it matters here: Addresses the gap formal analyses of x402 and AP2 point to: the agent that reads untrusted content should not hold the credential that signs the payment.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{zheng2026kita,
title = {From Review to Authorization: Key-Isolated Threshold Signing for LLM Agents},
author = {Yu Zheng and Qizhi Zhang},
year = {2026},
eprint = {2609.05901},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.05901},
note = {arXiv preprint}
}
Proposes a governance proxy that enforces signed, machine-readable mandates on MCP tool calls, blocking non-conforming calls and recording every decision in a hash-chained, timestamp-anchored audit trail. The mandate is modeled on the civil-law delegation of authority and mapped to EU AI Act, GDPR, NIS2 and eIDAS 2 obligations; the paper describes implementation status and an evaluation plan rather than results.
Why it matters here: A mandate concept parallel to AP2's intent and cart mandates, applied at the tool-call layer and tied to EU legal instruments, which is useful for the compliance view of delegation. AP2: Signed mandates enforced on tool calls, mapped to EU law.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{racioppi2026mandato,
title = {Mandato: Protocol-Level Enforcement of Digitally Signed Mandates on AI Agent Actions with Cryptographically Chained Audit Trails},
author = {Giovanni Racioppi},
year = {2026},
eprint = {2608.14074},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2608.14074},
note = {arXiv preprint}
}
Proposes receiver-attested receipts for agent actions: the service receiving an agent's call signs a receipt of what it observed, encrypts it to the agent's owner (bound to the authorization token through JWS) and publishes it to a witness-cosigned transparency log, so the owner can reconstruct a tamper-evident trail without trusting the agent or its operator. Instantiated as Sello, with microbenchmarks and a discussion of suppression and collusion attacks.
Why it matters here: An audit primitive for delegated agent actions that would complement the merchant-side evidence in ap2 and openai-acp flows.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{figuera2026notarized,
title = {{Notarized Agents: Receiver-Attested Confidential Receipts for AI Agent Actions}},
author = {Juan Figuera},
year = {2026},
eprint = {2606.04193},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2606.04193}
}
Argues that the most consequential risks in agentic commerce platforms sit in the protocol between agents and commerce services rather than in the model, documenting 33 structural vulnerabilities across three platforms that succeed deterministically regardless of model, three of which chain into a payment hijack. Contributes a taxonomy, AIP-Bench as a deterministic benchmark, and PCAT, a platform-agnostic defense that removes four of five structural attack classes.
Why it matters here: Cross-platform evidence that protocol design, not model alignment, decides the security of openai-acp, ap2 and ucp style checkout flows; the three platforms are not named in the abstract, so the mapping is unconfirmed. Agentic Commerce Protocol (ACP): Protocol-level attacks on agentic commerce platforms; does not name ACP but covers the same layer. UCP: Cross-platform attack taxonomy for agentic commerce platforms; context for section H.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{louck2026protocollevel,
title = {{Protocol-Level Attacks on Agentic Commerce Platforms: A Cross-Platform Taxonomy, AIP-Bench, and Unified Defense}},
author = {Yedidel Louck},
year = {2026},
eprint = {2607.21824},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2607.21824}
}
Identifies a post-fulfillment activation gap: payment, budget, OAuth, mandate and fulfillment checks validate a transaction but do not decide whether a resource an agent acquires (compute, credentials, accounts, other agents) may become usable authority. Proposes a provenance-bounded runtime authorization architecture that quarantines acquired outputs and activates them only through checked activation transactions, with eight proved safety properties and trace-based evaluation.
Why it matters here: Extends the ap2 and x402 question from whether a payment was authorized to what the agent may do with what it bought, a gap none of the eight protocols addresses.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{zhu2026runtimeauth,
title = {{Runtime Authorization for Resources Acquired by AI Agents}},
author = {Genliang Zhu and Chu Wang},
year = {2026},
eprint = {2609.14744},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2609.14744}
}
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}
}
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}
}
Proposes a set of principled design patterns that restrict how untrusted inputs can influence an agent's actions, analyzes their utility and security trade-offs, and illustrates them with case studies of real applications.
Why it matters here: A practical checklist for anyone building a buying agent on ACP, AP2 or x402: the patterns constrain which parts of agent state untrusted merchant content may ever touch.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{beurerkellner2025patterns,
title = {Design Patterns for Securing LLM Agents against Prompt Injections},
author = {Luca Beurer-Kellner and Beat Buesser and Ana-Maria Creţu and Edoardo Debenedetti and Daniel Dobos and Daniel Fabian and Marc Fischer and David Froelicher and Kathrin Grosse and Daniel Naeff and Ezinwanne Ozoani and Andrew Paverd and Florian Tramèr and Václav Volhejn},
year = {2025},
eprint = {2506.08837},
archivePrefix = {arXiv},
primaryClass = {cs.LG},
url = {https://arxiv.org/abs/2506.08837},
note = {arXiv preprint}
}
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}
}
An extensible environment for agents that run tools over untrusted data, with 97 realistic tasks (email, e-banking, travel booking), 629 security test cases and pluggable attacks and defenses. Frontier models fail many tasks even without attacks, and existing injections break some but not all security properties.
Why it matters here: Its e-banking and booking suites are the closest public testbed to agent payments, and the defenses cited here (CaMeL, multi-CaMeL) report their numbers on it.
Metadata verified 2026-10-10 through publisher.
Show BibTeX
@inproceedings{debenedetti2024agentdojo,
title = {AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents},
author = {Edoardo Debenedetti and Jie Zhang and Mislav Balunović and Luca Beurer-Kellner and Marc Fischer and Florian Tramèr},
year = {2024},
booktitle = {Advances in Neural Information Processing Systems 37 (NeurIPS 2024), Datasets and Benchmarks Track},
url = {https://proceedings.neurips.cc/paper_files/paper/2024/hash/97091a5177d8dc64b1da8bf3e1f6fb54-Abstract-Datasets_and_Benchmarks_Track.html},
eprint = {2406.13352},
archivePrefix = {arXiv}
}
A benchmark of 1,054 test cases over 17 user tools and 62 attacker tools that measures whether tool-integrated agents follow injected instructions aimed at direct harm or data exfiltration. Across 30 agents the vulnerability was substantial, with ReAct-prompted GPT-4 following injections in roughly one case in four.
Why it matters here: Supplies the attacker-tool framing (a malicious tool result that triggers a transfer) that payment-agent threat models for AP2 and x402 reuse.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{zhan2024injecagent,
title = {InjecAgent: Benchmarking Indirect Prompt Injections in Tool-Integrated Large Language Model Agents},
author = {Qiusi Zhan and Zhixiang Liang and Zifan Ying and Daniel Kang},
year = {2024},
booktitle = {Findings of the Association for Computational Linguistics: ACL 2024},
publisher = {Association for Computational Linguistics},
pages = {10471-10506},
doi = {10.18653/v1/2024.findings-acl.624},
url = {https://aclanthology.org/2024.findings-acl.624/},
eprint = {2403.02691},
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}
}
Introduces macaroons, bearer credentials built from chained HMACs that any holder can attenuate by adding caveats (contextual restrictions such as time, target or third-party discharge) without contacting the issuer, enabling decentralized delegation in cloud services.
Why it matters here: The attenuable-token model behind later agent delegation designs (Biscuit tokens in AIP, scoped mandates in ap2) and a reference point for how visa-tap and openai-acp scope agent authority. AP2: Caveat-based attenuation, an ancestor of constraint-limited delegation. x402: Macaroons, the credential in the original L402 design (an earlier HTTP 402 approach on Lightning).
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{birgisson2014macaroons,
title = {{Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud}},
author = {Arnar Birgisson and Joe Gibbs Politz and Úlfar Erlingsson and Ankur Taly and Michael Vrable and Mark Lentczner},
year = {2014},
booktitle = {Proceedings 2014 Network and Distributed System Security Symposium (NDSS)},
publisher = {Internet Society},
doi = {10.14722/ndss.2014.23212},
url = {https://doi.org/10.14722/ndss.2014.23212}
}
Argues that the deepest economic effect of generative AI is lower communication friction between consumers and businesses, with assistant agents and service agents transacting programmatically. The authors separate unscripted interactions, enabled by language and protocol design, from unrestricted interactions, which depend on market structure and governance, and discuss walled gardens versus an open agent web, advertising and discovery, micro-transactions and the rebundling of digital goods.
Why it matters here: The clearest economic framing of why ACP, UCP and AP2 exist: its assistant-agent and service-agent split maps onto the buyer-agent and merchant roles those protocols standardize, and its walled-garden warning is the open question behind all of them, with x402 as the micro-transaction case.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@article{rothschild2026agenticeconomy,
title = {The Agentic Economy},
author = {David M. Rothschild and Markus M. Mobius and Jake M. Hofman and Eleanor Dillon and Daniel G. Goldstein and Nicole Immorlica and Sonia Jaffe and Brendan Lucier and Aleksandrs Slivkins and Matthew Vogel},
year = {2026},
journal = {Communications of the ACM},
volume = {69},
number = {2},
pages = {39-42},
doi = {10.1145/3747175},
url = {https://doi.org/10.1145/3747175},
eprint = {2505.15799},
archivePrefix = {arXiv}
}
A survey chapter for economists on how AI agents that plan and act over long horizons with little oversight might interact with people and with each other, reshape markets and organizations, and what institutions would be needed for such markets to work.
Why it matters here: Frames the institutional questions (identity, liability, enforcement) that ERC-8004 registries and AP2 mandates try to answer with technical artifacts.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{hadfield2025economy,
title = {An Economy of AI Agents},
author = {Gillian K. Hadfield and Andrew Koh},
year = {2025},
eprint = {2509.01063},
archivePrefix = {arXiv},
primaryClass = {econ.GN},
url = {https://arxiv.org/abs/2509.01063},
note = {arXiv preprint}
}
Builds an experimental framework in which consumer and merchant LLM agents negotiate and transact with each other. Outcomes differ sharply across models, and behavioral anomalies lead to overspending or acceptance of unreasonable deals, producing losses for both sides.
Why it matters here: Agent-to-agent negotiation is the step before an ACP or UCP checkout and before an AP2 mandate is signed; the paper quantifies the asymmetry and loss risk users accept when they delegate the deal itself.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{zhu2025risky,
title = {The Automated but Risky Game: Modeling and Benchmarking Agent-to-Agent Negotiations and Transactions in Consumer Markets},
author = {Shenzhe Zhu and Jiao Sun and Yi Nian and Tobin South and Alex Pentland and Jiaxin Pei},
year = {2025},
eprint = {2506.00073},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2506.00073},
note = {arXiv preprint}
}
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}
}
Compares technical and legal ideas of agency, linking implied authority in agency law to value alignment in AI, and argues that computer science has under-theorized the agent's loyalty to its principal and its dealings with third parties.
Why it matters here: Agent payments put third parties (merchants, networks) in contact with an agent; the paper explains which legal duties may attach and why protocols record what the user actually authorized. AP2: Agency and liability when AI agents act.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{riedl2025law,
title = {{AI Agents and the Law}},
author = {Mark O. Riedl and Deven R. Desai},
year = {2025},
booktitle = {Proceedings of the AAAI/ACM Conference on AI, Ethics, and Society},
volume = {8},
pages = {2189--2198},
doi = {10.1609/aies.v8i3.36705},
url = {https://doi.org/10.1609/aies.v8i3.36705}
}
Uses the economics of principal-agent problems and the common law of agency to analyze AI agents, identifying problems of information asymmetry, discretionary authority and loyalty, and argues that incentives, monitoring and enforcement work poorly for agents acting at machine speed and scale.
Why it matters here: Frames delegated purchasing in legal terms, which matters for the mandate and consent records that AP2, Agent Pay and the other protocols produce as evidence of authority. AP2: Legal and governance frame for agents acting for principals.
Metadata verified 2026-10-11 through arxiv.
Show BibTeX
@misc{kolt2025governing,
title = {{Governing AI Agents}},
author = {Noam Kolt},
year = {2025},
eprint = {2501.07913},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2501.07913}
}
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
Christoph Busch. 2026. CERRE Issue Paper. Not peer reviewed
An issue paper (published 2026-07-16) asking whether EU consumer law, built on the assumption that a human makes the final purchase decision, is ready for AI shopping agents, and proposing how to adapt it. It is part of CERRE's Regulatory Lab series, which received input from members including Apple, Booking.com and Microsoft.
Why it matters here: Checkout protocols such as ACP and UCP assume the agent can confirm a purchase; this paper explains where EU disclosure and consent rules may not fit that flow. Agentic Commerce Protocol (ACP): Consumer protection analysis of agentic commerce including ACP.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@techreport{busch2026cerre,
title = {{Agentic AI and Consumer Protection}},
author = {Christoph Busch},
year = {2026},
institution = {Centre on Regulation in Europe (CERRE)},
type = {Issue Paper},
month = {jul},
url = {https://cerre.eu/publications/agentic-ai-and-consumer-protection/}
}
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/}
}
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}
}
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}
}
Katharina Schumacher, Roger Roberts, Katharina Giebel. 2025. McKinsey & Company report. Not peer reviewed
A consulting report (2025-10-17) estimating that agents could orchestrate $900 billion to $1 trillion of US B2C retail revenue by 2030 and $3 trillion to $5 trillion globally, counting goods only. It discusses the infrastructure, business models and trust needed for that shift.
Why it matters here: The largest of the widely cited market forecasts; useful as the upper bound when the atlas compares adoption claims, and it is a forecast, not measured volume.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{schumacher2025mckinsey,
title = {{The agentic commerce opportunity: How AI agents are ushering in a new era for consumers and merchants}},
author = {Katharina Schumacher and Roger Roberts and Katharina Giebel},
year = {2025},
howpublished = {McKinsey \& Company},
note = {Report, 2025-10-17. Forecast figures as of publication},
url = {https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-agentic-commerce-opportunity-how-ai-agents-are-ushering-in-a-new-era-for-consumers-and-merchants}
}
AP2 assumes every LLM and agent can be turned against the user, so it puts the user's approval on a non-agentic Trusted Surface and binds every mandate to one checkout with hashes. Within that design, tampering with the checkout or payment and reusing a stolen mandate are well covered. The open problems sit before and after the signature: prompt injection that steers what the agent picks, replay at runtime because verifiers have no consume-once rule, no revocation of open mandates, no step-up in v0.2, and no retention rule for dispute evidence. No CVE or advisory exists for the repository; the published findings come from 2026 research papers and unreviewed GitHub issues.
STRIDE threats (12)
STRIDE
Threat
Spec mitigation
Implementer notes
S Spoofing
Manipulated discovery steers the agentText in product listings or tool results (prompt injection) pushes the agent toward a brand, a pricier item or another user's credentials while it builds the cart. Source [12, 36, 39, 40]Preconditions: The agent reads untrusted merchant or tool content; Constraints are wide enough to allow the steered choice.Impact: A validly signed purchase that the user did not really want.
Partly
Signatures cover the final checkout, not the decision. Keep constraints narrow, show human-present approval for high value, and isolate the signer from the model.
S Spoofing
Stolen Payment Mandate reused with another checkoutAn attacker replays a captured closed Payment Mandate against a different checkout. Source [16, 36]Preconditions: Mandate captured in transit or from logs.Impact: Unauthorized purchase.
Mitigated by spec
transaction_id names one checkout_jwt hash; open mandates must carry payment.reference.
S Spoofing
Agent key theftAn attacker obtains the agent private key named in cnf. Source [15, 35]Preconditions: Key stored where the model or host can reach it.Impact: Attacker can close any open mandate within its constraints.
Partly
Proof of possession binds the mandate to the key, not to the agent's integrity. Keep the key in deterministic code or hardware; keep open mandates short and narrow.
T Tampering
Manipulated checkoutThe agent or a man in the middle alters items or price between the merchant's signed checkout and the user approval. Source [13, 21, 36]Preconditions: Agent or transport compromised.Impact: User approves a different checkout than the merchant created.
Mitigated by spec
The merchant signs checkout_jwt and checks checkout_hash against its latest checkout before completing.
T Tampering
Manipulated paymentThe agent or Credential Provider changes payee, amount or instrument in transit. Source [19, 36]Preconditions: A party between the Trusted Surface and the processor is malicious.Impact: Funds go elsewhere or amount changes.
Mitigated by spec
Processors and Credential Providers verify the user signature, the transaction_id binding and every constraint.
R Repudiation
Replay of an accepted mandate at runtimeRetries, concurrency or orchestration let the same accepted closed mandate be processed more than once. Source [13, 25, 41]Preconditions: Verifier keeps no consumed-mandate record.Impact: Duplicate charges.
Partly
The spec forbids overlapping presentations by the agent but defines no consume-once rule for verifiers; record each accepted mandate hash. Issue 346 reports the samples never consume accepted mandates.
R Repudiation
Dispute evidence not retainedMandates and receipts are not stored, so nobody can prove what the user approved. Source [13]Preconditions: No retention agreement between parties.Impact: Disputes fall back to network rules without evidence.
Left to implementers
Retention and retrieval are out of scope; agree retention with your network and processor.
I Information disclosure
Leakage of user intent through constraintsA merchant learns the user's full budget or other merchants from open mandate constraints. Source [13, 36]Preconditions: Agent discloses all constraints.Impact: Privacy loss and price discrimination.
Mitigated by spec
Selective disclosure is mandatory for constraints; decoy digests may be added; disclose only what the verifier needs.
I Information disclosure
Rainbow-table guessing of digestsAn observer guesses checkout contents from checkout_hash or disclosure digests. Source [3, 13, 36]Preconditions: Low-entropy checkout content; Deterministic signatures.Impact: Purchase details exposed.
Partly
Salted digests per RFC 9901; the two spec documents disagree on deterministic signatures (issue 268). Use ECDSA and add entropy.
D Denial of service
Fallback abuse through unresolved_constraintAn attacker forces repeated unresolved_constraint errors so the user is asked again and again, or into a non-agentic flow with weaker checks. Source [15, 32]Preconditions: Merchant or agent behaves maliciously.Impact: Approval fatigue; users approve without reading.
Left to implementers
v0.2 defines no step-up and no limit on fallbacks; Trusted Surfaces should show the full checkout each time.
E Elevation of privilege
Double spend from one open mandateA compromised agent signs several closed mandates from one open mandate before any receipt arrives. Source [13, 36]Preconditions: Agent signer reachable by the model or attacker.Impact: Purchases beyond what the user approved.
Partly
The deterministic part of the agent must not sign overlapping mandates without a rejection receipt; Credential Providers, networks or processors may reject overlaps or invalidate tokens.
E Elevation of privilege
No revocation of an open mandateA user changes their mind or the agent is compromised, but an open mandate stays valid until exp. Source [15, 35, 57]Preconditions: Long exp; No out-of-band blocking.Impact: Purchases after the user withdrew consent.
Left to implementers
Use the shortest exp the task allows; Credential Providers and networks can refuse tokens. ERC-8226 shows an on-chain revoke for comparison.
Preconditions: Processor times out after charging; Verifier keeps no record of accepted mandates.
The agent receives no receipt and retries
The same closed mandate is accepted again
A second charge goes through
Impact: Duplicate payment until reconciled.
Compromised agent within a long open mandate Source [16, 35]
Preconditions: Open mandate with a week-long exp and a budget constraint; Agent key reachable on the host.
Attacker copies the agent key
Attacker closes mandates with allowed merchants up to the budget
The user cannot revoke the open mandate
Impact: Loss up to the budget before exp.
Published research findings
Signing the Transaction but Not the Decision: Whisper Attacks and a Binding Defense for AP2: Product-description text steers sample agents into credential fetches, cart divergence and upgrades; proposes A-VIP session binding. (paper in section G) Source [40]
A Formal Analysis of Agent Payment Protocols: Tamarin models of x402, MPP, ACP and AP2; 40 new formal-consistency findings across 86 cases. (paper in section G) Source [61]
Beyond the Mandate: A Systematic Security Analysis of the Agent Payments Protocol (AP2): 48 threats in five families across five architectures, eight in the High band; valid signatures do not guarantee intent when the pre-authorization context is manipulated. (paper in section G) Source [12]
SoK: Security of Autonomous LLM Agents in Agentic Commerce: 12 cross-layer attack vectors across agent payment protocols including AP2. (paper in section G) Source [62]
Zero-Trust Runtime Verification for Agentic Payment Protocols: Replay and context-redirect gaps from retries and concurrency; consume-once nonces at about 3.8 ms in simulation. (paper in section G) Source [41]
Whispers of Wealth: Red-Teaming Google's Agent Payments Protocol via Prompt Injection: Branded Whisper and Vault Whisper attacks steer product ranking and extract user data from an AP2 shopping agent. (paper in section G) Source [39]
CVEs and advisories
No CVE or advisory is recorded for this protocol as of the last verification.
AP2 is a controls protocol at heart: consent capture, spending caps, merchant and payee scoping, time windows and signed receipts are native. What it lacks is revocation, step-up, agent registration and consume-once replay tracking. The best places for an independent controls layer are the agent signer (before a closed mandate is signed), the Credential Provider (before a token is issued) and the evidence store after the purchase.
The agent proves possession of the key in cnf; who the agent is belongs to the commerce protocol layer. Source [15, 35]
Agent registration (know your agent)
None
No registry or know-your-agent step; under the Trusted Agent Provider model verifiers keep their own list of trusted providers. Source [15]
User consent capture
Native
A non-agentic Trusted Surface shows the Mandate Content and authenticates the user before signing. Source [13, 32]
Spending caps
Native
payment.amount_range per payment and payment.budget across recurring uses. Source [16]
Merchant or payee scoping
Native
checkout.allowed_merchants, checkout.line_items, payment.allowed_payees, payment.allowed_pisps and payment.allowed_payment_instruments. Source [16, 31]
Time windows and expiry
Native
iat and exp on every mandate, payment.execution_date windows and payment.agent_recurrence frequency. Source [16, 19]
Revocation
None
No mandate revocation in v0.2; only short exp and agent-side mandate management. Source [15, 35]
Step-up authentication
None
v0.2 specifies no step-up; a failed check falls back through unresolved_constraint to a user-approved closed mandate. v0.1 had 3DS2 and OTP challenges. Source [15, 37]
Replay protection
Partial
checkout_hash, transaction_id, sd_hash, cnf and the one-presentation-at-a-time rule; consume-once tracking is left to verifiers. Source [13, 36, 41]
Receipts and evidence
Native
Signed Payment and Checkout Receipts whose reference is the hash of the closed mandate. Source [34]
Dispute support
Partial
Dispute verification steps are defined; retention, retrieval and adjudication are out of scope. Source [13]
No revocation. An open mandate is valid until exp; there is no revoke message or status list. Source [35]
No step-up in v0.2. Only the unresolved_constraint fallback; no challenge messages are defined. Source [15]
No consume-once rule. Verifiers are not told to record accepted mandates; issue 346 reports the samples never do. Source [25, 41]
Stateful constraints without an owner. payment.budget and payment.agent_recurrence need presentation history, and nobody is assigned to keep it. Source [17]
Pre-authorization context unprotected. Mandates cover the final checkout, not the inputs that shaped the agent's choice. Source [12, 40]
Where an independent controls layer can act
Before authorization
Narrow the open mandate: merchants, line items, amount range, budget, short exp. Trusted Surface templates and policy that refuse wide constraints. Source [13, 16]
At signing
Decide whether the agent may close an open mandate for this checkout. A deterministic signer that evaluates constraints itself and refuses overlapping presentations. Source [13, 36]
At settlement
Refuse or scope the payment credential. Credential Provider and network checks, token invalidation, budget tracking. Source [13, 36]
After the fact
Prove what was approved. Store the open, closed and receipt tuple and run the dispute verification steps. Source [13, 15]
Implementer checklist
Reject any constraint type you do not recognize. The spec requires unknown constraints to fail. Source [15]
Compare checkout_hash with the hash of your latest checkout_jwt before completing. It is the binding that stops a stale or altered checkout. Source [13]
Record the hash of every accepted closed mandate and refuse repeats. Consume-once behavior is not specified. Source [41]
Keep the agent signing key out of the model's reach. Anyone with the key in cnf can close the open mandate. Source [35]
Set exp to the shortest time the task needs. Expiry is the only way an open mandate ends. Source [13, 35]
Sign checkouts with ECDSA (ES256) and include entropy. Resolves both sides of the issue 268 conflict. Source [3]
Store mandates and receipts for your dispute window. AP2 leaves retention out of scope. Source [13]
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.
AP2 moves no money, so payment law reaches it through the parties that use mandates: issuers, Credential Providers, processors and merchants. Its main legal value is evidence: a signed record of what the user authorized, which is the central fact in any unauthorized-transaction dispute under Regulation E, Regulation Z, PSD2 or the UK PSRs. Open questions are whether an open mandate counts as consent to each later transaction, how strong customer authentication works when the user is absent, and who carries the loss when an agent stays inside its limits but misreads the user. The specification claims no compliance with any of these rules.
Rules by topic and jurisdiction
Jurisdiction
What applies
Confidence
Consumer protection and liability
United States
Regulation E treats a transfer as unauthorized only without actual authority, and excludes transfers by someone the consumer gave the access device to until notice. An open AP2 mandate is evidence of authority given to an agent, which may shift losses toward the consumer. Source [13, 63]
Verified
United States
Regulation Z caps cardholder liability for unauthorized use at 50 dollars and asks whether there was actual, implied or apparent authority. Whether an agent acting outside a mandate has apparent authority is open; mandates are the evidence either way. Source [1, 64]
Verified
European Union
PSD2 requires payer consent to the specific transaction and caps payer liability for unauthorized ones. Whether a signed open mandate is consent to each later transaction is untested. Source [15, 60]
Verified
United Kingdom
The Payment Services Regulations 2017 treat a payment as authorised only with payer consent (regulation 67) and cap liability at 35 GBP for misappropriated instruments (regulation 77). Source [75, 76]
Verified
Canada
The Retail Payment Activities Act has required payment service providers to have risk management and safeguarding frameworks since 2025-09-08. No agent-specific liability rule was found. Source [80]
Verified
Singapore
The MAS E-Payments User Protection Guidelines allocate liability for unauthorized and erroneous e-payments. Source [82]
Verified
Card network rules
No public Visa or Mastercard rule on agent-specific disputes or liability shifts was found as of 2026-10-11; AP2 itself leaves liability to the networks and offers mandates as evidence. Source [1, 58]
Reported
AML and sanctions
United States
AP2 has no KYC, sanctions or know-your-agent layer. AML and sanctions duties stay with the Credential Provider, processor and network that already carry them. Source [13, 67]
Verified
Strong customer authentication
European Union
The RTS on strong customer authentication requires two factors and dynamic linking of amount and payee for remote payments. The AP2 glossary defines both terms but the spec claims no compliance; a human-not-present payment needs an exemption, a merchant-initiated setup or a delegated model. Source [23, 69]
Verified
European Union
PSD3 and the Payment Services Regulation reached provisional agreement on 2025-11-27 and were not in the Official Journal in the latest sources found; no agent-specific provisions were reported. Source [70, 71]
Reported
Card network rules
EMVCo published a draft agentic payments framework on 2026-09-01 and lists agentic transaction indicators as possible future work. Source [85]
Verified
AI-specific rules
United States
No federal statute or CFPB rule on AI agents in payments was found; Senator Warner asked Treasury on 2026-06-02 to examine liability for agentic payment rails. Source [65, 66]
Reported
European Union
AI Act transparency duties under Article 50 apply from 2026-08-02; the Digital Omnibus moved Annex III high-risk duties to 2027-12-02. A shopping or payment agent is not high-risk by default. Source [72, 73]
Verified
United Kingdom
The FCA said on 2026-03-25 it will consider whether regulation must change for agentic payments, and HM Treasury consulted from 2026-07-14 to 2026-10-06 on authentication, consent and liability for agents. Source [77, 78]
Verified
Singapore
MAS issued Guidelines on AI Risk Management on 2026-10-07, effective 2027-10-07, and names agentic AI systems. Source [83]
Verified
Card network rules
Ant International, Mastercard and Visa announced Know Your Agent interoperability work on 2026-09-11, building on TAP and Verifiable Intent; it is a collaboration, not a rule. Source [84]
Reported
Data protection
United States
Regulation P governs how financial institutions share consumer financial information; risk_data and disclosed mandate fields reaching a Credential Provider fall under the provider's existing duties. Source [19, 68]
Verified
European Union
GDPR Article 22 limits decisions based solely on automated processing with significant effects. AP2 makes selective disclosure of constraints mandatory, which supports data minimization. Source [36, 74]
Verified
United Kingdom
The Data (Use and Access) Act 2025 amends UK GDPR rules on automated decision-making. Source [79]
Verified
Canada
PIPEDA governs private-sector personal information, including risk_data and disclosed mandate fields held by Canadian parties. Source [81]
Verified
K. Observability lens
1 of 5 observability score
AP2 defines no registry, explorer, event stream or .well-known path of its own.
Mandates, receipts and risk_data are private between the parties, and selective disclosure deliberately limits what each sees.
Support is publicly visible only where a UCP merchant lists dev.ucp.common.payment.ap2_mandate in /.well-known/ucp.
The specification, schemas and GitHub activity are public, which is how adoption signals can be tracked.
Publicly observable
Public signals
What
Where
How
UCP merchants that accept AP2
/.well-known/ucp on each business domain
capabilities list includes dev.ucp.common.payment.ap2_mandate; signing keys in keys[]. Source [14]
Specification, schemas and samples
github.com/google-agentic-commerce/AP2 and ap2-protocol.org
Schema $id URLs under https://ap2-protocol.org/schemas/. Source [7, 38]
Repository activity
GitHub API
Commits on main, issues and pull requests; main idle since 2026-04-29. Source [11, 25]
Self-reported deployments
GitHub issues
For example issue 345, which publishes its own /.well-known/ap2.json, a path AP2 does not define. Source [48]
Private by design
Open and closed mandates. Exchanged only between agent, Credential Provider, merchant, processor and network.
Payment and Checkout Receipts. Signed JWTs returned to the parties, never published.
risk_data and undisclosed constraints. Selective disclosure keeps them from verifiers that do not need them.
What an indexer or monitor could capture
AP2 support among UCP merchants from Crawling /.well-known/ucp profiles: dev.ucp.common.payment.ap2_mandate, keys[] kid valuesSource [14]
Specification and SDK activity from GitHub API on google-agentic-commerce/AP2 and a2a-x402: commit SHA, tag v0.2.0, issue numbersSource [9, 11]
L. Ecosystem and adoption
Stewards
FIDO Alliance: Develops the specification in its Payments Technical Working Group and Agentic Authentication Technical Working Group since the 2026-04-28 donation; no deliverable published yet. Source [4, 5]
Google (google-agentic-commerce): Created AP2 (announced 2025-09-16); keeps the GitHub samples and SDK. Source [1, 8]
Implementers and deployments
Implementers (5)
Name
Role
Status
Universal Commerce Protocol
Specifies the AP2 extension dev.ucp.common.payment.ap2_mandate; live use unverified. Source [1, 14]
Announced
Google products (Gemini Spark first)
Google said on 2026-05-19 it would begin bringing AP2 to its products in the coming months. Source [26]
Announced
Mastercard Verifiable Intent
Aligned mandate format co-developed with Google and contributed to FIDO. Source [4, 20]
Announced
Suede Agent Studio
Self-reported merchant-side v0.2 deployment in issue 345; not independently verified. Source [48]
Unknown
Launch collaborators (Adyen, American Express, Coinbase, Mastercard, PayPal, Worldpay and others)
Named in the 2025-09-16 launch post; being named is not deployment. Source [8]
Build v0.1 or v0.2 mandates, try carts that break the constraints, sign with ephemeral ES256 keys and watch each verifier recompute checkout_hash, transaction_id, sd_hash and the cnf binding; simulation only, no real funds.
Simulation, no real fundsFollows spec version v0.2
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
UCP is AP2’s home. UCP decides where the artifacts travel and AP2 decides what they contain. The extension, named dev.ucp.shopping.ap2_mandate until v2026-04-08 and dev.ucp.common.payment.ap2_mandate since v2026-08-25, is advertised in /.well-known/ucp. The merchant signs each checkout as a detached JSON Web Signature (JWS) in ap2.merchant_authorization, and the platform must send ap2.checkout_mandate on complete.Source [14, 27, 28, 44] Once negotiated, neither side may fall back to an unprotected checkout, and UCP adds its own errors such as mandate_required and mandate_scope_mismatch.Source [28, 53] All of this is specified; production use inside UCP is unverified.Source [1, 12]? unverified
Mastercard’s is AP2’s closest sibling and now sits beside it at . It uses the same vct values (mandate.checkout.open.1, mandate.checkout.1, mandate.payment.open.1, mandate.payment.1) and aligned semantics with different key prefixes: AP2 writes payment.amount_range, Verifiable Intent writes mandate.payment.amount_range.Source [16, 20, 21, 54] Those names exist only on Verifiable Intent’s main branch since 2026-04-20; at its tag v0.1.0 they were different, so check which revision your counterpart implements.Source [55, 56]
x402 meets AP2 through a2a-x402. Its v0.2 Embedded Flow nests the x402 payment requirements inside an AP2 CartMandate and the signed payment inside a PaymentMandate.Source [18] Those are v0.1 objects. AP2 v0.2 has no Cart , and neither specification defines the v0.2 mapping, so the documented embedding is out of step with current AP2.Source [18, 19] The AP2 repository still ships x402 samples for both modes.Source [7]
ERC-8226, a draft Ethereum standard created on 2026-04-12, is the on-chain analogue of an . A verified principal grants an agent scoped, time-bounded, capped authority, with on-chain revocation and freeze that AP2 lacks, and ERC-8004 serves as its identity layer.Source [57] It does not mention AP2.Source [57] Visa TAP, OpenAI ACP and Stripe MPP have no documented link to AP2; Visa co-chairs the FIDO payments group where AP2 now lives.Source [4, 7]
Relations to other protocols
Compatible withAP2 to Mastercard Agent Pay: Verifiable Intent shares AP2 v0.2 vct values with aligned constraint semantics and different key prefixes (payment.amount_range versus mandate.payment.amount_range); both were contributed to FIDO on 2026-04-28. Source [4, 16, 20]
Compatible withAP2 to x402: The a2a-x402 Embedded Flow nests x402 inside AP2 mandates, but it targets the v0.1 CartMandate and PaymentMandate; AP2 v0.2 has no Cart mandate. The AP2 repository ships x402 samples. Source [7, 18]
EmbedsAP2 to UCP: UCP embeds AP2 through the extension dev.ucp.common.payment.ap2_mandate (renamed in v2026-08-25): merchant signature in ap2.merchant_authorization, Checkout Mandate in ap2.checkout_mandate, Payment Mandate in the credential token. Live use unverified. Source [1, 14, 28]
Complementsfrom ERC-8004: Trustless Agents: Indirect only: ERC-8004 lists A2A agent cards as services and AP2 can be implemented as an A2A extension. ERC-8226 is the closest on-chain analogue of an AP2 mandate. Source [23, 88, 89]
Complementsfrom Mastercard Agent Pay: Agent Pay is not AP2. Through Verifiable Intent it uses the same four mandate vct values as AP2 v0.2 on main, with aligned constraint semantics and a mandate. key prefix; both were contributed to FIDO on 2026-04-28. No live VI use inside AP2 is documented. Source [90, 91, 92]
Complementsfrom Agentic Commerce Protocol (ACP): ACP has no mandates or signed user intent; AP2 mandates or Verifiable Intent could add that layer, but no adopted extension exists. Source [93, 94]
Complementsfrom Stripe MPP (Machine Payments Protocol): Complementary in principle (AP2 carries user authorization evidence, MPP settles payment) but no specification binds them and neither repository mentions the other. In AP2, MPP means Merchant Payment Processor. Source [95, 96]
Embedsfrom UCP: AP2 is an optional UCP extension, dev.ucp.common.payment.ap2_mandate (dev.ucp.shopping.ap2_mandate before v2026-08-25). UCP places the merchant authorization, checkout mandate and payment mandate; AP2 defines the formats. Live use is unverified. Source [27, 28, 53, 97]
Same stewardfrom UCP: Google launched both; Google donated AP2 to the FIDO Alliance on 2026-04-28 while UCP stays under its own Governing Council. Source [98, 99]
Embedsfrom x402: AP2 can carry x402 as a payment method through the a2a-x402 extension launched on 2025-09-16; its embedded flow targets AP2 v0.1 mandates (CartMandate), which AP2 v0.2 no longer has. Source [100, 101, 102]
AP2 in the compare matrix (34 dimensions)
Dimension
Value
Confidence
Primary job
Signed mandates that prove what a user authorized an agent to buy Checkout and Payment Mandates, closed or open, verified by merchant, credential provider and processor.Source [13]
Verified
Layers covered
Intent and authorization; payment credential scoping; dispute evidence No rail, no checkout messages, no identity registry.Source [13, 35]
Verified
Stewards
FIDO Alliance working groups; Google for samples and SDK Donated 2026-04-28.Source [1, 4]
Verified
Governance model
Industry alliance working groups (FIDO) Payments Technical Working Group chaired by Mastercard and Visa; no public deliverable yet.Source [4, 6]
Verified
License (spec and code)
Apache-2.0 Repository license covers docs, schemas and code.Source [7]
v0.2.0 (2026-04-28) main idle since 2026-04-29.Source [9, 11]
Verified
Maturity
Draft specification with samples No verified production use.Source [1, 12]
Unverified
Transports
Transport-agnostic inside a commerce protocol UCP extension; A2A in samples; OpenID4VP and the Digital Credentials API for delegation.Source [7, 13, 14]
Verified
Settlement rails
None of its own (rail-agnostic) Cards, bank transfers, PISPs and x402 via a2a-x402.Source [13, 38]
Verified
Agent identity model
Proof of possession of the agent key in cnf Agent identification left to the commerce protocol.Source [15, 35]
Verified
User authorization model
User-signed mandates (SD-JWT VC) on a non-agentic Trusted Surface User Credential or Trusted Agent Provider delegation.Source [13, 15]
Verified
Human-present and human-not-present support
Both Closed mandates for human present; open mandates with constraints for human not present.Source [32]
Verified
Merchant of record
Unchanged: the merchant AP2 adds no intermediary that takes over the sale.Source [13]
Verified
Credential type
Payment token scoped by a verified Payment Mandate Issued by the Credential Provider, possibly with the network.Source [32]
Verified
Cryptography
SD-JWT VC with ES256, Delegate SD-JWT chains, SHA-256 hash bindings JWK type fixes EC P-256.Source [15, 38]
Verified
Replay protection
checkout_hash, transaction_id, sd_hash and cnf; one presentation at a time No consume-once rule for verifiers.Source [36, 41]
Verified
Native spending controls
Yes: payment.amount_range and payment.budget Plus payee, merchant, instrument, PISP, line item, date and recurrence constraints.Source [16, 31]
Verified
Revocation
None; expiry only The spec recommends the shortest exp.Source [13, 35]
Verified
Refunds and disputes
Dispute verification steps; no refunds Retention, retrieval and adjudication out of scope; liability with networks.Source [1, 13]
Verified
Privacy exposure
Low by design: mandatory selective disclosure of constraints risk_data travels to verifiers.Source [19, 36]
Verified
Discovery mechanism
None of its own; UCP /.well-known/ucp lists the extension Source [14]
Verified
Permissionless or registration required
Open specification; verifiers choose which issuers or agent providers to trust No registration step defined.Source [15]
Verified
Decentralization
Bilateral trust between parties; governed by an alliance No central operator in the protocol.Source [4, 15]
Verified
Observability score
1 of 5 Everything except UCP profiles and GitHub activity is private.Source [13, 14]
Verified
Fees and who pays them
No protocol fee Costs are those of the underlying rail.Source [13]
Verified
Who pays (short)
Card or rail economics unchanged AP2 adds no fee; merchants may carry a second signing key type.Source [3, 13]
Verified
Builds on (standards)
SD-JWT (RFC 9901), SD-JWT VC, Delegate SD-JWT draft, RFC 7800, OpenID4VP, Digital Credentials API VC 2.0 and DIDs only as the wider family.Source [15, 24]
Verified
Composes with
UCP (extension), x402 (a2a-x402, v0.1 target), Mastercard Verifiable Intent No documented link with TAP, ACP, MPP or ERC-8004.Source [7, 14, 18, 20]
Verified
Reference implementations and SDKs
Python SDK and samples in Python, Go and Android SDK not on PyPI; TypeScript SDK PR closed unmerged.Source [7, 25]
Verified
Adoption evidence
Unverified anywhere, including inside UCP One self-reported deployment (issue 345); 3,216 GitHub stars on 2026-10-11.Source [1, 48, 86]
Unverified
Published security research
Yes: several 2026 papers; no CVE 48 threats (2608.23858), prompt injection, replay, formal analysis.Source [12, 39, 41, 43]
Verified
Regulatory touchpoints
Consent and unauthorized-transaction rules; SCA Regulation E and Z, PSD2 and UK PSRs; no compliance claim in the spec.Source [23, 60, 63]
Verified
Biggest open question
Will FIDO publish it and will anyone deploy it? No FIDO deliverable and no verified production use as of 2026-10-11.Source [1, 4]
No. AP2 moves no money and defines no fee. It carries signed evidence of what the user authorized on top of cards, bank transfers or stablecoins. Source [8, 13]
MisconceptionIs AP2 the same as A2A?
No. A2A (Agent2Agent) is one transport that the AP2 samples use. Version 0.2 describes AP2 as a security feature inside a commerce protocol and leaves the messages to that protocol, for example UCP. Source [7, 13]
MisconceptionDoes AP2 v0.2 still have Intent and Cart Mandates?
No. Version 0.2 has only Checkout and Payment Mandates, each closed or open. Intent and Cart Mandates belong to v0.1, which most 2025 tutorials describe. Source [13, 19, 21, 22]
MisconceptionDoes Google still control AP2?
Not alone. Google donated AP2 to the FIDO Alliance on 2026-04-28, and specification work continues in FIDO working groups. Google keeps the samples and SDK. Source [1, 2, 3, 5]
MisconceptionDid FIDO create two new working groups for AP2?
Only one. The Agentic Authentication Technical Working Group was new on 2026-04-28; the payments group, chaired by Mastercard and Visa, has existed since 2025-04-29. Source [4, 6]
MisconceptionIs AP2 live in Gemini or in UCP?
Not verifiably. UCP specifies an AP2 extension and Google said in May 2026 it would bring AP2 to its products, but no primary source shows production use anywhere. Source [1, 12, 14, 26]? unverified
What is the difference between an open and a closed mandate?
A closed mandate binds to one checkout with exact values. An open mandate holds constraints and the agent's public key in cnf, so the agent can later sign a closed mandate inside those limits. Source [13, 15, 32]
MisconceptionCan a user revoke an open mandate?
Not in v0.2. No revocation mechanism exists; the specification recommends the shortest expiry that lets the agent finish. Source [13, 15, 35]
MisconceptionDoes AP2 v0.2 use 3DS2 step-up?
No. v0.2 specifies no step-up; a failed check falls back through unresolved_constraint. v0.1 allowed 3DS2 or OTP challenges, and the Executive Summary still mentions them. Source [15, 32, 37, 42]
MisconceptionIs the MPP in AP2 Stripe's Machine Payments Protocol?
No. In AP2, MPP stands for Merchant Payment Processor, a role. Source [13, 23]
MisconceptionDoes AP2 need W3C VC 2.0 and DIDs?
No. Version 0.2 uses SD-JWT VC, OpenID4VP and the Digital Credentials API; VC 2.0 and DIDs are the wider family. Source [15]
The a2a-x402 Embedded Flow nests x402 inside AP2 CartMandate and PaymentMandate objects, which are v0.1 objects. AP2 v0.2 has no Cart mandate, so the embedding is out of step with the current version. Source [18, 19]
MisconceptionIs the ap2 package on PyPI Google's SDK?
No. The PyPI and npm packages named ap2 belong to unrelated third parties; Google's Python SDK is installed from the repository. Source [7, 47]
R. Open questions and research frontier
Will FIDO publish AP2 as a standard, and when?
FIDO gave no deliverable or date, its drafts are member-only, and the GitHub repository has not changed since 2026-04-29. Source [4, 11]
How does a user withdraw an open mandate before exp?
v0.2 has no revocation; ERC-8226 shows an on-chain revoke and freeze for comparison. Source [35, 57]
Who keeps state for payment.budget and payment.agent_recurrence?
Both need history of earlier presentations, and the specification does not assign that role; Verifiable Intent calls such constraints network-enforced. Source [17, 20]
How should a2a-x402 embed x402 in AP2 v0.2?
The documented Embedded Flow targets v0.1 CartMandate and PaymentMandate; no v0.2 mapping exists in either specification. Source [18, 21]
Can the context before signing be protected?
Research shows valid signatures do not prove intent when listings or tool results steer the agent; proposals bind credential lookups and cart lines to the session. Source [12, 40]
Will verifiers adopt consume-once semantics?
Runtime replay across retries is not covered; one paper proposes time-bound nonces and an issue reports that the samples never consume accepted mandates. Source [25, 41]
Which signature rule applies to the Checkout JWT?
The specification and the security considerations disagree on deterministic signatures; issue 268 is open and deferred to FIDO. Source [3, 13, 36]
Will AP2 and Verifiable Intent converge on one set of key names?
Same vct values, different constraint prefixes, and Verifiable Intent renamed its keys on main without a version bump. Source [16, 20, 55]
Will networks give mandate-backed transactions different liability?
AP2 leaves liability to the networks, and no network rule specific to agents was found. Source [1, 58]
S. Self-test
Quiz
0 of 10 answered.
Flashcards
0 of 15 marked known. Card 1 of 15.
Prompt
Mandate
T. Notes
Notes stay in this browser. Nothing is sent anywhere.