Google's AP2 Protocol: Building Trust in Autonomous Transactions
It's been a while since I felt giddy reading a specification. The release of Google's Agent Payments Protocol (AP2) brought back memories of my payments days—waiting eagerly for Visa and Mastercard to publish updates on network tokenization, or when Android introduced Host Card Emulation.
Here's what stood out.
What Is AP2?
The Agent Payments Protocol (AP2) is Google's ambitious attempt to create a cryptographic foundation for AI agent–initiated commerce. Released on September 16, 2025 with backing from 60+ organizations, it tackles the central trust problem:
How do we ensure secure, verifiable transactions when autonomous agents—not humans—are clicking "buy"?
From a security perspective, AP2 introduces a framework built on:
- W3C Verifiable Credentials
- Cryptographic Mandates
- Role-based access controls
Where AP2 Fits
AP2 acts as an extension layer that complements existing protocols:
- Agent-to-Agent (A2A) – for inter-agent communication and negotiation
- Model Context Protocol (MCP) – for tool and API access
- AP2 – for payment authorization and verification
Mandates at a Glance
(Three cryptographically signed mandates form the trust backbone of AP2.)
- Intent Mandate: Captures pre-authorized conditions for delegated purchases (human-not-present scenarios)
- Cart Mandate: Records explicit user approval for specific items and prices (human-present scenarios)
- Payment Mandate: Minimal credential shared with payment networks, signaling agent involvement without exposing full transaction details.
Example: Buying Nike Shoes
Here's how a user might delegate and complete a purchase using AP2.
Step-by-Step
- Intent Mandate – Alice tells her agent: "Buy Nike Air Max if price < $97." She signs this digitally.
- Mandate Credential – The agent registers it with PayPal, who countersigns, issuing a credential.
- Price Trigger – The agent monitors Nike.com. When price hits $96, it alerts Alice.
- Cart Mandate – Alice approves the specific cart at $96 and signs again.
- Execution – Agent submits both mandates to PayPal.
- Settlement – PayPal processes payment with Nike.
- Receipt – PayPal signs and returns an auditable receipt to Alice.
⚠️ Note: This example is for illustration only. Actual implementations (e.g., PayPal, Stripe, or card networks) may differ in the details of how mandates are represented, validated, or countersigned. The important part is the pattern: user-signed mandates, provider validation, and cryptographic receipts.
What Happens If Agents Exceed Their Authority?
If an agent attempts to purchase beyond its mandate constraints (say, trying to buy at $105 when authorized only up to $97), the payment provider automatically rejects the transaction and logs the violation. This creates an immediate audit trail and prevents unauthorized spending while maintaining the user's control.
Strengths
- Cryptographic Foundation – Robust use of established standards (W3C VCs, COSE)
- Defense in Depth – Multiple layers, from mandate constraints to provider validation
- Audit Trail – Complete cryptographic chain of custody for dispute resolution
- Industry Collaboration – Backed by 60+ partners, ensuring diverse perspectives
Areas of Concern
- Key Management Complexity – Users must manage signing keys securely
- Trust in Execution Environments & Agent Identity – How do we know an agent isn't compromised? (Hint: I'll explore why Confidential Computing fits here in a follow-up post.)
- Cross-Platform Consistency – Security depends on the weakest implementation in the ecosystem
Why It Matters
- Agents get bounded, verifiable authority — not free rein
- Providers enforce user intent, not just payment details
- Every mandate and receipt creates tamper-proof auditability
- This could be the blueprint for how we let AI agents transact safely at scale
You can find the specification at github.com/google-agentic-commerce/AP2