Beyond the Mandate: A Systematic Security Analysis of the Agent Payments Protocol (AP2) | AI Paper Digest

TL;DR Highlight

Catalogs 48 AP2 threats: validly signed mandates can still carry unintended payments

Who Should Read

Backend developer building LLM shopping or payment agents with A2A and MCP, relying on signed mandates for authorization

Core Mechanics

A valid signature can still mean wrong intent
- AP2 protects the integrity of signed mandates only.
- Catalog data, tool results and A2A messages before signing sit outside that protection.
- Manipulating context alone yields a valid mandate without any forgery.
48 threats, 8 rated High
- MAESTRO produced 48 threats in five attack families.
- AIVSS rated 8 as High in at least one architecture.
- Threats change with architecture: single agent, MCP, marketplace and so on.
Shared MCP amplifies risk
- If merchant and shopping agents share one MCP server, one compromise reaches both sides.
- The demo chains a tool-name collision that leaks context into calls to CP-reserved operations.
One character in a URI causes a downgrade
- Loose matching of the extension URI accepts a look-alike with protoco1 instead of protocol.
- The session silently drops to v0.1 and loses replay defenses.

Evidence

Only 66.7% overlap with STRIDE-GPT
- Five STRIDE-GPT runs produced 124 rows.
- 32 of 48 catalog threats (66.7%) mapped as Full or Partial.
- The other 16 were all judged Distinct by annotators.
Eight experts reproduced the severity bands
- Gwet's AC2 was 0.984 over 25 threats (95% CI 0.963–1.000).
- Krippendorff's alpha was 0.802 with CI 0.520–0.978.
- They matched the single-rater reference band in 111 of 120 ratings (92.5%).
Scanner recall varied by layer
- The Full configuration reached A2 .80, A3 .60, A4 .50, A5 1.00.
- On A2, Only-Passive scored .60 and Only-CDSE .00.
- No layer subsumed the others, and T-2, T-1, T-9 and T-3 were missed by all.
Worked score example for T-1
- CVSS base 8.3 and AARS 6.5 give AIVSS 7.2 (High).
- Replay T-31 scored 6.3 in A1 and 6.7 in A3.

How to Apply

Switch extension URI checks to exact match
- Today, find the SA's AgentCard extension URI check and replace loose matching with a pinned exact value.
- Abort the transaction on mismatch instead of falling back to legacy.
Move risk_data inside the signature
- Remove mutable fields the SA attaches; accept only data inside the signed Payment Mandate or a TS-issued signed attestation.
- Make CP and MPP reject unsigned risk payloads.
Enforce limits with policy outside the model
- Move amount-ceiling and payee-restriction escalation rules into versioned deterministic code.
- Have the TS render the exact amount_range.max and the absence of payee restrictions, and sign only the bytes it rendered.
Bind MCP servers and caller roles
- Pin each tool to one answering server at session start and reject name collisions.
- Attach a signature over caller, role and transaction ID to every MCP call, and have the CP authorize on it rather than on the transport channel.

Try It

copy & run

# Paste into Claude or ChatGPT (simplified version of the paper's method: AP2 threat review prompt)

Our payment agent setup is as follows.
{{Architecture description: single or multi SA/MA, MCP used or not and shared or not, marketplace or not}}

Review it from these angles.
1. List every path by which input the SA receives before signing (catalog, tool results, A2A messages) can influence mandate fields.
2. For each path, say whether manipulation could change the amount ceiling, payee restriction or risk_data.
3. For each item, propose one defense: exact-match validation, signature binding, or policy enforcement outside the model.

Next step: pick the riskiest path and write a test case for it.

Terminology

MandateA signed document recording the payment authority a user gave an agent. Think of a stamped power of attorney.

Human-Not-Present (HNP)A mode where the user leaves and the agent pays automatically within limits approved in advance.

MAESTROA threat-modeling framework that splits multi-agent systems into seven layers to find threats.

AIVSSA scoring method that adds agent-specific amplification factors (AARS) to CVSS to rate AI vulnerabilities.

AgentCardAn A2A document listing an agent's identity, endpoints and capabilities, like a business card. It is unsigned by spec.

Related Papers

Related Resources

https://anonymous.4open.science/r/AP2_Beyond_the_Mandate

Original Abstract (Expand)

The Agent Payments Protocol (AP2), introduced by Google, enables large language model (LLM)-driven shopping agents to authorize and execute payments on behalf of users. Its signed Checkout and Payment Mandates protect the integrity of transaction data after signing. Agent interactions and external inputs that shape a transaction before authorization remain outside that protection, including Agent-to-Agent Protocol (A2A) messages and Model Context Protocol (MCP) tool calls. Prior work identified replay and prompt-injection attacks in AP2 v0.1. AP2 v0.2 addresses some of these issues but adds capabilities and deployment assumptions that require renewed analysis. We present a systematic security analysis of AP2 v0.2 based on its roles, transaction lifecycle, deployment architectures, and trust boundaries. We divide the lifecycle into five phases and identify five deployment architectures. Using MAESTRO (Multi-Agent Environment, Security, Threat, Risk, Outcome), we model four threat actors, eleven attack surfaces, eighteen adversary capabilities, and six attacker goals. The resulting catalog contains 48 threats spanning five attack families. We score these threats with the Artificial Intelligence Vulnerability Scoring System (AIVSS), identifying eight that reach the High band in at least one architecture. Because no complete public AP2 deployment was available, we build a testbed spanning all five architectures and develop five proof-of-concept demonstrations covering all eight High-risk threats and their mitigations. We also develop a deployment-aware scanner that maps applicable threats to static, cross-role consistency, and adversarial checks. Our analysis shows that valid mandate signatures alone do not ensure that an agent-mediated transaction reflects the user's intent when its pre-authorization context is manipulated.