Agent Payments Protocol (AP2) is a protocol for handling payments initiated by agents rather than directly by a human user. The main security risk is unauthorised or ambiguous payment authority, especially when agents can act across services. Defenders should require clear approval, scope limits, and transaction logging before execution.
What Agent Payments Protocol means in practice
Agent Payments Protocol (AP2) is about letting an autonomous agent initiate payment-related actions without treating the agent itself as the final authority. The key design problem is separating request generation from payment approval so the payment can be governed, audited, and constrained.
That separation matters because agent workflows often span multiple services, tools, and moments in time. Once a payment action crosses systems, the security question is no longer just whether the request was valid, but whether the authority behind it is still clear, bounded, and provable.
Why AP2 is different from ordinary checkout flows
Traditional checkout assumes a human user is present at the point of payment. AP2 has to handle cases where an agent composes the purchase, negotiates terms, or triggers a transaction later, which makes provenance and consent much harder to preserve.
The protocol therefore sits at the boundary between commerce automation and authorization design. Its value is not only that it can move money, but that it can preserve who approved what, under what scope, and for which transaction conditions.
Agentic Commerce Identity Guide explains the identity model behind agent-led payments, including mandates and tokenised credentials, while Agent Identity Standards Tracker places AP2 alongside the wider standards landscape for agent identity and transaction authority.
Controls that make agent payments trustworthy
For AP2 to be safe, approval needs to be explicit enough to distinguish a suggested action from a permitted one. Scope limits should define what the agent may buy, from whom, for how much, and under what conditions, so the protocol does not become a blanket payment proxy.
Transaction logging is equally important because payments initiated by agents need a durable record of the request, the policy decision, and the execution result. That record is what lets teams investigate disputes, detect misuse, and reconstruct authority after the fact.
AI Agent Authorisation Guide gives the least-privilege and approval model that AP2 depends on, and AI Agent Observability, Audit and Incident Response Guide shows how those actions should be logged and reviewed.
How AP2 fits into the broader agent ecosystem
AP2 is best understood as one piece of a larger agentic commerce stack. The payment layer only works cleanly if the agent can be identified, its authority can be bounded, and the surrounding systems can verify that the request has not been altered or reused in an unintended context.
That is why AP2 is closely related to identity standards, delegated authorization, and secure agent orchestration. If those surrounding controls are weak, payment protocol design alone cannot prevent an overreaching agent from acting outside the user’s intent.
Agentic AI Identity Guide covers the identity and delegation patterns AP2 depends on, and Zero Trust for AI Agents explains how to verify the principal, request, and action before granting payment authority.
Risk and Threat Considerations
AP2 creates meaningful risk wherever agent authority is ambiguous, over-broad, or poorly logged. If a payment request can be generated by an agent but not clearly tied to a specific approval and scope, the protocol can become a fast path to unauthorized spend or disputed transactions.
Failure mechanism: An attacker, malicious insider, or buggy agent abuses delegated payment authority, reuses a valid approval outside its intended context, or expands a narrow mandate into broader purchasing activity.
Impact: Organisations can suffer direct financial loss, fraudulent purchases, difficult dispute resolution, and weak forensic reconstruction because the approval chain does not prove what was actually authorised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | AP2 depends on controlling payment credentials and delegated authority. |
| AC-6 — Least Privilege | AP2 requires narrow action scope for agents initiating payments. | |
| AU-2 — Event Logging | AP2 needs durable records of approval, scope, and execution for payment actions. | |
| Recommendation — Manage payment credentials and tokens so agent-initiated transactions stay bound to approved authority. Constrain agent payment permissions to the minimum scope needed for each approved transaction. Log each agent payment decision and execution event with enough detail to reconstruct authority. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AP2 directly addresses misuse of agent payment authority and delegated privilege. |
| ASI09 — Human-Agent Trust Exploitation | AP2 is vulnerable when a human approval is stretched beyond its intended meaning. | |
| Recommendation — Apply per-action approval and scope checks to prevent agent privilege abuse in payments. Require transaction-specific confirmation so a human approval cannot be repurposed by an agent. | ||
Practitioner Guidance
Why practitioners should care: AP2 should be treated as an authorization and audit problem, not just a payment integration. The most important design question is whether each transaction can be shown to have a clear approver, a bounded scope, and a verifiable execution trail.
Practitioner takeaway: If a payment cannot be explained after the fact from logs and policy records alone, the protocol design is not yet operationally safe enough for production use.
Related resources from NHI Mgmt Group
- How should security teams govern agent-native payments without creating new shadow access paths?
- Why do wallet-based agent payments matter for NHI governance?
- How do agent-native payments change the decision between API keys and runtime authorisation?
- What breaks when AI agent permissions are managed through custom integrations instead of a standard protocol?