Open data · Mandates

State of Agent Mandates

When an AI agent is authorized to pay, what does the authorization actually look like, who issues it, and does it travel? Every major agent-payment rail, assessed from primary specifications and scored one of three ways: Portable (any third party can verify the mandate), Federated (open mechanics, but trust resolves inside the issuing network), or Walled (the artifact only means something to its issuer).

rails assessed from primary specs

issue a mandate verifiable outside their walls

federated: open mechanics, in-house trust

2026-06-12

last verified

The discipline, borrowed from our x402 tracker: live and announced are never mixed, every entry carries a primary source, and anything we could not verify firsthand is labeled, not guessed.

The finding

The identity layer has quietly converged: Visa's TAP and Mastercard's Web Bot Auth share the same signature standard and the same engineering partner, so "is this agent real" is already answerable across networks. The mandate layer has not: no rail can verify another rail's spending permission today, because almost every design records what the user allowed as a database row at the issuer instead of carrying it in the artifact. The agentic web agreed on who. The fight is over may.

Live and piloting

x402

Portable (verification only)Livex402 Foundation (Linux Foundation, in formation)

Anyone on the internet can verify the payload against public state. But it answers 'did this key authorize this payment,' not 'did a human authorize this agent.' Delegation semantics are explicitly out of scope.

Artifact: Signed on-chain transfer authorization (EIP-3009 pattern: from, to, value, validity window, nonce)

Issuer: The payer's own wallet key; nobody mints anything

Revocation: Validity window + nonce; on-chain cancel before settlement; no push notification to relying parties.

Bridges: MCP transport (x402 payload rides tool-call metadata); A2A transport; a2a-x402 extension into the AP2 ecosystem

Protocol v2 spec live; production usage on Base; foundation roster still unpublished by LF.primary source

Visa Trusted Agent Protocol

FederatedPilotVisa (spec open source, built with Cloudflare)

The signature format is an open IETF standard, so the mechanics travel. The trust decision does not: 'is this agent legitimate' resolves to Visa's registry, and the credential only resolves inside Visa authorization.

Artifact: Per-request RFC 9421 HTTP message signature; payment behind it is a tokenized Visa credential

Issuer: Agent's own keys, trusted via Visa's Agent Registry; Visa mints the payment tokens

Revocation: Not published. Registry removal fails future verifications; signatures are single-use.

Bridges: Same RFC 9421 + Cloudflare engineering base as Mastercard's Web Bot Auth: the identity layers are already technically interoperable

Spec live October 2025; pilot transactions completed December 2025; OpenAI partnership announced June 10, 2026.primary source

OpenAI / Stripe ACP

FederatedLiveOpenAI + Stripe (Apache 2.0, agenticcommerce.dev)

The spec is open and any PSP can implement issuance, which is real protocol-level interoperability. But each issued artifact is a database row at the issuing PSP: the allowance is exactly a mandate, enforced where nobody else can see it.

Artifact: PSP-issued scoped bearer token (vault token / Stripe Shared Payment Token) with an allowance: max amount, currency, merchant, expiry, single use

Issuer: The payment service provider, after buyer confirmation in the checkout UI

Revocation: Best in class among bearer designs: revocable any time, sellers notified by webhook. But only because the issuer runs the rails.

Bridges: PayPal processes ACP tokens as Braintree nonces; merchants expose checkout as an MCP tool

Instant Checkout live in ChatGPT for US users; adopted by PayPal and Meta.primary source

PayPal Agent Ready

FederatedLivePayPal / Braintree

The clearest case of a rail that verifies everyone else's artifacts and exports none of its own. One Braintree integration reaches ChatGPT, Google surfaces, and Perplexity; nothing PayPal issues is verifiable outside PayPal.

Artifact: Other rails' tokens (ACP delegated tokens, Google Pay tokens) processed as Braintree nonces; PayPal wallet auth on native flows

Issuer: Whoever the surface designates: the PSP under ACP, Google Pay under UCP, PayPal's wallet natively

Revocation: Single-use tokens expire or are consumed; wallet-level standing-permission revocation unpublished.

Bridges: Accepts ACP and UCP artifacts through one integration; the aggregator position is the strategy

Perplexity Instant Buy live November 2025; ChatGPT rollout 2026; Hey Savi UK launch June 2026.primary source

Google UCP (standalone)

FederatedLiveGoogle

On its own, a Google Pay-centered design: one transaction, one merchant's PSP. AP2 is its portability layer, not the other way round.

Artifact: Encrypted single-use Google Pay token; merchant UCP profile publishes verification keys

Issuer: Google Pay

Revocation: Single-use.

Bridges: AP2 Checkout Mandates wrap the UCP Checkout object by spec

Live on Google Search AI Mode and Gemini; Klarna and Affirm embedded via Google Pay.primary source

MCP (core protocol)

Walled by designLiveAnthropic / MCP project

Audience binding exists precisely so a token means nothing anywhere except the one server it was minted for. Correct security posture, and the opposite of a traveling mandate. MCP is the transport other rails' mandates ride on, not an issuer.

Artifact: OAuth 2.1 access token, scope-limited and audience-bound; payment credentials explicitly pushed out-of-band

Issuer: The MCP server's chosen OAuth authorization server

Revocation: Standard OAuth: short-lived tokens, mandatory refresh rotation for public clients.

Bridges: Carries x402 payloads in tool-call metadata; ACP checkout exposed as MCP tools; AP2 integrates alongside A2A

Authorization spec current as of 2025-11-25; no payment mandate primitive in core.primary source

Spec-only and announced

Kept strictly separate from the live list. A press release is not a deployment.

Google AP2

PortableSpec-onlyGoogle + 60 launch partners

A self-contained signed object any party on the trust list can verify, including parties Google has no relationship with. The design is portable today; the deployment is early.

Artifact: Checkout + Payment Mandates: SD-JWT verifiable credentials, hash-bound to the merchant-signed cart

Issuer: The user, signing on a non-agentic Trusted Surface

Revocation: Expiry-first: short exp claims, one-outstanding-mandate rule, signed receipts. No status list yet.

Bridges: Wraps UCP (the Checkout Mandate's checkout_jwt MUST be the UCP Checkout object); user anchor is an EMVCo digital payment credential; a2a-x402 bridges to x402

v0.2 spec public; no card network accepts AP2 mandates in live authorization yet.primary source

Mastercard Agent Pay

Walled (identity layer federated)AnnouncedMastercard (Web Bot Auth with Cloudflare)

Anyone can verify the agent's Web Bot Auth signature at the edge. But the authorization artifact only means something at Mastercard authorization; no third party can inspect it and learn what the user permitted. Mastercard's own FIDO verifiable-credentials work describes the portable version as future.

Artifact: Agentic token (network token credential), presentable as a Dynamic Token Verification Code in standard card fields; Web Bot Auth signature for agent identity

Issuer: Mastercard, after agent registration

Revocation: Programmable transaction-level controls; issuer-app revocation reported but unverified in primary sources. A relying merchant sees a decline.

Bridges: Web Bot Auth shares the RFC 9421 + Cloudflare base with Visa TAP

Announced April 2025; acceptance framework published October 2025; no named production deployment in primary sources.primary source

The bridge map

Bridge formation below the mandate layer is the leading indicator of consolidation. These already exist:

Visa TAP ↔ Mastercard Web Bot Auth	Same RFC 9421 signature base, same Cloudflare engineering partner. The rival networks' agent-identity layers are already technically interoperable.
AP2 ↔ UCP	AP2 Checkout Mandates are hash-bound to the UCP Checkout object by spec. AP2 is UCP's portability layer.
AP2 ↔ EMVCo	AP2's worked example anchors user trust in an EMVCo digital payment credential. The card networks' standards body is the trust anchor inside Google's protocol.
x402 ↔ MCP / A2A	The most portable payment payload ships transports for the most common agent protocols (x402 MCP transport, a2a-x402).
ACP ↔ PayPal / Meta	Open Apache 2.0 spec adopted beyond its authors; PayPal processes ACP tokens through Braintree.

The response

The gap this page measures is the MandateKit thesis: a mandate should be a signed, self-contained object any verifier can check, not a row in the issuer's database. MandateKit is our open-source primitive for exactly that, in Python or TypeScript. v0, experimental, honestly labeled.

mandatekit on GitHub →

Changelog

2026-06-12Tracker launched: eight rails assessed from primary specs. Verdict count at launch: 2 Portable, 4 Federated, 2 Walled.

The x402 adoption tracker — the settlement layer this page's portability question sits above.
The identity gap — the who layer, measured across the MCP ecosystem.
The population dataset — the weekly sweep behind the Major Labs scoreboards.