The merchant remains accountable for most downstream business impact, including chargebacks, refunds, support costs, and inventory loss, unless the payment rail or wallet contract explicitly shifts liability. That means merchants, fraud leaders, and platform owners need governance controls before enabling agentic commerce at scale.
Why Accountability Does Not Move Just Because an Agent Placed the Order
AI-assisted purchasing changes how the decision is made, but it does not automatically change who absorbs the business loss. In most commercial setups, the merchant still carries the operational burden of disputed transactions, abusive returns, refund handling, support effort, and stock shrinkage unless a contract, wallet rule, or payment rail explicitly reallocates liability. That distinction matters because accountability follows the commercial arrangement, not the novelty of the interface.
For security and fraud teams, the practical issue is that agentic commerce can blur intent, approval, and provenance. A purchase that looks automated may still be treated as merchant-authored activity, especially when identity assurance, authorisation evidence, or transaction controls are weak. Governance has to be designed around that reality, not around assumptions that the presence of an AI assistant shifts responsibility to the model provider. For a control baseline, see NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, many security teams discover the liability question only after chargebacks, refund disputes, or abuse patterns have already become a recurring cost.
How Merchant Liability, Wallet Rules, and Agent Approval Chain Together
Accountability in AI-assisted purchasing usually sits across three layers: the commercial merchant relationship, the payment or wallet contract, and the internal approval workflow that allowed the purchase to happen. If the merchant has accepted the order, fulfilled it, or delivered digital value, the merchant normally owns the downstream consequence even when a machine initiated the transaction. A wallet provider or rail may absorb some loss only where its terms, dispute process, or fraud policy clearly say so.
That is why “who clicked” is often less important than “who was authorised to spend, under what conditions, and with what evidence.” If an AI agent can buy on behalf of a user, the organisation needs to know whether the transaction is treated as delegated approval, unattended automation, or an exception requiring human confirmation. The answer affects fraud operations, customer support, and dispute handling. The stronger the purchasing authority, the more important it becomes to keep logs that show the command source, approval state, spend limits, and revocation path.
- Delegation must be explicit, because implied trust is hard to defend during disputes.
- Spend thresholds need separate treatment from product category restrictions.
- Reversible payment methods reduce financial exposure but do not remove merchant accountability.
- Transaction logs matter most when an abuse claim has to be reconstructed later.
For this reason, teams should treat agentic purchasing as a governed control problem, not just a checkout optimisation feature. Where the rail, wallet, or platform does not clearly assume liability, the merchant side still has to manage abuse, refunds, and operational fallout. This guidance breaks down when the payment arrangement itself is outside normal card or wallet dispute structures, because liability can then depend on bespoke contract terms rather than standard commerce expectations.
Where AI-Assisted Buying Creates Gray Areas and Abuse Paths
Tighter automation often improves conversion speed while increasing the chance that weak approvals are mistaken for valid intent, so teams have to balance convenience against dispute defensibility. The hardest edge cases are delegated shopping, account takeover combined with agent use, and bulk purchasing that appears normal at transaction time but abusive in retrospect.
One common gray area is the difference between a user instructing an agent and a merchant receiving a completed order. If the customer later denies authorisation, the dispute may still land on the merchant unless evidence shows a clear approval chain or the payment instrument offers stronger liability protection. Another gray area appears when the agent is technically operating within a user account but outside the user’s real intent, such as buying restricted goods, making repeated low-value purchases, or exploiting promotional logic. Those cases often look like ordinary commerce until the dispute volume reveals the pattern.
There is also a governance tradeoff. The more autonomy the agent has, the more the organisation has to accept that abuse can be fast, distributed, and hard to unwind. That is why many programmes keep human approval for high-risk baskets, unusual shipping patterns, first-time destinations, or high-value repeat orders. The control objective is not to prevent every automated purchase, but to make abusive ones attributable and stoppable before they become expensive.
In practice, the weakest point is usually not model capability but insufficient transaction governance, because the dispute process only exposes the control gap after loss has already occurred.
Risk and Threat Considerations
AI-assisted purchases create exposure in both fraud and accountability terms because automation can accelerate abusive ordering, conceal intent, and widen the blast radius of a compromised account or delegated agent. The risk is not limited to chargebacks; it also includes refund abuse, inventory loss, merchant support cost, and disputes over whether the transaction was truly authorised.
Failure mechanism: A merchant accepts an order that was generated through weakly governed agent authority, stolen credentials, or an over-permissive delegation model. Once fulfilment has occurred, the transaction is difficult to unwind, and the dispute process may treat the merchant as the responsible party unless strong evidence or contract terms shift liability elsewhere.
Impact: The organisation absorbs financial loss, operational overhead, and trust damage while also inheriting the burden of proving authorisation, distinguishing legitimate automation from abuse, and tightening controls after the fact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | Liability and abuse exposure require explicit risk ownership for AI-assisted commerce. |
| PR.AA — Identity Management, Authentication, and Access Control | Delegated purchasing depends on proving who may authorise transactions and under what limits. | |
| DE.CM — Continuous Monitoring | Chargeback abuse and anomalous buying patterns require ongoing transaction visibility. | |
| Recommendation — Define who owns chargeback and abuse risk before enabling agentic purchasing at scale. Enforce transaction authorization limits for delegated and agent-driven purchase flows. Monitor AI-assisted purchases for anomalous spend, destination, and repeat-order patterns. | ||
| CIS Controls v8 | 6.3 — Access Control Management | AI-assisted buying needs tightly scoped approval and spend authority. |
| 8.2 — Audit Log Management | Disputes require evidence of who approved and executed the purchase. | |
| Recommendation — Limit purchase permissions to the minimum authority needed for each agent or user. Retain transaction logs that prove approval state, delegation, and fulfilment history. | ||
| MITRE ATT&CK | T1657 — Business Email Compromise | Account abuse can enable fraudulent purchases through compromised identities and trust. |
| Recommendation — Hunt for account compromise paths that could turn delegated purchasing into abuse. | ||
Practitioner Guidance
What to verify: Confirm whether your payment contracts, wallet terms, and merchant policies actually shift liability for AI-assisted orders, or whether they leave the merchant carrying the downstream loss. Verify that the evidence trail can show who authorised the spend, what limits applied, and how the decision was delegated.
Decision rule: If a purchase can be disputed later, treat it as a governance problem before it is a fraud problem. High-value, repeat, first-time, or restricted purchases should require stronger approval than ordinary low-risk checkout flows.
Practitioner takeaway: The key judgement is not whether AI made the purchase, but whether the organisation can prove controlled authority and absorb the dispute if it cannot.
Related resources from NHI Mgmt Group
- Who is accountable when AI-assisted impersonation or supplier abuse causes an incident?
- Who is accountable when AI-assisted code changes affect compliance evidence?
- How do organisations keep AI-assisted access changes accountable?
- Who is accountable for mistakes made with AI-assisted work in an enterprise setting?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
