AP2 becomes the trust layer for AI agent commerce

From chatty helpers to accountable buyers

AI agents are crossing a line that changes everything. They no longer just recommend sweaters or suggest flights. They can place orders, move money, and complete checkout while you are busy elsewhere. That shift breaks long‑standing assumptions in payments. Who clicked buy. What did the user actually authorize. Who bears the loss if something goes wrong.

Google’s new Agent Payments Protocol, or AP2, is the first serious attempt to answer those questions with a shared technical playbook rather than a closed product. In Google’s framing, AP2 is an open, payment‑agnostic set of rules and data objects that lets agents prove intent, bind that intent to a specific cart, and carry those proofs through to authorization on any rail. The announcement and early design give a clear signal: the future of agent commerce needs a trust substrate that all parties can rely on, not yet another isolated checkout widget. See Google’s overview for the canonical description of AP2’s purpose and building blocks in “Powering AI commerce with the new Agent Payments Protocol (AP2)” on the Google Cloud blog. Read Google’s AP2 announcement.

This piece goes deeper into how AP2’s cryptographically signed Mandates and verifiable credentials work, what they mean for merchants, PSPs, wallets, and regulators, how to build against them safely, and how AP2 fits next to agent‑interoperability efforts and competitive moves.

Mandates and verifiable credentials: the heart of AP2

AP2 introduces a simple idea that does a lot of work. Every meaningful step in an agent‑driven purchase is captured as a cryptographically signed object called a Mandate. Mandates are expressed as verifiable credentials, which means they are tamper‑evident, signed by a known party, and portable across systems that understand the schema.

Two Mandates matter most for retail scenarios:

Intent Mandate. A signed record of what the human instructed the agent to do. Think of it as the evidence of consent. It can include constraints like budget ceilings, time windows, product categories or SKUs, refundability rules, and the fact that the human may not be present when execution occurs. The signature binds the user’s credentials to the instruction.
Cart Mandate. A signed record of the specific items, price, merchant, and totals to be purchased. It is what translates the human’s intent into a concrete basket that a merchant can fulfill and that the payments ecosystem can underwrite.

AP2 chains these Mandates. An Intent Mandate that says buy two concert tickets up to 120 dollars each can be used by the agent to seek offers. Once the exact seats and price are found, the agent presents a cart for approval. The human approves and the Cart Mandate is generated. The chain creates a non‑repudiable trail from instruction to itemized purchase.

On the payment side, AP2 adds a Payment context that can be shared with issuers and networks in a privacy‑preserving way. The key idea is visibility without leakage. The issuer learns that an agent acted on an authorized mandate, along with risk signals needed for decisioning, without receiving the user’s prompts or unrelated personal data.

One protocol, many rails: cards, instant bank transfers, and stablecoins

AP2 is payment‑agnostic by design. The Mandate chain attaches to different payment instruments without rewriting the rules:

Card rails. The merchant or PSP submits the authorization as usual, but includes AP2 metadata that signals an agent‑initiated purchase and references the Mandate chain. This gives issuers a new, auditable signal that the cardholder consented to the exact cart contents.
Instant bank rails. Real‑time payment systems favor push payments initiated by the payer. AP2’s Intent plus Cart flow maps well here. The Mandate can drive a request‑to‑pay message or a push transfer, while preserving a verifiable audit trail.
Stablecoins. AP2’s data model can ride on top of crypto transfers by producing a signed instruction and binding it to a transaction on chain. The benefit is the same: verifiable consent and cart specificity carried alongside the payment.

The unifying point is not which rail moves the money. It is how AP2 binds human intent to agent action and then to the actual funds movement in a way everyone can check later.

Why this matters to each stakeholder

Merchants. AP2 offers a way to accept agent orders without giving up control of liability. You can verify that a Cart Mandate matches what the human approved, reduce false declines by sending better signals to your PSP and issuer, and create clearer dispute evidence. You also unlock new demand from agent shoppers who operate outside your current UI.
PSPs and gateways. AP2 becomes an enrichment layer for risk and authorization messaging. You ingest Mandates, validate signatures, extract risk payloads, and normalize them into existing auth and clearing formats. That helps issuers trust agent transactions and helps you differentiate your risk services for merchant customers.
Wallets and identity providers. AP2 assumes strong keys and a place to store verifiable credentials. You become the Credential Provider that issues or manages user identities, keys, and signing flows. This aligns with the view that identity is the control plane, and it is an opportunity to make hardware‑backed signatures routine.
Regulators and auditors. AP2 creates durable records of consent and content. The chain from Intent Mandate to Cart Mandate to payment can be inspected, redacted where required, and tied to controls like time‑to‑live and spend limits. That improves consumer protection, auditability, and harmonization with accountability regimes seen in the bank-grade agent tipping point.

Fraud, chargebacks, and consent in an agent world

Fraud pressure rises when software buys on our behalf. AP2’s answer is to turn fuzzy intent into signed, checkable evidence. Teams should also account for takeover and prompt‑level risks that escalate as agents gain purchase authority, which is why agent hijacking is the gating risk.

Friendly fraud and disputes. Dispute reason codes can now be evaluated against a Mandate chain. Did the Cart Mandate match what shipped. Was the user present. Was the TTL expired. That makes chargeback adjudication less guesswork and more record‑driven.
Account takeovers. ATO becomes harder when approvals require keys the attacker does not control. Step‑up challenges can be bound to the Mandate itself, not just to a session.
Merchant risk models. The Mandate includes a compact risk payload. Merchants and PSPs can pack device, reputation, or velocity signals without leaking raw personal data.
Consent revocation. The user can revoke an Intent Mandate for scheduled or recurring actions. That revocation becomes a signed event that agents and merchants must honor, reducing dark‑pattern risk.

Design patterns and guardrails when you build on AP2

Treat AP2 as a trust protocol first and a payments protocol second. The patterns below keep the human in charge and the audit trail intact.

Human‑present vs human‑not‑present

Human‑present pattern: Capture an Intent Mandate when the user asks the agent to find something, then require explicit approval that creates a Cart Mandate. TTL should be short. If the cart changes, the signature must be renewed.
Delegated pattern: For background buying, capture a rich Intent Mandate with guardrails such as price ceiling, brand allowlist, timing window, quantity, cancellation policy, and refund rules. The agent can later mint the Cart Mandate within those constraints.

Price and scope guards

Hard limits: Budget ceiling, SKU list or category filter, merchant allowlist. If discovery finds a slightly different item or higher price, the agent must ask for a new signature.
Soft preferences: Preferred shipping speed, color, or refundability. These do not authorize spend by themselves and must not be used to bypass limits.

Step‑up challenges

Design for step‑up that is bound to the Mandate. The challenge response should sign the same payload the Mandate will contain. Use hardware‑backed keys where available. For risky changes, elevate again.

Privacy by construction

Minimize what travels. Pass only the risk signals a counterparty needs. Keep user prompts and summaries local unless the user explicitly authorizes sharing. Redact optional fields by default.
Rotate keys and support selective disclosure. If a single field changes, avoid re‑sharing the entire history.

Safe failure and dispute hooks

Always emit a machine‑readable reason when the agent declines to buy or when a counterparty rejects a Mandate. Bind refund and cancellation tokens to the Cart Mandate so the merchant can automate returns.

Observability

Emit signed, append‑only logs for each state transition: Intent created, offer evaluated, Cart created, payment submitted, fulfillment confirmed. Keep them hash‑chained so you can prove ordering without leaking content.

Red teams and chaos drills

Treat agents like high‑privilege software. Run adversarial tests. Fuzz Mandate fields. Simulate network partitions and partial failures, then verify that agents do not silently widen scope or spend.

How to build against AP2 step by step

Pick your role. Merchant agent, shopping agent, PSP adapter, or wallet provider. Your responsibilities differ. Merchant agents validate Mandates and produce payment requests. Shopping agents gather offers and orchestrate Cart approvals. PSP adapters translate AP2 context into auth and clearing messages. Wallets provide identity, signing, and key management.
Implement identity and keys. Use a strong identity for the user and the agent. Generate hardware‑bound keys when possible. Your Credential Provider issues the verifiable credentials that let you sign Mandates.
Integrate an agent messaging layer. AP2 is most effective when agents can talk to other agents. The Linux Foundation’s Agent2Agent project is becoming the neutral home for this messaging, and AP2 can sit on top for payment semantics. See the Linux Foundation’s announcement of A2A for the direction of travel. Review the A2A project launch.
Create an Intent Mandate flow. Define the schema you need. Include constraints, an expiration, and a clear text playback of the user’s instruction for transparency. Present a concise approval screen and sign with the user’s key.

Build offer evaluation. Your shopping agent should fetch offers that satisfy the Intent. Keep deterministic reasoning on what qualifies. Record which offers were considered and why they passed or failed the constraints.

Generate the Cart Mandate. When the human approves the exact cart, sign a Cart Mandate that includes merchant identity, items, price, and totals. Bind it to the Intent via a reference so the chain is complete.
Attach payment context. Choose the rail. For cards, include AP2 flags in the authorization request so issuers can treat agent purchases distinctly. For bank transfers, generate a request‑to‑pay or push instruction scoped by the Cart Mandate. For stablecoins, bind the on‑chain transaction hash to the Cart Mandate and publish a receipt that references both.
Handle step‑ups and reversals. If a counterparty asks for more assurance, trigger a contextual step‑up bound to the same Mandate payload. If the user cancels or a refund is due, emit signed reversal tokens referencing the Cart Mandate.

Reconcile and store the audit trail. Keep signed logs and receipts. Build dashboards that let support teams answer a simple question fast: what did the user authorize, what did the agent do, and what shipped.

The trust layer arrives

We are quickly leaving the demo phase of agent commerce. Real money, real refunds, and real disputes are here. AP2’s contribution is not a new checkout button. It is a common language for consent, specificity, and accountability that works regardless of how money moves. Adopt it and you get a durable audit trail. Ignore it and your agents will remain untrusted, siloed, and hard to scale.