Agent Payments Protocol (AP2): Architecture, Authorization, and Security Considerations

The Agent Payments Protocol (AP2) is an open protocol announced by Google and developed with a coalition of payments, technology, and financial services companies. It is designed to standardize how AI agents initiate and complete payments on behalf of a user rather than leaving each agent framework or vendor to build its own ad hoc authorization scheme. The core problem AP2 addresses is authorization ambiguity: when an autonomous agent submits a payment request, how does a merchant, processor, or auditor confirm that the request reflects genuine user intent rather than an error, a misconfigured automation, or a compromised agent acting outside its scope. AP2 answers this by introducing the Mandate, a cryptographically signed, tamper-evident digital contract that captures the terms of a user's authorization. Because AP2 is published as an open specification with a public reference implementation, security teams can review its structure directly rather than relying solely on vendor claims about how agent payments are secured.

Core Architecture and Message Flow

AP2's design separates four roles into distinct trust boundaries: the user, the agent acting on the user's behalf, the merchant, and the payment processor. Each interaction between these roles is mediated by signed mandates rather than implicit trust. AP2 defines separate mandate types to distinguish the moment a user grants authorization from the moment an agent executes a transaction, which is what enables both immediate purchases and delegated, non-real-time scenarios such as an agent completing a purchase later when a price condition is met. The protocol is intentionally payment-method agnostic, meaning it is meant to extend across cards, bank transfers, and emerging real-time payment rails rather than being tied to one settlement network. This flexibility means AP2 sits as a layer above existing payment rails rather than replacing their underlying fraud, dispute, and authorization mechanisms.

How Agent Identity and Authorization Are Established

Authorization under AP2 is built around the mandate rather than a persistent session or API key. A mandate is signed to reflect the specific scope of what a user has authorized, and that signed artifact is what agents, merchants, and processors reference to validate a transaction. This model supports accountability and auditability because a mandate is a verifiable record, not a verbal or implicit permission. However, the strength of this trust model depends entirely on how securely the signing keys are managed. Public AP2 documentation does not yet provide extensive detail on key issuance, rotation, or how an agent's identity is bound to its signing key in a way that survives credential compromise. For security engineers, this means AP2 provides the authorization structure, but the surrounding identity and key management practices are an implementation responsibility, not something the protocol guarantees by default.

Runtime Risks Introduced by Agent-Initiated Payments

Granting an AI agent the ability to create, hold, or act on payment mandates introduces new runtime risk that does not exist in traditional human-initiated payment flows. The separation of authorization from execution, while useful for delegated purchasing, creates a time gap during which the agent's behavior, its operating environment, or merchant conditions can change before the mandate is executed. If a mandate is scoped too broadly, this gap increases the blast radius of a single compromised or misbehaving agent. AP2 also supports multi-agent and delegated scenarios where a mandate may be passed or referenced across multiple agent hops. Each additional hop increases the complexity of verifying the full chain of custody for an authorization, and public specification materials do not yet detail comprehensive revocation mechanics for a mandate once it has been issued. These are architectural gaps that security teams should treat as open questions rather than assume are solved by the protocol itself.

Where Runtime Governance Fits

AP2 defines how a payment authorization is structured and signed, but it does not by itself constrain what an agent is permitted to attempt at runtime, monitor for deviation from expected behavior, or provide an enterprise-wide audit trail across every agent interacting with payment systems. This is the layer that runtime governance is designed to address. Applying least-privilege permissions to agents before they can generate or act on a mandate, enforcing tool approval workflows for payment-initiating actions, and maintaining continuous runtime monitoring and audit logging across agent-to-agent interactions are governance practices that operate alongside a protocol like AP2 rather than being replaced by it. Trussed AI provides runtime governance and security for enterprise AI agents, including agent identity, permissions, and policy enforcement, which enterprises can apply as a control layer when evaluating how AP2-enabled agents are allowed to operate in production.