Because merchants can still be financially responsible for disputes even when the buyer never interacted directly with the store. If the merchant only sees a valid-looking payment token, it may approve the order without enough evidence to judge intent or risk. The result is a mismatch between approval authority and the cost of failure.
Why agent-mediated shopping changes the approval problem
Agent-mediated shopping turns a human purchase into a delegated transaction. That changes the merchant’s risk because the seller is no longer judging a person’s clickstream, session behaviour, or direct intent, it is judging a machine-selected order that may have been assembled, approved, or rerouted through an agent acting on someone’s behalf.
The practical consequence is that standard fraud signals can become less reliable. A merchant may see a valid payment instrument, a normal shipping pattern, and a technically correct checkout flow, yet still lack enough context to know whether the buyer actually authorised that exact basket, price, merchant, or fulfilment path.
This is why liability can increase even without a new payment rail. The transaction still lands on the merchant’s books, but the evidence available at authorisation time may be thinner than in a direct consumer purchase. The merchant is left carrying more dispute exposure while having less certainty about the purchase intent it relied on.
Where liability comes from in delegated checkout flows
Merchant liability rises when the approval decision and the evidentiary record drift apart. If an agent can complete a purchase with a token or delegated credential, the merchant often cannot easily distinguish a properly delegated order from one that was overbroad, misused, or generated outside the buyer’s expectations.
That problem is not just about chargebacks. It also affects refund disputes, fulfilment reversals, and claims that the transaction was not sufficiently authenticated or was not meaningfully consented to by the buyer. In practice, the merchant may have to defend a sale with logs that prove payment succeeded, but not that the right party intended the exact commercial outcome.
Merchants also inherit a harder attribution challenge. When an agent intermediates the purchase, the human, the agent platform, and the underlying credentials may each be part of the path to approval, which complicates post-transaction investigation and weakens the merchant’s ability to separate fraud from delegated use gone wrong.
What merchants need to prove, and what they often cannot
To reduce liability, merchants need evidence that the order was both authorised and bounded. That means knowing whether the buyer approved the agent’s scope, whether the order stayed inside that scope, and whether the merchant can retain enough transaction detail to answer disputes later.
Strong practice is to treat agent-mediated checkout as a consent and delegation problem, not only a payment problem. The merchant should care about order constraints, allowed spend, merchant allowlists, item class restrictions, delivery location limits, and whether the approval record can be reconstructed after the fact.
Where that evidence is missing, the merchant’s position weakens. A token may show that payment was technically valid, but if it does not encode the relevant decision boundaries, the merchant may still be unable to show that the purchase was intended in the form actually submitted.
Risk and Threat Considerations
Agent-mediated shopping creates an attractive fraud path because it can hide misuse behind a legitimate-looking delegation flow. Abuse can range from over-scoped permissions and unintended purchases to malicious redirection of product, quantity, or delivery details while preserving a valid checkout trail.
Failure mechanism: The merchant accepts a transaction on the strength of a token or delegated session, but the authorisation evidence does not prove that the buyer intended the exact order, scope, or recipient. That gap makes dispute handling harder and increases the chance that the merchant absorbs loss after the sale clears.
Impact: The merchant may face higher chargeback exposure, weaker dispute defence, more operational overhead in investigations, and a larger blast radius when a delegated purchase is abused at scale across many orders or accounts.
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, OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Delegated shopping hinges on agent authority and scope, which can be abused in checkout flows. |
| ASI09 — Human-Agent Trust Exploitation | Buyer trust in an agent can be exploited to submit unintended orders or scopes. | |
| Recommendation — Enforce per-action approval and least privilege for agent-driven purchases. Require explicit confirmation for order changes that affect price, recipient, or merchant. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agent checkout tokens can carry more authority than the purchase actually requires. |
| NHI-07 — Long-Lived Secrets | Persistent tokens make delegated shopping abuse and dispute exposure last longer. | |
| Recommendation — Scope shopping credentials to the smallest purchase-specific permissions possible. Rotate or expire purchase credentials quickly after each delegated transaction. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Delegated shopping should limit what an agent can do during authorisation and checkout. |
| AU-2 — Event Logging | Disputes require reconstructing who approved what, when, and under which delegation. | |
| Recommendation — Constrain agent permissions to the minimum actions needed for a single order. Log order approval context, scope changes, and final checkout decisions. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Delegated checkout should not trust a token without continuous validation of request context. |
| Recommendation — Verify each purchase request against current identity, context, and policy before approval. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Agent-mediated purchases can fail when the wrong actor can invoke purchase functions or modify orders. |
| API6 — Unrestricted Access to Sensitive Business Flows | Checkout and fulfilment flows are sensitive business actions that need stronger controls. | |
| Recommendation — Authorize every purchase-related action, not just the session that initiated checkout. Protect shopping and fulfilment flows with tighter limits, monitoring, and approval checks. | ||
Practitioner Guidance
What to prioritise: Anchor your checkout design around verifiable intent, not just successful payment. If the agent can change basket contents, shipping address, or merchant selection, you need a way to prove those fields were within the buyer’s approved bounds before you rely on the transaction as low risk.
What to verify: Check whether your fraud, order, and dispute records preserve the delegation context, including the approval boundary, the final submitted order, and the exact identity or session that authorised it. If you cannot reconstruct those facts later, treat the process as dispute-prone even when auth succeeds.
Practitioner takeaway: The key control question is whether the merchant can prove intent for the specific order it accepted. If not, payment validity alone is a weak defence, and liability may remain with the merchant even when the buyer never touched the checkout directly.