PaperlayerView exact revision on arXiv

Source-linked AI summary

Beyond the Mandate: A Systematic Security Analysis of the Agent Payments Protocol (AP2)

Avital Aviv, Parth A. Gandh, Ron Bitton, Asaf Shabtai

arXiv:2608.23858v1cs.CRcs.AI

TL;DR

AP2’s signed mandates leave agent interactions and external inputs that shape transactions before authorization outside their protection. The paper analyzes AP2 v0.2 across lifecycle phases, deployment architectures, and trust boundaries using MAESTRO, AIVSS, a testbed, proof-of-concept attacks, and a scanner. It catalogs 48 threats, identifies 8 High-risk threats, and demonstrates attacks and mitigations while showing that valid signatures alone do not ensure user intent.

  • Problem

    AP2 protects signed transaction data after authorization, but pre-authorization A2A messages, MCP tool calls, and other external inputs remain outside that protection.

  • Method

    The paper models AP2 v0.2 across five lifecycle phases and five deployment architectures using MAESTRO, AIVSS, a custom testbed, proof-of-concept attacks, and a deployment-aware scanner.

  • Results

    48 threats are cataloged, 8 reach the High band in at least one architecture, and five demonstrations cover all eight High-risk threats and their mitigations.

  • Takeaways & Limitations

    Valid mandate signatures alone do not ensure that an agent-mediated transaction reflects user intent when its pre-authorization context is manipulated.

  • Takeaways & Limitations

    Because no complete public AP2 deployment was available, the testbed cannot establish that the same failures will appear unchanged in future third-party deployments.

Abstract

from arXiv · show

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.

1 Introduction

AP2 v0.2 is analyzed because signed mandates protect post-signing data but not the agent interactions and external inputs that shape transactions beforehand. The paper develops a lifecycle- and architecture-spanning threat analysis, testbed demonstrations, mitigations, and a deployment-aware scanner.

  • AP2 supports LLM-driven agents that browse catalogs, assemble carts, and execute payments for users without human approval at every step.
  • Pre-signing catalog data, tool results, and A2A messages remain outside AP2’s signed mandates, so attackers can manipulate transaction formation without forging mandates or receipts.
  • The paper segments AP2 transactions into five phases, identifies five deployment architectures, and maps threats using MAESTRO and AIVSS.
  • Five proof-of-concept demonstrations cover all eight High-risk threats and their mitigations, while a scanner selects deployment-specific checks and reports findings.
  • 48 threats are cataloged across five attack families, with 8 reaching the High risk band in at least one architecture.

2 Related Work

Prior work examined components of AP2, MCP, A2A, and agentic-commerce security, but did not systematically analyze how those risks propagate into AP2 v0.2. This paper addresses that gap with a comprehensive threat model, proof-of-concept demonstrations, mitigations, and a scanner.

  • Earlier studies found prompt-injection, replay, and context-binding flaws in AP2 v0.1 despite signed mandates.
  • Existing agentic-commerce work mapped recurring attack classes, but no protocol fully ensured both authorization integrity and settlement accountability.
  • MCP research identified tool poisoning and shadowing, while A2A research examined authentication, authorization, integrity, confidentiality, and availability.
  • The paper examines how supporting-protocol vulnerabilities propagate into AP2 and consolidates the findings into a security scanner for implementers.

3 AP2 Transaction Lifecycle & Architectures

AP2 defines five roles, signed mandate artifacts, two authorization modes, and five analytical lifecycle phases. The paper refines these abstractions for threat modeling by distinguishing deployment architectures and their trust boundaries.

  • Roles and artifacts: AP2’s five roles are the Shopping Agent, Merchant, Credential Provider, Merchant Payment Processor, and Trusted Surface.
  • Roles and artifacts: Checkout and Payment Mandates have open and closed forms, with hashes binding closed mandates to the merchant-signed checkout.
  • Authorization modes: Human-Present users approve closed mandates directly, whereas Human-Not-Present flows use open mandates and autonomous signing by the Shopping Agent.
  • Lifecycle phases: The five analytical phases cover preparation, context formation, mandate formation and authorization, verification and consumption, and evidence retention; they are not a shared chronology.
  • Deployment architectures: Five architecture classes capture distinct trust boundaries, shared state domains, tool-execution surfaces, or compromise paths reaching different AP2 roles.
  • Deployment architectures: A5 gives the Shopping Agent and Merchant the same MCP server, allowing a compromised server to influence both sides of one transaction.

4 Threat Model

The threat model represents attacks through actors, surfaces, capabilities, and goals, and assigns threats according to deployment-specific permissions and trust boundaries. It distinguishes access capabilities needed to realize attacks from knowledge capabilities that affect attack complexity or success probability.

  • Each threat is a tuple of initiating actor, attack surface, capability, and attacker goal, with phase applicability recorded separately.
  • MAESTRO supplies seven layers spanning foundation models, data operations, agent frameworks, infrastructure, observability, security and compliance, and the agent ecosystem.
  • The notation identifies five architectures, five phases, eleven surfaces, four threat actors, six goals, and numbered access and knowledge capabilities.
  • Access capabilities describe what an attacker can read, write, invoke, or control, whereas knowledge capabilities only reduce complexity or increase success probability.
  • Compromising a shared A5 MCP server can combine permissions across the Shopping Agent and Merchant, making architecture-specific analysis necessary.
  • The four actor categories are User, Merchant, Developer or Operator, and External Attacker, with malicious behavior attributed to actors rather than surfaces.

4.3 Attack Surfaces

AP2’s security analysis identifies 11 attack surfaces across roles and runtimes, communication channels, and data or artifacts. The applicability and scope of the MCP channel depend on the deployment architecture.

  • 11 attack surfaces are organized into role and runtime, communication-channel, and data-and-artifact categories.
  • The S9 MCP channel is absent in A1, pure A3, and pure A4, but isolated or shared in other architectures.
  • Architecture determines whether S9 threats apply and whether their scope remains single-sided or spans both sides.

4.4 Attacker Goals

The threat model organizes AP2 attacks around six attacker goals, covering unauthorized or manipulated payments, authorization overreach, confidentiality loss, repudiation, and denial of authorized payment.

  • Six attacker goals organize threats according to the security objective they violate.
  • Unauthorized Payment targets settlement without valid corresponding authorization, including payments with altered amounts, merchants, or instruments.
  • Mandate-Content Manipulation obtains a valid signature over semantics differing from user intent, rendered views, or pre-authorized constraints.
  • Authorization-Scope Inflation extends a legitimate authorization after signing through replay, reuse, or rebinding.
  • Confidentiality Breach, Repudiation, and Denial of Authorized Payment respectively concern disclosed claims or metadata, transaction evidence, and completion of authorized transactions.

4.5 Risk Assessment

Risk is scored separately for each applicable deployment architecture by combining protocol-level CVSS severity with agentic amplification factors under AIVSS. The assessment identifies eight threats reaching the High band, with architecture affecting which threats become high risk.

  • Risk applies only when a threat’s architecture exposes its required surface and its preconditions hold.
  • AIVSS combines CVSS v4.0 base severity with ten AARS amplification factors covering agentic properties such as autonomy, tools, memory, and multi-agent interaction.
  • ThM is set to 0.97 for PoC-based assessment, while MF is set to 1.0 to rank inherent risk before deployment controls.
  • 8 threats reach the High band, summarized with their CVSS base scores, AARS profiles, and final AIVSS scores.
  • T-31 has AIVSS = 6.3 in A1 from CVSS_base = 8.9 and AARS = 4.0, while concurrent fan-out in A3 activates multi-agent amplification.
  • The A1 baseline is dominated by F3 trust-root and F4 state-binding threats, whereas A5 amplifies the largest number of F1 threats.

5 Taxonomy of AP2 Attack Families

The paper organizes 48 AP2 threats into five attack families based on the security object whose corruption first breaks protocol guarantees. The taxonomy distinguishes semantic, authority, trust-root, state-binding, and accountability failures while retaining phases, actors, surfaces, capabilities, and goals for analysis and scoring.

  • Five attack families map threats to corrupted security objects: Semantic Manipulation, Authority Spoofing, Supply-Chain & Trust-Root Subversion, State-Binding Failures, and Accountability Failures.
  • The taxonomy assigns multi-object threats to the object whose initial corruption first breaks AP2’s guarantees.The paper classifies a poisoned shared-MCP tool result under Semantic Manipulation because contextual corruption diverts mandate construction before downstream state leakage.
  • Semantic Manipulation: Semantic Manipulation includes prompt, tool-result, mandate-content, and cross-agent attacks that can alter user-intended authorization.Examples include adversarial content, over-broad mandate construction, rendered-versus-signed divergence, and semantic collusion.
  • Authority Spoofing: Authority Spoofing covers signing-key control and authority-binding gaps that prevent AP2 from proving the correct principal produced or approved an action.A valid signature establishes key use, but not that the identified principal actually approved the action.
  • Supply-Chain & Trust-Root Subversion: Supply-Chain & Trust-Root Subversion covers unintended code, model, prompt, infrastructure, discovery, and channel identities entering trusted AP2 roles.The taxonomy separates software provenance, discovery trust, and mid-session channel or tool identity failures.
  • Accountability Failures: Accountability Failures leave incomplete evidence chains or hide the principal responsible for transaction-shaping behavior.The family includes dispute-evidence gaps, marketplace fronting, and multi-tenant isolation failures.

6 Attack Demonstrations and Mitigations

The paper presents five proof-of-concept attack demonstrations and mitigations covering all eight high-risk AP2 threats. The demonstrations include chained attacks and isolated threats across discovery, authorization, shared-MCP, risk-data, and extension-handling scenarios.

  • Five demonstrations together cover all eight high-risk threats and their mitigations; two demonstrations are multi-threat chains and three isolate one high-risk threat each.
  • AM1: Authorization Beyond Stated Intent: AM1 chains prompt drift, poisoned tool results, and mandate manipulation to obtain broader payment authority than the user intended.Its mitigation pins tool schemas, uses typed mapping, renders exact signed constraints, and rejects unauthorized limits or missing restrictions.
  • Shared-MCP attacks: The shared-MCP demonstration addresses tool confusion and caller-role confusion with session-fixed tool bindings, application-layer signatures, and transaction-scoped capability tokens.
  • AM3: Cross-Tenant Credential Theft: AM3 demonstrates cross-tenant credential theft against a shared Credential Provider serving multiple merchant programs.
  • The demonstrations also cover AP2 extension-URI downgrade and unsigned risk_data parameter poisoning as distinct attack scenarios.The listed mitigations require authenticated or exact extension handling and signed, schema-conforming risk data from an authorized source.

7 The AP2 Security Scanner Tool

The AP2 security scanner profiles a deployment, filters the threat catalog to applicable threats, and runs static, cross-role, and adversarial checks against implementation evidence. It reports findings across roles, tools, verifier logic, and protocol surfaces.

  • The scanner derives a deployment profile, selects threats whose architecture and surface requirements match it, and executes threat-specific checks for each retained threat.Checks include per-request role-bound authorization for MCP tools and restrictions on AP2 control fields crossing open schema boundaries.
  • Its checks span static source analysis, cross-role specification comparison, and targeted runtime adversarial probes.The Cross-Role Differential Specification Evaluator compares schemas, mandate fields, and accepted tool schemas across SA, MA, CP, and MPP roles.

8 Evaluation

The evaluation tests catalog coverage, AIVSS severity reproducibility, and scanner-layer contributions using structured comparisons, independent raters, and ablation on a controlled AP2 testbed. Results show partial coverage by STRIDE-GPT, strong agreement on severity bands, and complementary scanner layers, with some threats remaining undetected.

  • Three research questions evaluate catalog coverage, reproducibility of AIVSS severity bands, and the contribution of scanner layers.
  • RQ1: Threat Catalog Comparison: Five frozen STRIDE-GPT runs produced 124 rows; 32 of 48 catalog items received Full or Partial coverage, yielding 66.7% coverage.All 124 generated rows mapped to at least one catalog item, so none qualified as a candidate addition.
  • RQ1: Threat Catalog Comparison: 16 None catalog items were ultimately labeled Distinct, with annotators agreeing on 15 of 16 initial judgments.The final labels were 16 Distinct, zero Overlap, and zero Unsupported.
  • RQ2: Risk Assessment Reproducibility: Eight independent participants rated 25 threats using CVSS v4.0 and AARS factors, and agreement was measured with quadratically weighted Gwet’s AC2.The study also cross-checked Krippendorff’s alpha and exact pairwise agreement.
  • RQ2: Risk Assessment Reproducibility: Participants reproduced the single-rater reference band in 111 of 120 ratings, or 92.5%, while the AC2 lower bound exceeded the 0.61 operational reference point.The paper qualifies the threshold because it was not validated for quadratically weighted AC2.
  • RQ3: Scanner-Layer Ablation: The scanner ablation uses Passive, CDSE, and Adversarial layers, with recall computed over applicable threats for each architecture.The evaluation uses a custom testbed because no public AP2 deployment was available.
  • RQ3: Scanner-Layer Ablation: The Full configuration achieved the highest mean recall on every architecture, although other configurations tied it on A4 and A5.
  • RQ3: Scanner-Layer Ablation: Each scanner layer uniquely detected at least one seeded threat, while all three layers missed T-2 on A2, T-1 and T-9 on A3, and T-3 on A4.

9 Discussion and Future Work

The analysis shows that cryptographically valid AP2 artifacts can still authorize transactions that diverge from user intent when pre-signing context or supporting protocol exchanges are manipulated. Security outcomes also vary by deployment architecture, motivating context-binding requirements and layered, deployment-aware validation.

  • 9.1.1 Agentic authorization must bind operational context, not only signed intent.: Cryptographically valid AP2 artifacts can authorize transactions that no longer reflect the user’s intent when pre-signing operational context is manipulated.Relevant context includes discovery choices, cart state, tool outputs, and verifier-facing disclosures.
  • 9.1.1 Agentic authorization must bind operational context, not only signed intent.: Several proof-of-concept attacks steer agents before protected artifacts are produced, so mandate-chain verification may not reveal the failure.The same limitation applies to formal analyses that model signed artifacts but omit the agentic execution path.
  • 9.1.2 AP2 security depends on its protocols and deployment architecture.: AP2 consumes A2A and MCP data before signing, but its mitigations cannot retroactively secure flawed exchanges that shaped mandate semantics and verifier decisions.Some protections therefore need to be structural requirements in the supporting protocols.
  • 9.1.2 AP2 security depends on its protocols and deployment architecture.: Deployment choices determine attacker capabilities and trust boundaries, so the same protocols can expose different threats across architectures.A threat may be absent in one architecture, present in another, or amplified in a third.
  • 9.1.2 AP2 security depends on its protocols and deployment architecture.: Agentic-protocol security tools must combine validation methods matched to threat classes because no single method covers the full attack surface.The scanner uses adversarial testing for reasoning-layer vulnerabilities and static or configuration checks for supply-chain, cryptographic, and retention flaws.
  • 9.2 Limitations: The evaluation used a custom testbed because no complete public AP2 deployment was available, limiting claims about unchanged failures in future third-party deployments.The study does not measure effects on card networks, issuers, acquirers, or other payment-rail systems.
  • 9.3 Future Work: Future public-deployment evaluations could provide a more realistic basis for estimating scanner false-positive and false-negative rates.Such testing could help move the scanner from a research prototype toward production readiness.

10 Conclusion

AP2’s signed mandate chain makes transaction intent verifiable after signing, but unsecured pre-signing context can manipulate agents into producing valid mandates for unintended transactions.

  • 10 Conclusion: A manipulated pre-signing path can yield a valid mandate chain authorizing a transaction the user did not intend.The analysis covers unsecured catalog data, tool results, A2A messages, and other context information.
Loading 2608.23858v1…