Mandate Expression Compared — AP2, AP4M, Visa, ACP, Coinbase Side by Side, Where the Constraint Actually Lives

Five authorization schemes for AI-agent spending — AP2, Mastercard AP4M, Visa Intelligent Commerce, ACP, Coinbase Agentic Wallets — encode spend limits differently and store the constraint in different places (a signed document, a network-side token, or an on-chain rule). That placement decides how fast a principal can kill a live mandate and who can prove what happened afterward. None of the five publishes a revocation-speed number; the only measured revocation-latency data in these notes comes from a generic OAuth/JWT study, not from any of the five protocols.

AP2 (Google)

three JSON-LD documents structured as W3C Verifiable Credentials, signed with ECDSA over P-256 (or stronger) curves and SHA-256 hashing. Intent Mandate carries a natural-language request description, optional "prompt playback" summary, hard constraints (max price, item specs, expiration time, permitted merchants), and an agent identity reference. Cart Mandate carries the full item list (SKUs, unit prices, taxes, shipping, totals), currency, the merchant's signature over cart contents, and a co-signature from the user via a hardware-backed device key — "what you see is what you pay for." Payment Mandate carries a hashed payment-method reference, transaction amount, a human-present vs human-not-present flag, and a pointer to the upstream Cart Mandate, avoiding PII exposure to card networks. Every mandate carries a timestamp, nonce, signer public-key reference, and signature. Source: eco.com AP2 explainer.

Mastercard AP4M

credentialing runs on Mastercard's "Verifiable Intent" framework, giving every agent a verifiable identity recognized across counterparty ecosystems without re-authentication (eco.com/AP4M explainer, UNVERIFIED beyond this single source). Credentials are issued through Mastercard's own token infrastructure (MDES), not recorded on a public blockchain (zylos.ai); Polygon and Solana appear in coverage only as ecosystem/settlement partners, not as the credential-storage layer (cryptobriefing.com). The permissioning model is "cardholder-defined mandates bound to token at provisioning," validated in real time against the stored mandate, carrying provisioning-time constraints: spend ceilings, merchant categories, time windows, recurring-purchase rules (eco.com AP4M-vs-Visa comparison).

Visa Intelligent Commerce

tokens are merchant-specific and bound to agent + transaction context, not just the underlying card. The token schema extends existing network tokenization with two new fields — agent identifier and session-scope object — so a token is scoped to a single agent and a single transaction context, defining exactly what may be purchased. Compromise exposure is limited by design and replay is prevented. Visa's separate Trusted Agent Protocol instead requires a per-transaction signed intent from the cardholder with explicit authorization, contrasting with AP4M's standing mandates. Source: eco.com tokenization-for-agents explainer + AP4M-vs-Visa comparison.

ACP (Stripe/OpenAI)

the Shared Payment Token (SPT) primitive carries token ID (format spt_123), card brand and last four digits, single-seller scope, single-currency denomination, maximum charge amount, expiration timestamp (Unix format), and a status field (active/requires_action/deactivated). None of the three key SPT properties expose the PAN. Tokens are issued via POST /shared_payment/issued_tokens, where the agent supplies the customer's payment-method ID, the seller's network business-profile identifier, and usage constraints. Delegation separately runs on OAuth 2.0, with tokens carrying a max-amount + currency allowance, RFC 3339 expiration, merchant identifier, checkout-session reference, and risk-signal classifications. Server-side merchant verification rejects the PaymentIntent before money moves if the cart exceeds the SPT maximum or the currency mismatches. Spec snapshot dated 2026-04-17 (latest stable; unreleased work sits in an unreleased/ directory). Source: eco.com ACP explainer + docs.stripe.com/agentic-commerce/acp.

Coinbase Agentic Wallets

spend limits are session caps (max per session) and per-transaction caps, set at wallet creation and changeable later, enforced at the TEE (Trusted Execution Environment) level alongside allowlisted contracts. Policy enforcement happens at the signing layer before any private key is used — the agent cannot produce a signature that violates policy. The MPC wallet architecture keeps private keys inside enclave-isolated infrastructure. Source: eco.com Coinbase-wallets explainer.

Where each sits relative to [[concept/authorization-layer-vs-settlement-layer]]

AP2 is a pure mandate/signaling layer riding on top of whatever settlement rail is chosen; AP4M, Visa and ACP are network-level schemes that both authorize and settle within card-network or card-adjacent infrastructure; Coinbase's policy enforcement sits at the wallet-signing layer above on-chain settlement.

Where the constraint lives, and what that implies for revocation and disputes

A four-layer enforcement taxonomy from fystack.io frames where a spending rule can be placed: application code (first filter, easiest to update, but bypassable by bugs or prompt injection), policy engine & signing layer (flexible and auditable, supports KYT screening, but depends on the signing service's own security — this is where Coinbase's TEE enforcement sits), protocol & payment layer (covers both fiat and crypto rails but needs separate integration per rail — this is where AP2's mandate documents and ACP's SPTs sit), and smart contract & on-chain (tamper-proof, blockchain rejects a rule-violating transaction outright, but harder to update and crypto-native only).

Zeta.tech frames the same split differently: protocol-level constraints (AP2, x402, ATXP) formalize how intent and payment interact and transport proofs of identity/consent between layers, while network-level enforcement (card rails) implements the actual block through tokenization mechanics, virtual-card issuance, and message-field constraints inside existing Visa/Mastercard infrastructure. A virtual card with encoded limits functions as a "mini account" — MCC filters, spend caps, merchant binding, validity windows all encoded on the card itself. Network tokens bound to a specific agent identity can be revoked instantly on misuse telemetry, without reissuing the underlying card.

Revocation-speed implication

a network-side token (Visa, and by structure AP4M) can be killed by the network unilaterally because the network holds token state — this is what "instant revocation" means for Visa in these notes (no published latency number, just the descriptor "instant"). A self-contained signed credential (an AP2 mandate) has no revocation mechanism described in the source material at all — its Cart Mandate's hardware-backed co-signature stops the merchant from altering the cart post-signature, but nothing in the note material says how a principal revokes a mandate already issued. An on-chain policy (Coinbase) is enforced pre-signature, so nothing gets signed that violates the rule in the first place — but once a transaction is broadcast, finality (and therefore any window in which "stopping" it is even meaningful) depends on Base/Solana/Polygon block-confirmation time, not published in this material.

Dispute-handling implication

protocol-level mandates (AP2) create a cryptographic proof of authorization usable in a later dispute audit — the user's hardware-backed signature on the Cart Mandate proves authorization and blocks later denial. Network-side tokens (Visa, AP4M) let the network respond fast because it holds token state and can invalidate immediately. On-chain policies (Coinbase) create an immutable transaction record but — per the implicit read of the source — no chargeback or dispute mechanism equivalent to the card networks: crypto-native settlement has no built-in "money comes back" path.

Expiry and mid-session revocation: what's published, and what a generic token study shows

No protocol in this set publishes a default mandate/token lifetime or a revocation-latency SLA. Specifically: AP2's spec is silent on both revocation speed and default Intent/Cart/Payment Mandate expiry. AP4M's material states pulling agent authorization from the issuer's app invalidates the Agentic Token at the network level, with no published latency figure. Visa's tokens are described only as revocable "instantly," with no measured number. ACP's SPT carries an expiration timestamp field but no default/recommended lifetime is published, and revocation works by the merchant flipping status to deactivated — with no published latency between issuer and merchant systems. Coinbase's policy engine blocks bad signatures pre-issuance, but on-chain finality latency (which bounds how "final" a revocation is) depends on block confirmation and isn't published here.

What is measured, from an unrelated generic-token study (mojoauth.com), is the structural exposure that self-contained tokens (JWTs) create: once issued, a JWT stays valid at resource servers until it expires, because validation happens locally — so *token lifetime equals the revocation SLA*. Measured mean exposure after revocation: 1,794 seconds and 719 additional requests processed for a 1-hour token; 145 seconds and 59 requests for a 5-minute token; 25 seconds and 11 requests for a 60-second token. Multi-hop agent systems make it worse — a single-service setup showed 145 s mean exposure, a four-hop system 251 s (1.73× worse), a cascading-revocation effect. This is not a measurement of any of the five payment protocols — it is offered here as the general mechanism explaining *why* a self-contained signed credential (structurally, AP2's mandate model) cannot have instant revocation the way a network-held token (Visa) can, absent published numbers for AP2 itself.

A separate finding from the same source: RFC 7009 is asymmetric — a server given a refresh token SHOULD invalidate the grant's access tokens, but a server given only an access token MAY (not must) revoke the refresh token. In testing, revoking only the access token without the refresh token left an agent functional indefinitely: 1,316 requests processed two hours post-revocation. This is a general OAuth finding, relevant because ACP's payment-delegation layer explicitly runs on OAuth 2.0 — but the note material does not confirm ACP inherits this specific asymmetry; flagged unverified.

Industry pressure exists for a sub-500ms halt-confirmation contractual guarantee for pre-settlement actions (zeta.tech, described as a buyer-side SLA expectation, not a shipped guarantee by any of the five). Separately, OpenID's Shared Signals Framework 1.0 and CAEP (Continuous Access Evaluation Profile) 1.0 became Final in August 2025; CAEP defines a session-revoked event for push-based revocation notification — a general web-identity standard, not confirmed as adopted by any of the five payment protocols in this note material.

What none of the five protocols currently express

- Cross-protocol mandate portability: an agent authorized under AP2 cannot spend via a Visa Intelligent Commerce merchant without separate re-authorization today. Visa and Mastercard support *multiple* agent protocols through a single integration, but the agent still carries separate authorization per protocol (zylos.ai; the Crossmint claim about routing mechanics is UNVERIFIED — mechanism not detailed in the source). See Interoperability or Walled Gardens? Cross-Protocol Compatibility — what a builder actually integrates when an AP2, ACP, x402 and UCP agent all show up. - Dispute resolution for on-chain settlement: on-chain/stablecoin agent payments (Coinbase, and by extension any x402-settled leg) have no chargeback equivalent; when settlement is on-chain, no card-network chargeback applies and no clear Regulation E claim exists, leaving the liability bearer unresolved. See Who Is Liable When a Prompt-Injected Agent Spends Money — the unresolved question behind every mandate protocol in this wiki. - Real-time mid-transaction human override: no protocol here lets a human interrupt an agent purchase in the moment — the choice is pre-approval (static mandate) or a full abort. AP2's material frames real-time human approval as a roadmap item, not a current capability; the other four are silent on this in the note material. - Session-scoped issuance tied to presence: payment tokens can be generated well before execution, creating an exposure window; conventional OAuth assumes synchronous user presence, which agentic payments break because the user may not be in-session for the whole payment journey. None of the five explicitly binds token lifetime to a live session-presence signal (this last point is an inference from the absence of such a feature in the reviewed material, not a positive confirmation). - Agent-identity separation from user authorization: AP2 binds a mandate to the *user's* signing key, not the agent's identity — so a compromised agent can produce a mandate-signing prompt that fools the user, and the resulting signature is cryptographically valid even though the agent acted maliciously. None of the five separates "agent was compromised" from "user authorized this" at the moment of signature. - Liability allocation: when an autonomous agent overspends via prompt injection, hallucination, or misread intent, no protocol here allocates liability or provides an escrow/reserve mechanism. Industry opinion on who should bear it is split — roughly 39% AI providers, 20% customers, 14% merchants, 11% banks (zylos.ai survey figure, single source, no base/n published — treat as a sentiment split, not a measured outcome). - Session-level auditability: none of the five lets a principal reconstruct, after the fact, exactly what an agent was authorized to do versus what it actually did across a session. AP2's Cart Mandate captures the final item list and co-signature but not the session context (which prompts drove the agent's decisions); Coinbase gives on-chain immutability for the transaction itself but no session-level intent reconstruction.

Related

- Authorization Layer vs Settlement Layer — the split every agent-payment protocol page in this wiki must be read against — this page's five schemes are all instances of the generic mandate anatomy (identity, scope, constraints, expiry, signature, revocation) that page defines; use it to place each protocol on the settlement-vs-authorization map before reading the comparison above. - Google AP2 — the one agent-payment authorization spec that shipped code, not just a press release — full field-level detail on the three AP2 mandates only summarized here; go there for publication history and launch-partner-vs-shipped status. - Mastercard AP4M — an announced authorization layer, not yet a published spec or a shipped integration — AP4M's on-chain credentialing and launch-partner claims, condensed to permissioning fields here. - Visa Intelligent Commerce: Tokenized Agent Credentials — the spec-vs-announcement test applied to Visa's own numbers — Visa's token schema and ecosystem numbers in full; this page only extracts the scoping/revocation fields relevant to the comparison. - Agentic Commerce Protocol (ACP) — the checkout-layer spec Stripe and OpenAI ship, and the deployment it already killed — ACP's SPT and OAuth delegation building blocks in full. - Coinbase Agentic Wallets — spend limits enforced server-side, native x402, and how thin the outside-usage evidence still is — Coinbase's TEE/MPC architecture and x402 integration in full. - Who Is Liable When a Prompt-Injected Agent Spends Money — the unresolved question behind every mandate protocol in this wiki — picks up directly from the liability gap identified above: which US legal frame (EFTA/Reg E) might apply and what regulators have actually said. - Outside Implementations Tracker — separating shipped code from launch-partner press releases across the five agent-payment protocols — before trusting any claim in the comparison table above about what a protocol "does," check there whether anyone outside the issuing company has actually shipped it.