Agent Payments Protocol (AP2) defines a structured way for an agent to request, authorise, and complete payments on a user’s behalf. In practice, security teams should verify that payment authorisation is explicit, scoped to the transaction, and auditable. Controls should separate identity, consent, and payment execution, and monitor for replay, tampering, or unauthorised agent actions.
How AP2 structures an agent payment flow
AP2 is best understood as a payment workflow, not just a message format. The agent initiates a request, the user or delegate supplies explicit permission, and the transaction is then executed within the agreed scope. That separation matters because payment intent, consent, and settlement are distinct steps, and each needs its own controls and audit trail.
For practitioners, the important design question is whether the protocol preserves a clear boundary between “the agent asked” and “the user authorised this exact payment.” That boundary should survive retries, handoffs, and downstream payment processing, otherwise the system can drift from delegated action into ambiguous or overbroad authority.
AP2 also fits naturally into the wider ecosystem of agent identity and delegated authority. A payment flow is only safe when the agent can be distinguished from the user, the scope of authority is narrow, and the execution path is attributable end to end. NHIMG’s Agentic Commerce Identity Guide is useful here because it frames how agent identity, verifiable mandates, and tokenised credentials fit together in agentic commerce.
What security properties AP2 needs to be trustworthy
The core security requirement is that consent is explicit, transaction-scoped, and resistant to reuse outside the approved payment. In practice, that means the authorisation should bind the amount, recipient, timing, and context closely enough that the agent cannot repurpose the approval for a different action.
AP2 also depends on strong controls around delegation. If an agent can act on behalf of a user, then the system needs a way to distinguish delegation from impersonation, and a way to limit what the agent may do without fresh approval. That is why scoped access, per-action policy decisions, and clear separation of identity and execution are so important.
This is the same problem space covered by AI Agent Authorisation Guide, which is useful for understanding task-scoped access, human approval gates, and least-privilege delegation for agents. It also aligns with Agent Identity Standards Tracker, which tracks the wider identity standards landscape around agent identity, authentication, and token exchange.
From a payment-security perspective, the protocol should also support durable evidence of who approved what, when, and under which policy. That auditability is not optional, because disputes in agentic payments are usually about authority, scope, and provenance rather than simple transport integrity.
Where AP2 fails in practice if controls are weak
The main failure modes are replay, tampering, and unauthorised agent action. If a payment approval can be copied, delayed, expanded, or redirected, then the protocol no longer protects the user’s intent. If the agent can silently chain additional actions off the original approval, the system begins to behave like unconstrained automation rather than delegated payment execution.
Another common weakness is overloading a single approval with too much power. A vague or broad consent object can become a standing permission slip, especially when the same agent is reused across sessions or merchants. That creates a governance problem as much as a technical one, because the organisation may be unable to prove that a specific payment matched a specific user intent.
AP2 also inherits the observability problem common to autonomous systems: if the execution path is not logged clearly, it becomes difficult to tell whether a payment was legitimate, replayed, or altered midstream. NHIMG’s AI Agent Observability, Audit and Incident Response Guide is relevant because it focuses on attribution, logging, and kill-switch thinking when an agent’s actions need to be investigated or stopped.
Risk and Threat Considerations
AP2 concentrates value in a small set of approval and execution decisions, which makes it attractive to attackers and dangerous when implemented loosely. The biggest risk is not the payment message itself, but any gap that lets an attacker reuse, alter, or impersonate a legitimate approval path.
Failure mechanism: A weak consent binding, replayable token, or poorly scoped delegation lets an attacker or misbehaving agent turn one approved payment into repeated or redirected payments, or use the same authority for a different transaction.
Impact: Users can lose funds, organisations can lose control over payment provenance, and incident responders may be unable to prove whether the agent acted within its mandate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | AP2 must limit agent payment authority to one transaction. |
| NHI-07 — Long-Lived Secrets | Payment delegation becomes unsafe if reusable credentials outlive the approved transaction. | |
| NHI-10 — Human Use of NHI | AP2 depends on separating user consent from agent execution and preventing credential misuse. | |
| Recommendation — Constrain agent payment authority to the minimum scope needed for each transaction. Prefer short-lived transaction-bound credentials over reusable standing secrets. Prevent agents from using human credentials to authorise or execute payments. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AP2 is vulnerable if an agent exceeds the authority granted for a payment. |
| ASI09 — Human-Agent Trust Exploitation | AP2 must avoid confusing user intent with agent-initiated action. | |
| Recommendation — Enforce per-action approval and deny privilege expansion beyond the approved payment. Require explicit user confirmation for every payment the agent proposes. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | AP2 depends on secure lifecycle handling for payment credentials and tokens. |
| AU-2 — Event Logging | AP2 requires a durable audit trail for who approved, requested, and executed a payment. | |
| AC-3 — Access Enforcement | AP2 needs policy enforcement that limits what the agent may do after consent is granted. | |
| Recommendation — Rotate and bound credentials so payment authorisation cannot be replayed. Log the full authorisation and execution chain for each agent payment. Enforce transaction-scoped policy decisions before executing any payment. | ||
Practitioner Guidance
What to verify: Confirm that every payment approval binds to a single transaction, with amount, recipient, expiry, and context all visible and enforced. If any of those fields can change after approval, treat the flow as high risk.
Decision rule: If the agent can initiate a payment without a fresh user-visible approval for that exact transaction, redesign the flow before production use. If the workflow supports retries or partial failures, make sure the original consent cannot be silently reused.
What good looks like: A reviewer should be able to reconstruct the full chain from user intent to agent request to payment execution, and see exactly where authority was granted, constrained, and consumed.
Practitioner takeaway: AP2 is safe only when the agent is treated as a delegated actor with narrow, auditable authority, not as a general proxy for the user’s payment intent.