Who Is Liable When an AI Agent Makes a Fraudulent Purchase

Three parties could plausibly carry it. Today, in most cases, it is you.

---

TL;DR

• An unauthorised agent purchase usually settles as a card-not-present transaction, so the existing liability rules apply and the merchant carries it.
• The agent platform is generally positioned as a referrer or tooling provider, which keeps it out of the liability chain.
• The open question is authorisation scope - proving the agent was permitted to spend that amount for that person.
• This is genuinely unsettled. Treat any vendor claim of liability transfer as a contract term to verify, not a given.

---

Why it lands on the merchant

Nothing in the current rails changes the transaction type. An agent-placed order arrives as card-not-present, and card-not-present liability sits with the merchant. The assistant that produced the referral is not the seller, does not take title to the goods, and in most arrangements is explicitly not a party to the sale.

So the default is unglamorous: it works exactly like any other online order you could not visually verify, with one extra layer of software between the cardholder and the button.

---

The three candidates, honestly assessed

The merchant. Carries it today, for the reason above.

The agent platform. Would be the intuitive answer - their software spent the money. But referrer positioning keeps them out of it, and none of the major surfaces have volunteered to become the merchant of record. If one does, that is a material change worth tracking.

The payment network or rail provider. The rails being built are the mechanism by which liability might eventually move, because they create the evidence that an agent was properly authorised. Better evidence is the precondition for reallocating risk. It has not reallocated yet.

---

Authorisation scope is the real problem

Strip away the framing and the question is narrow: can you prove this agent was allowed to spend this amount, on this person's behalf, for this purchase?

A human at a checkout answers that implicitly by being present. An agent has to answer it explicitly, and the quality of that answer determines who ends up carrying a disputed charge. Scoped, verifiable authorisation is what the payment primitives are for. Until that evidence is standard and accepted, disputes resolve the old way - against the merchant.

---

What actually reduces your exposure

Keep your fraud tooling on. The most common mistake is relaxing velocity and anomaly checks because the traffic arrives from a recognised assistant. Recognised does not mean authorised.

Capture authorisation metadata at order time. Which agent, which authorisation reference, what price and terms were presented. This is the evidence you will want in a dispute and it cannot be reconstructed afterwards.

Segment agent orders in your reporting. You cannot see an emerging fraud pattern in a channel you are not measuring separately.

Get liability claims in writing. If a platform or vendor tells you they carry the risk, that belongs in a contract, not a slide.

---

A note on certainty

Anyone stating this confidently is overstating it. The commercial practice is young, the case law is thin, and the network rules are still being written. What is described here is how transactions settle today and where the pressure is. Revisit it as the rails mature, and do not architect around an assumption that liability is about to move.

---

Related: how the agent paid in the first place

Every agent purchase ends on a rail a merchant already runs: a Link single-use card, Shop Pay, Google Pay, a Stripe Shared Payment Token or a saved card behind a login, and Stripe put Link's agent purchases at more than 1 million businesses that accept it (Stripe, 8 September 2026). Liability follows the credential: the rails, what each protocol binds the shopper to, and the merchant's integration steps are in the agentic payments guide; the operational side is in returns, refunds and chargebacks on agent orders.

Where Tru Commerce fits

We work on the discovery and catalog layers rather than fraud tooling - but the same order metadata that helps a dispute also tells you which agent surfaces are actually driving purchases. If you want to start with visibility, run a free Citation Rank scan.

---

FAQs

Q: Who is liable if an AI agent makes an unauthorised purchase? A: In most current setups the merchant. It settles as card-not-present and those liability rules apply.

Q: Can I push liability onto the agent platform? A: Not by default. If a platform offers protection, confirm it contractually.

Q: What is authorisation scope? A: Proof that an agent was permitted to spend a specific amount for a specific purchase on a specific person's behalf. It is the central problem the payment rails address.

Q: How do I reduce exposure now? A: Capture agent and authorisation metadata on every order, keep velocity and anomaly checks running, and segment agent orders in reporting.