AP2: The Trust Layer for Agent Transactions
When an AI agent spends money on your behalf, how do you prove you authorised it? Google’s Agent Payments Protocol gives every agent transaction a signed record of intent. What it means for businesses that sell, buy or underwrite, and what to do now.
Cameron Mukherjee, Director · · Updated
For: Financial institutions, payment providers and platforms that need proof of authorisation for agent transactions
Key points
- The Agent Payments Protocol (AP2), developed by Google with more than 60 partners, provides cryptographic proof that an agent’s purchase reflects the user’s intent.
- AP2 uses signed Mandates (intent, cart and payment) expressed as W3C Verifiable Credentials to create a non-repudiable audit trail.
- The protocol supports human-present and human-not-present (delegated) transactions.
- AP2 is payment-agnostic across cards, bank transfers, wallets and stablecoins, and integrates with x402 for on-chain settlement.
Part 2 of our three-part series on the agentic commerce stack, written for directors who need to know what changes when an AI agent spends money on a business's or a customer's behalf. Part 1 covered ACP, the checkout layer. Part 3 covers x402, the settlement layer.
In one paragraph
When an AI agent buys something on your behalf, how do you prove you authorised it, and how does the merchant, the bank and the card network know the agent was not acting alone? That is the question the Agent Payments Protocol (AP2) answers. Developed by Google with more than 60 partners including Mastercard, PayPal, American Express and Coinbase, AP2 gives every agent transaction a signed, tamper-evident record of what the person authorised. For a business, that is the difference between an agent you can give a budget to and one you cannot.
Why proof of intent matters
Every payment system today assumes a person clicked "buy" on a trusted screen. That click is the authorisation, and everything from 3D Secure to fraud detection is built on it. As Google's announcement puts it, "the rise of autonomous agents breaks this fundamental assumption."
Without a common standard, three questions have no good answer: did the user actually permit this specific purchase; does the transaction reflect real intent or an agent's error; and if it goes wrong, who is accountable, the user, the agent platform or the merchant? Fragmented, proprietary answers would mean confusion for customers, operational complexity for banks and higher fraud exposure for everyone.
How it works, for a non-engineer
AP2's core idea is the mandate: a digitally signed record of what a person authorised, expressed as a W3C Verifiable Credential so any participant can verify it without calling a central authority. There are three:
- Intent mandate: the instruction. "Find white running shoes under £150 and buy them if you find a good price." It records merchant restrictions, price limits, time windows and payment method categories, before any transaction happens.
- Cart mandate: the specific purchase. Generated by the merchant from the user's selections and signed by the user, usually with a hardware-backed key on their device. It fixes items, price, currency and destination, and carries the risk signals merchants and issuers need. According to PayPal's analysis, it provides non-repudiable proof that this person approved this cart at this price.
- Payment mandate: a minimal credential for the card network or issuer, showing that an agent was involved and whether the person was present, without exposing card or personal data.
The chain runs intent, then cart, then payment, then settlement proof, each step signed and linked. If a dispute arises, the chain shows who authorised what.
AP2 supports two modes. Human-present: the person reviews and signs the cart in real time, equivalent to clicking buy but with a cryptographic record. Human-not-present: the person signs a detailed intent mandate up front ("buy the concert tickets the moment they go on sale, up to £200 each, maximum four") and the agent executes later within those bounds. The second mode is what turns an agent from an assistant into something that can be delegated a budget.
Security rests on standard primitives: ECDSA signatures, hardware-backed keys, and replay protection, as set out in the Cloud Security Alliance's review. Responsibilities are split across roles so that raw payment credentials never flow to the agent or the merchant unnecessarily.
How it fits with everything else
AP2 is designed to work with, not replace, the surrounding protocols. It is a payment extension to Google's Agent2Agent (A2A) protocol, it integrates with Anthropic's Model Context Protocol, and through the A2A x402 extension it connects to stablecoin settlement. The card networks are aligning with it: Visa's Trusted Agent Protocol for agent identity at the merchant, Mastercard's Agent Pay for trusted-agent recognition and agentic tokens, and Cloudflare's Web Bot Auth, built with Microsoft, Shopify, Checkout.com, Worldpay and Adyen, for cryptographic agent identity at the network edge.
| When | What |
|---|---|
| April 2025 | Mastercard Agent Pay launches |
| 16 September 2025 | Google announces AP2 with 60+ partners |
| 29 September 2025 | ACP launches with ChatGPT Instant Checkout |
| October 2025 | Visa Trusted Agent Protocol and Cloudflare Web Bot Auth announced |
Partners span payment networks (Mastercard, American Express, JCB, UnionPay), processors (Adyen, PayPal, Worldpay, Checkout.com, Revolut), platforms (Salesforce, ServiceNow, Intuit) and crypto infrastructure (Coinbase, Ethereum Foundation, MetaMask). PayPal's implementation plan embeds mandates in its existing payment flows and fraud engines and its seller-protection process.
AP2 is payment-agnostic: the same mandate framework covers cards, bank transfers, wallets and stablecoins. That is why it is the universal trust layer while ACP is currently Stripe-centric and x402 is stablecoin-focused.
What this means for your business
- If you sell: AP2-backed orders arrive with cryptographic proof of authorisation, which reduces dispute exposure and gives you evidence if a chargeback is raised.
- If you buy: agents can be given bounded spending authority, with the record to satisfy your finance and audit functions. This is the prerequisite for automated procurement, expense handling and supplier payments.
- If you are in financial services: the mandate chain is the audit trail regulators, fraud teams and dispute processes will expect for agent transactions, and the mechanism for underwriting them.
- For any regulated business: the same properties, signed intent, bounded authority and a replayable record, are what the EU AI Act and your auditors ask of any automated decision. Getting them right for payments is a template for the rest.
What to do now
- Decide which processes an agent could be delegated with a budget, and what the bounds would be.
- Ask your payment provider and bank about their AP2 timetable and what agent-presence signals will mean for your fraud rules.
- Design the approval step: what an agent may do alone, what needs a person, and how both are recorded.
- Treat the mandate record as an audit asset and plan where it is stored and for how long.
How Hexploits helps
We build agentic workflows with exactly these properties: policy on every action, approvals for consequential steps and an immutable log. We built the platform that does this for enterprises, swarmd.ai, and we implement identity and access so that agent authority is scoped and revocable.
Request a proposal or talk to an engineer. You will have a written scope and an indicative price within two working days.
Continue to Part 3: x402, the settlement layer, or revisit Part 1: ACP, the checkout layer.
Questions this raises
What is AP2?
What is a mandate in AP2?
How does AP2 relate to ACP and x402?
How Hexploits helps
- Agentic AI workflows with governance
An agentic workflow is an AI system that carries out multi-step tasks by calling your systems and tools, rather than only answering questions.
- Identity and access management
Identity and access management controls who can reach which systems, with what permissions, and what happens when they join, move or leave.
More insights
EU AI Act High-Risk Series, Part 5: Critical Infrastructure
11 September 2026
AI managing power grids, water supply or road traffic is high-risk under the EU AI Act only where it is a genuine safety component, and part of the scope test is still draft guidance. How utilities, operators and their vendors should classify, and what to build if they are in scope.
EU AI Act High-Risk Series, Part 4: Healthcare & MedTech
4 September 2026
Healthcare AI has two EU AI Act deadlines eight months apart, and which applies depends on whether your product is legally a medical device. How to classify correctly, what goes in the technical file, and why health-system procurement is already asking.
EU AI Act High-Risk Series, Part 3: Education & EdTech
28 August 2026
Admissions, grading and exam-monitoring tools are high-risk under the EU AI Act, and emotion recognition in proctoring is banned outright. What universities, exam boards and EdTech vendors have to build by December 2027, and why institutional buyers are already asking.
Next step
Have a question this raised?
Tell us about the system and the sector. A named engineer replies within one working day. A written scope and an indicative price within two working days of a short scoping call.