How should merchants handle liability shift when AI agents place orders on behalf of customers?

Merchants should treat AI agent-led orders as a distinct trust case, not as a routine extension of human checkout. The key is to separate who initiated the order from which signals prove it is legitimate. Liability should follow verifiable order evidence, not assumptions about the presence of a human cardholder.

Why This Matters for Security Teams

When an AI agent places an order, the merchant is no longer validating only a shopper’s intent at checkout. The decision has to account for delegated authority, transaction risk, and whether the agent is acting within the customer’s instructions. That matters because liability shift rules were designed around human cardholder behavior, not autonomous software that can chain actions, retry flows, or select higher-risk purchase paths.

Practitioners should treat agent-led commerce as a trust problem with evidence requirements, not a simple payment problem. If the merchant cannot distinguish a legitimate delegated purchase from an abused agent session, chargeback disputes become harder to defend and fraud teams lose the ability to reason about consent. Guidance from OWASP Agentic AI Top 10 and NHIMG’s OWASP NHI Top 10 both point to the same operational issue: autonomous systems change the trust boundary faster than payment workflows do.

In practice, many security teams encounter liability and fraud disputes only after an agent has already completed the purchase, rather than through intentional design of delegated checkout controls.

How It Works in Practice

Merchants should separate three things in the payment flow: who owns the payment instrument, who initiated the action, and what proof exists that the action was authorised. For agent-led orders, that means relying on explicit delegation signals, transaction context, and auditable order evidence instead of assuming a human cardholder is directly present.

A practical implementation usually combines payment controls with workload identity and policy checks. The agent should present a verifiable identity token, the merchant should evaluate the request in real time, and the order should be tagged with metadata showing the scope of delegation, item limits, merchant category constraints, and any user approval step. For AI-driven flows, this is closer to intent-based authorisation than traditional role-based checkout logic.

• Require explicit customer delegation for agent purchases, with scope and expiry.
• Use short-lived tokens or approval receipts tied to a single transaction or cart session.
• Log the agent identity, customer account, cart contents, and policy decision for dispute handling.
• Flag orders that exceed delegated limits, change shipping destination, or split into multiple sub-orders.

That operational model aligns with the emerging guidance in the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasise governance, traceability, and context-aware controls. NHIMG’s analysis of AI Agents: The New Attack Surface report shows why this matters: 80% of organisations report agents have already acted beyond intended scope, which means the checkout layer cannot assume benign behaviour by default.

These controls tend to break down in marketplaces or subscription environments where one agent can create many orders across changing contexts because the merchant loses a clean one-to-one link between delegation, intent, and final settlement.

Common Variations and Edge Cases

Tighter liability controls often increase friction, requiring organisations to balance chargeback protection against conversion loss. That tradeoff becomes sharper when the customer uses a general-purpose agent, because best practice is evolving and there is no universal standard for proving that an order was fully authorised by a human at the moment of purchase.

One common edge case is recurring or replenishment orders. If the customer pre-approves a routine purchase pattern, merchants should still require fresh evidence when the agent changes quantity, vendor, fulfilment address, or delivery timing. Another edge case is agent-to-agent commerce, where one system composes the cart and another executes payment. In those flows, liability should follow the strongest available proof of customer delegation, not whichever party touched the transaction last.

Merchants also need a dispute posture for sessions where the customer later claims the agent exceeded instructions. The strongest defence is a clear audit trail showing scope, time, and policy outcome. NHIMG’s Ultimate Guide to NHIs — 2025 Outlook and Predictions is useful here because it frames non-human identity as an operational control plane, not just an authentication concern. Where the merchant only sees payment credentials and not delegated authority evidence, the liability question usually shifts from “was the card valid” to “was the agent authorised,” and those cases are much harder to defend.

Related resources from NHI Mgmt Group

• How should security teams handle delegated access when AI agents act 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?
• Why do AI agents make non-human identity governance harder?