How can signed mandates prevent payment fraud by agents?

Google announced the Agent Payments Protocol (AP2), which it describes as "an open protocol developed with leading payments and technology companies to securely initiate and transact agent-led payments across platforms," built as an extension of the existing Agent2Agent (A2A) and Model Context Protocol (MCP) standards. Google states it is "collaborating with a diverse group of more than 60 organizations," naming Adyen, American Express, Coinbase, Etsy, Mastercard, PayPal, and others. The post frames the need plainly: "today's payment systems generally assume a human is directly clicking 'buy' on a trusted surface," and agents break that assumption, raising three questions AP2 is meant to answer — authorization ("proving that a user gave an agent the specific authority"), authenticity (that "an agent's request accurately reflects the user's true intent"), and accountability (determining fault "if a fraudulent or incorrect transaction occurs").

The mechanism is a chain of "Mandates — tamper-proof, cryptographically-signed digital contracts" backed by verifiable credentials (VCs). For a real-time purchase with the human present, an initial request ("Find me new white running shoes") is captured in an Intent Mandate, and the user's approval of the final cart signs a Cart Mandate, which Google calls "a secure, unchangeable record of the exact items and price." For a delegated task with the human absent ("Buy concert tickets the moment they go on sale"), the user signs a detailed Intent Mandate upfront specifying "price limits, timing, and other conditions," which then lets the agent generate the Cart Mandate autonomously once those conditions are met. Google says this sequence — "from intent, to cart, to payment" — produces "a non-repudiable audit trail" and is payment-method agnostic, covering cards, stablecoins, and real-time bank transfers; a companion extension, A2A x402, built with Coinbase, Ethereum Foundation, and MetaMask, extends the same constructs to crypto payments specifically.

AP2 sits one layer below the access-and-session protocols in this library: where Can a protocol split agent access from agent incentives? governs whether an agent may act on a business's website, API, or conversational channel at all, AP2 governs the narrower moment of payment authorization once access is already granted. It shares its underlying pattern with How can AI agents prove who authorized their actions? — both use a cryptographically signed credential from a human principal as proof of authorized scope — but AP2's Mandates are purpose-built for a single purchase rather than a general-purpose delegation chain. The Cart Mandate's human-approval step for real-time purchases also lines up with what Do consumers want to approve AI shopping purchases before they happen? finds consumers want, and the protocol's framing as a named, auditable trust layer speaks directly to the gap Does naming a payments brand increase trust in AI transactions? measures between assistant adoption and payment trust.

The excerpt is a vendor announcement, not an evaluation: Google names no live transaction volume, no dispute case Mandates have resolved, and no independent party assessing whether the "non-repudiable audit trail" holds up under contested or fraudulent claims. The "smarter shopping," "personalized offers," and "coordinated tasks" examples Google gives are described as commercial models AP2 "provides a foundation to support," not transactions it has processed. The accountability question AP2 is built to answer — who is liable for a fraudulent or incorrect agent transaction — is therefore still open in practice, even where the protocol specifies, in principle, whose signature should settle it.