Who Is Liable If an AI Agent Buys the Wrong Thing?

Short answer: in almost every case, you do. If your agent spends your company's money, the loss lands on your business by default. Whether any of it is recoverable depends mostly on the rail: a card payment keeps the dispute and chargeback machinery of the card network behind it, while an on-chain stablecoin payment is irreversible by design. What changes the outcome is evidence: whether you can show what the agent was authorized to do, what policy allowed the charge, and who approved it.

Last updated July 2026. This is a practical engineering and finance overview, not legal advice. Talk to your counsel about your own contracts.

The default answer nobody likes

An AI agent is not a legal person. It cannot hold liability, be sued, or be fired. In law it is a tool, and the acts of a tool are the acts of whoever deployed it. If you gave an agent a payment credential and it used that credential, the transaction is presumptively authorized by you, because from the outside it is indistinguishable from you making it.

That is uncomfortable, and it is also the whole reason spend governance exists. You cannot push the loss onto the model provider, and you usually cannot push it onto the merchant, who did nothing wrong by accepting a validly authorized payment. So the real question is not "who is liable" in the abstract. It is "what did I do beforehand that makes this recoverable."

Liability by payment rail

This is the part that actually determines whether you get the money back, and it varies enormously.

The blunt implication: an agent that pays on cards has a safety net, and an agent that pays on-chain does not. If an agent is going to spend meaningful amounts autonomously, that alone is a strong argument for putting the spend on a card rail rather than a crypto one, however elegant the crypto rail is technically. We go through that tradeoff in detail on the x402 comparison.

The three ways an agent buys the wrong thing

They are not the same problem and they do not have the same answer.

It bought the right thing at the wrong scale. The classic: a retry loop, a misparsed quantity, an off-by-one that orders 500 units instead of 5. The purchase is legitimate; the amount is not. A hard per-transaction cap stops this cold, and it is the single cheapest control you can put in place.

It bought from the wrong party. The agent was steered, either by a bad tool result or by a prompt injection, into paying an attacker. This is fraud, and the recourse depends entirely on the rail. On a card you have a real shot. On-chain the money is gone.

It bought something nobody wanted. The agent did exactly what it was told and the instruction was wrong. No control catches this, because nothing looks anomalous. This is what approval gates are for: a human sees the intent before the money moves.

What evidence actually protects you

When a purchase goes wrong, three questions decide how the conversation goes with your bank, your auditor, your insurer, and your CFO. All three are questions about records you either kept or did not.

1. What was this agent authorized to do? A payment mandate is the artifact that answers this: signed, verifiable proof that a human granted a bounded authority, with an amount, a scope, and an expiry. "The agent seemed to think it was allowed" is not evidence. A signed mandate is.
2. What did the policy do? If the charge passed, which rule let it pass? If it should have been blocked, was the rule missing, or was it there and bypassed? That distinction is the difference between a control gap and a control failure, and auditors treat them very differently.
3. Who approved it? If a human cleared the payment, you have a named approver and a timestamp. If no human ever saw it, you need to be able to show that the policy permitted it autonomously and that the policy was itself approved.

None of this is exotic. Finance and compliance teams already track obligations and map them to the controls that satisfy them. Agent spend is simply a new control surface being added to a discipline that already exists. What is new is that the actor is a piece of software that can act thousands of times an hour, which raises the cost of having no record at all.

Can you insure against it?

Commercial crime and cyber policies increasingly get asked about autonomous system losses, and the honest state of play in 2026 is that coverage is inconsistent and underwriters are still working out how to price it. What we can say without speculating is that every underwriter asks the same kinds of questions: what limits were in place, who could approve, and can you produce a record. A business that can answer those crisply is in a materially better position than one that cannot, whatever the policy says. Ask your broker specifically how autonomous agent transactions are treated, because the answer is not uniform.

Common questions

Can I hold the AI model provider liable?

Realistically, no. Model provider terms of service place responsibility for the use of outputs on the customer, and models are supplied without warranty as to correctness. The provider did not authorize the payment; you did, by wiring a payment credential to the model's output.

Is the merchant liable if an AI agent buys the wrong thing?

Generally not. A merchant that accepted a properly authorized payment for goods it delivered has met its obligations. Merchant liability enters where the merchant misrepresented the goods, never delivered them, or is itself the fraud, which is exactly when card dispute rights are worth having.

Does a human approval shift the liability?

It does not move liability off your business, but it changes the nature of the event: an approved purchase is a decision your organization made, not a system that ran away. That distinction matters to auditors and insurers, and it is why approval gates above a threshold are worth the friction on high-value spend.

What is the single most effective control?

A hard per-transaction cap enforced outside the agent. It is trivial to implement, it cannot be argued with by a model, and it converts an unbounded loss into a bounded one. Everything else, approvals, allowlists, velocity rules, is refinement on top of that. See spend controls and our writeup on stopping runaway agent spend.

The takeaway

If your agent buys the wrong thing, the loss is yours. That is the default and no amount of architecture changes it. What architecture changes is how big the loss can get and how much of it you can claw back. Cap the amount outside the agent's own code so a bug cannot spend past it. Prefer rails that carry dispute rights when the amounts are real. Keep a mandate showing what was authorized, a policy verdict showing why the charge passed, and an audit trail naming who approved it. Do that and a bad purchase is an incident. Skip it and a bad purchase is a hole in the accounts that nobody can explain. Next, see how the control plane works or compare the best agent payment platforms.