How do you authenticate AI agents that make purchases on behalf of customers?

How to establish that an AI purchasing agent is really acting for the customer

An AI agent that buys on behalf of a customer should not be treated as a generic app session. The security question is whether the agent has a verifiable mandate that binds it to one customer, one account, and one permitted buying context. That means the agent needs its own identity, its own scoped authority, and an auditable link back to the customer’s intent.

That distinction matters because delegated commerce creates an on-behalf-of problem, not just a login problem. RFC 8693: OAuth 2.0 Token Exchange is a useful model here because it formalises delegated token use rather than letting the agent reuse a customer credential directly.

For ai agents, identity should be explicit and lifecycle managed. The agent should be registered, tied to an owner, and given a bounded role that states what it may purchase, from whom, and under what conditions. Agentic AI Identity Guide is useful because it treats delegated authority, registration, and retirement as part of the control model, not an afterthought.

Authentication should also be contextual, not just session-based. If the agent is presenting a request to spend money, the request should carry enough signed context to prove the customer mandate, the account, the merchant, the amount, and any approval state. That is the difference between a live customer-authorised transaction and an agent merely holding a reusable credential that can be replayed later.

Which controls should bound the purchase flow?

The strongest control pattern is scoped authority with transaction-specific enforcement. Give the agent only the permissions it needs for a narrow task, then apply amount limits, merchant allowlists, category restrictions, and step-up approval for unusual spend. AI Agent Authorisation Guide directly supports this model because it focuses on task-scoped access, per-action policy decisions, and approval gates.

In practice, the agent’s credentials should be narrow enough that compromise does not equal open-ended purchasing power. If the agent needs a payment token, access token, or delegated key, that material should be short-lived and bound to the intended transaction path, not to the entire customer relationship. The same logic applies whether the agent is making a one-off buy or operating as a recurring concierge.

You also need to separate ordinary automation from high-risk authority. Zero Trust for AI Agents is relevant because purchasing agents should be continuously verified, not trusted once at login and then left to spend freely. The practical control objective is to remove standing privilege wherever possible and re-check the principal and the request at decision time.

For payment flows, a signed request is especially valuable because it creates non-repudiable context. If the user later disputes a purchase, the organisation should be able to show exactly what the agent was permitted to do, what policy allowed it, and which approval or reauthentication step was satisfied. That evidence is often more important than the fact that the agent technically authenticated at some point earlier in the session.

What should you monitor before you trust the agent with more spend?

Monitoring should focus on behavioural drift, not just access success. Unusual merchants, repeated failed authorisations, sudden category shifts, rapid basket changes, and attempts to exceed the normal approval threshold are all signs that the purchase flow may be off-policy or under abuse. The right question is not simply whether the agent can authenticate, but whether its spending still matches the customer’s mandate.

Good observability depends on being able to attribute each action to a specific agent, customer, and request chain. AI Agent Observability, Audit and Incident Response Guide is relevant because it emphasizes logging, attribution, anomaly detection, and kill-switch decisions for agent actions.

For higher-risk purchases, reauthentication should be a deliberate control point. If the request is unusual in amount, merchant, geography, or timing, require the customer or an authorised approver to confirm it again before the agent proceeds. That reduces the chance that a compromised agent can silently escalate from convenience buying into unauthorised spending.

It is also worth testing the failure path. If the agent loses delegated authority, the system should stop cleanly, not fall back to a weaker credential or a cached approval. In other words, revocation must be immediate and visible enough that purchasing stops before the next transaction, not after the account has already been drained.

Risk and Threat Considerations

AI purchasing agents concentrate financial authority, delegated access, and customer trust in one runtime actor. If that actor is over-scoped or weakly bound to the customer mandate, a compromise can produce unauthorised purchases, account abuse, merchant switching, and hard-to-reverse disputes. The risk is highest when the agent can spend without fresh policy checks or when its credentials are reusable across contexts.

Failure mechanism: The agent authenticates once, then reuses broad delegated authority for later purchases, or an attacker steals the agent’s token, key, or approval state and replays it against a different merchant or higher amount.

Impact: The attacker can trigger unauthorised spending, bypass intended approval thresholds, and create attribution gaps that make it difficult to prove whether the customer or the agent initiated the purchase.

Practitioner Guidance

What to prioritise: Bind the agent to a specific customer mandate first, then narrow what it can buy, where it can buy, and how much it can spend. If those three bindings are not explicit, the rest of the control stack is too weak to rely on.

What to verify: Confirm that the agent’s authority is short-lived, transaction-scoped, and revocable, and that every purchase event is traceable to a customer-approved context. If you cannot reconstruct that chain after the fact, the control design is incomplete.

What good looks like: The agent can complete routine purchases without exposing the customer’s primary credentials, but higher-risk or unusual transactions reliably trigger reauthentication or human approval. The system should fail closed when the mandate expires or the policy engine cannot validate the request.

Practitioner takeaway: Treat the AI agent as a delegated purchasing principal, not as a convenience wrapper around the customer account, and design every control around provable mandate, narrow authority, and transaction-level accountability.

Related resources from NHI Mgmt Group

• Why do AI agents make non-human identity governance harder?
• What should teams do when AI agents start making purchases on behalf of customers?
• When is it crucial to implement least-privilege access for AI agents?
• What is the difference between managed identities and hardcoded secrets for AI agents?