Researchers find 48 threats in Google's agent payment protocol

Google's Agent Payments Protocol lets AI agents complete purchases with a signed Payment Mandate standing in for the user's authorization. A new analysis of AP2 v0.2 finds that signature covers less than it looks like it does.

The paper models AP2 across five lifecycle phases and five deployment architectures using the MAESTRO threat framework, and catalogs 48 distinct threats scored with AIVSS. Eight land in the High severity band in at least one architecture.

The structural problem is where the protection starts. AP2's signed Checkout and Payment Mandates lock in transaction data once they're signed. But the A2A messages and MCP tool calls that build that transaction beforehand, the steps where an agent decides what to buy and for how much, sit outside the signature entirely. A valid signature proves someone signed off on a mandate. It doesn't prove the mandate reflects what the user actually asked for, because nothing upstream of the signing step is protected.

The authors didn't just theorize the gap. They built a testbed spanning all five architectures and five proof-of-concept demos, one for each High-severity threat, plus a scanner that checks deployments against static, cross-role consistency, and adversarial tests.

For anyone wiring agents into a payment flow, the lesson is specific: the signature check on a mandate tells you it wasn't tampered with after signing. It tells you nothing about whether the pre-authorization conversation was manipulated. Teams building on AP2 or protocols like it need to validate the request-shaping steps, not just the final signed artifact, and the paper's scanner is a starting point for what that validation should look like.