How should organisations secure payments when AI agents can buy on behalf of users?

Why This Matters for Security Teams

When an AI agent can buy on behalf of a user, the risk is no longer just payment fraud. It becomes delegated authority abuse: the agent may hold enough context, credentials, and tool access to complete a purchase that the human never intended. Current guidance suggests treating the agent as a distinct actor, not as a proxy extension of the user, which is why controls must separate authentication, delegation, and transaction approval. That framing aligns with the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework.

The practical failure mode is simple: teams harden user login, then assume the downstream agent inherits that trust forever. It does not. An agent can chain prompts, tools, and merchant workflows in ways that bypass the original user intent, especially when purchases are triggered from long-lived sessions or broad API tokens. NHIMG research on OWASP NHI Top 10 shows why delegated machine identities need separate governance from human accounts. In practice, many security teams encounter unauthorized purchases only after a billing spike or chargeback review, rather than through intentional transaction controls.

How It Works in Practice

Secure payment flows for AI agents should be built as a three-step trust model. First, the human authenticates with phishing-resistant controls. Second, the agent receives a narrow delegation grant that defines what it may buy, from whom, for how much, and for how long. Third, the merchant or payment broker validates those claims at transaction time before authorizing the purchase. That runtime validation is what keeps the agent from becoming an opaque buyer with broad standing access.

For implementation, practitioners should prefer short-lived, task-bound credentials over reusable API keys. The credential should represent the workload, not the human, so the system can prove what the agent is and what it is allowed to do. Standards and guidance increasingly point toward workload identity, policy-as-code, and just-in-time approval. That means a merchant can evaluate attributes such as amount, category, destination, device context, and expiration before capture. It also means the agent should not be able to self-expand scope after the user approves a single purchase.

• Use a distinct delegated token for the agent, separate from the user session.
• Bind approval to a specific order, merchant, amount, and expiry window.
• Validate policy at request time, not only at login.
• Revoke or expire delegation immediately after the transaction completes.
• Log both the human approval event and the agent execution path for auditability.

This model is consistent with the CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework, both of which emphasise governance, traceability, and runtime decisioning rather than static trust. These controls tend to break down when merchants accept generic bearer tokens across multiple checkout systems because the token no longer carries enough context to prove transaction-specific intent.

Common Variations and Edge Cases

Tighter payment controls often increase checkout friction and integration overhead, requiring organisations to balance user convenience against fraud prevention. That tradeoff is real, especially when agents are acting on behalf of power users, procurement teams, or subscription workflows that need repeat purchases. Guidance is still evolving on how much autonomy should be granted for low-value or recurring transactions, so there is no universal standard for this yet.

One common edge case is partial delegation. A user may want an agent to compare products, add items to a cart, or draft an order, but not finalize payment. Another is recurring spend, where pre-approved thresholds can reduce noise while still forcing step-up approval for exceptions. Organisations should also treat refunds, subscriptions, and marketplace re-orders as separate risk classes because each one exposes different abuse paths. If the environment uses many third-party merchants, policy enforcement becomes harder because not every checkout flow can validate the same claims. NHIMG’s research on the AI LLM hijack breach and the LLMjacking report both illustrate how quickly abused credentials and overbroad access can turn into downstream compromise. Best practice is evolving toward merchant-verifiable delegation claims, but environments with fragmented payment rails and legacy token reuse remain especially difficult to secure.

Related resources from NHI Mgmt Group

• How can organisations prevent AI agents from becoming overprivileged?
• How can organisations govern AI agents that use service accounts and tokens?
• How should security teams handle delegated access when AI agents act on behalf of customers?
• Should organisations let AI agents move from read-only to autopilot?