AP2Agent Payments Protocol

What it is

AP2 is an open protocol for agent-initiated payments, published in September 2025 as an extension to the Agent2Agent (A2A) protocol and designed to sit alongside the Model Context Protocol rather than replace either. Its central construct is the mandate: a verifiable digital credential, cryptographically signed and tamper-evident, that records what a user authorised.

In v0.2 the mandates are organised into two, each with an opening and a closing stage. A Checkout Mandate is shared with the merchant: it opens with the user's goal and constraints before a cart exists, and closes as an authorisation over a finalised order. A Payment Mandate is shared with credential providers, networks and processors: it opens with the user's constraints on the instrument, and closes bound to a specific amount against a specific finalised checkout.

The protocol distinguishes human-present flows, where a person is in the loop at the moment of purchase, from human-not-present flows, where the agent acts alone against authority granted earlier. The second case is the one the protocol exists for; the first is largely served by the payments industry as it stands.

What it actually standardises

Three things. First, a data model for authorisation: what a mandate contains, how it is signed, and what it is bound to. Second, a role architecture that compartmentalises who sees what — the merchant learns the checkout, the credential provider learns the payment, and neither needs the other's view. Third, an audit trail: because every mandate is signed and tamper-evident, a dispute can be resolved by reference to objects rather than by reference to logs kept by an interested party.

That third property is the one to hold onto. Most of the failure modes people worry about with agentic payments are not really payment failures; they are evidentiary failures. The money moved, and nobody can establish afterwards on whose authority. AP2 is an attempt to make that question answerable by construction.

What it assumes about the human

AP2 assumes the human's authorisation can be captured at a moment and expressed as constraints in a credential. That is a strong assumption and mostly a reasonable one: 'up to this amount, for this purpose, in this window' covers a great deal of real delegation.

It is weaker where authority is conditional on things the credential cannot see. A user who would happily approve £400 to a supplier they have used twenty times, and would want to be asked about £400 to a supplier first seen this morning, is not expressing an amount limit — they are expressing a rule about counterparty history. A mandate can encode the outcome of such a rule at issuance time, but the rule itself, evaluated against state that changes, lives somewhere else. In practice that somewhere else is a policy engine on the delegator's side of the boundary.

Why the FIDO contribution matters

In April 2026 Google contributed AP2 to the FIDO Alliance, alongside Mastercard's Verifiable Intent, and two working groups were chartered: Agentic Authentication, chaired by CVS Health, Google and OpenAI, and Payments, chaired by Mastercard and Visa.

This changes AP2's status from 'a large vendor's protocol with many endorsers' to 'an input to a standards process run by the body that standardised WebAuthn and passkeys'. It also frames delegation as an authentication problem, which is the right frame: the question of what an agent may do is downstream of the question of how a person expresses and later proves an instruction.

The practical consequence for anyone integrating today is that the data model is likelier to survive than the wire format. Build so the mandate is a value your system produces and verifies, not a shape hard-coded through your call sites.

What it does not do

• Agent identity remains an open problem inside the protocol; AP2 can bind a mandate to a key, but establishing which real-world operator holds that key is left to other layers.
• Revocation is under-specified relative to issuance. Minting a mandate is well described; withdrawing one already in flight, and proving it was withdrawn before a given moment, is not.
• It has not been tested at card-network volume, and the flows that matter most — human-not-present, high value, disputed — are the least exercised.
• A mandate expresses constraints fixed at issuance. Conditions that depend on state at evaluation time (spend so far today, counterparty history, whether a supplier's bank details changed last night) are outside its model.

Where mnd8t sits relative to it