Table of Contents
An agent with a budget runs for six hours overnight and spends eleven thousand dollars instead of four hundred. By breakfast the question is not what went wrong technically. It is who pays.
The reflex answer is that the vendor who built the agent should carry it, or the model provider, or the platform. In practice almost none of those parties is holding the obligation, and the business that deployed the agent usually is.
The reason is older than any of this technology. An agent is not a legal person, so it cannot owe anything, which means the loss has to land on a party that can, and the law has well-developed views about which party that is.
Nobody can sue the software. The question is always which human or company is treated as having made the purchase, and the absence of a human in the loop is not the defence people assume it is.
Key Takeaways
- The agent is not a party, so the deployer usually is.
- A cap your vendor never saw may not bind them.
- Lack of human review is generally not a defence.
- Using what the agent bought can ratify the purchase.
- On stablecoin rails the overspend is simply final.
Three Questions Hiding in One
Overspending covers three situations that resolve very differently, and conflating them is why the answer seems unknowable.
The first is burning through a budget on things it was allowed to buy, such as an agent that loops and calls a paid API fifty thousand times. Nobody disputes the purchases, and the loss is simply yours.
The second is buying something outside its mandate from a third party, which is a contract question about whether that purchase binds you. The third is a compromised agent spending funds for someone else's benefit, which is fraud and follows a different path again.
Only the second is genuinely contested, and it is the one worth understanding properly, because the authorisation layer our analysis of payments for AI agents describes exists to answer exactly this question before a dispute starts.
What to note: classify the incident before arguing about it, since a looping agent and a rogue purchase have almost nothing in common legally.
Why the Deployer Usually Carries It
Agency law has handled this shape of problem for a century, and the doctrine transfers more cleanly than people expect.
An AI agent generally cannot be a contracting party itself. The company that deploys it, however, can be bound where its own conduct led a counterparty to reasonably believe the agent was authorised, and that appearance traces to things the company did rather than to anything the agent claimed.
The signals that create that appearance are mundane. A company email address, access to a procurement portal, purchase-order numbers, and above all a history of similar transactions being honoured all tell a vendor that orders from this source are good.
The hoped-for defence does not hold either. Under US electronic transaction statutes, contracts can form through electronic agents without contemporaneous human review, so saying nobody looked at it is a description of your process rather than an escape from the deal.
What to note: the more reliably your agent has transacted in the past, the stronger a vendor's argument that the next order looked routine.
Your Internal Cap May Not Save You
This is the finding that should change how businesses document agent authority, and it is almost absent from technical coverage.
Suppose your policy limits the agent to twenty-five thousand dollars and it places a thirty thousand dollar order that looks ordinary to the vendor. A limit the counterparty never knew about may not protect you, because apparent authority is assessed from what the vendor could reasonably perceive rather than from your configuration file.
There is a second trap immediately after the incident. Accepting and using goods once you know the order was unauthorised can amount to ratifying it, which converts a contestable purchase into one you have affirmed by conduct.
Software error is not a general escape either. Courts have shown willingness to hold companies responsible for what their automated systems tell customers, as in the Canadian decision involving an airline's chatbot, which is non-binding elsewhere and indicative of the direction.
What to note: a limit has legal force when the counterparty knows about it, so put transaction caps in your vendor terms rather than only in your code.
The Rail Decides What Recourse Remains
Once the money has moved, the settlement method determines whether anything can be done at all.
On card rails, fraud is reasonably well allocated. Where an agent authenticates properly and a token is issued correctly, liability tends to follow existing tokenised transaction rules, with the issuer carrying fraud risk and cardholder dispute rights intact.
Everything short of fraud sits in an open space. An agent that simply bought too much or bought the wrong thing produces a loss still being negotiated among issuers, acquirers, agent platforms and merchants, with no liability shift in place, and US consumer rules assume a transaction was either authorised or not rather than misinterpreted.
On stablecoin rails the question collapses. Settlement is final, there is no chargeback, and recovery depends entirely on the counterparty agreeing to return funds, which is the allocation set out in our guide to who bears the loss.
What to note: choosing an irreversible rail for agent spending is a decision to accept your own configuration as the only control.
Limits That Others Can See
The practical conclusion from all of the above is that enforcement has to be structural and visible rather than internal and implied.
A policy the model is told to respect is an instruction. A limit enforced by the system holding the money is a wall, and the difference shows up both in how much damage is possible and in what you can demonstrate afterwards.
Cards are unusually good at this for the mundane reason that a declined transaction is externally observable. A card that stops at its ceiling produces a refusal the vendor sees in the moment, which is a far better record than a policy document nobody outside your company ever read.
A business account with per-card limits, one card per agent or project, merchant controls and approval rules is the usual way to get that, and Airwallex pairs it with cashback on eligible transactions at 2%, which returns something on spending that was going to happen on a card regardless.
What to note: issue one card or one wallet per agent, because a shared instrument makes it impossible to show which agent exceeded what.
Where the Loss Lands
| Scenario | Who typically absorbs it | Why |
|---|---|---|
| Agent loops on permitted purchases | The deployer | Every purchase was authorised and delivered |
| Agent exceeds an internal cap, vendor unaware | Likely the deployer | Apparent authority is judged from outside |
| Agent exceeds a cap stated in vendor terms | Contestable | The counterparty had notice of the limit |
| Compromised credential spends funds | Depends on rail and controls | Fraud rules apply on cards, finality on chain |
| Platform or provider defect causes it | Usually the deployer | Vendor terms generally disclaim consequential loss |
| Goods kept after discovering the overspend | The deployer | Continued use can ratify the purchase |
Only one row in that table is genuinely contestable, and it is the row where the limit was written into an agreement rather than into a configuration.
What to note: read the liability section of your agent platform and model provider terms before assuming either will share a loss.
How to Move the Risk
1. Put the cap where the money is
Enforce hourly, daily and per-transaction ceilings in the wallet or card rather than in the prompt, which is the mechanism covered in our guide to agent spend limits.
2. Tell your counterparties the limit
Write the authorised transaction size, the approved channels, and who may commit the company into vendor agreements. A limit with notice is a defence, and a limit without notice is a preference.
3. Require human approval above a line
New vendors, indemnities, auto-renewals and large commitments should need a person. The line can be high, and it should exist.
4. Reject an unauthorised order immediately
Say so in writing, do not deploy or consume what arrived, and arrange return. Delay and use are the two behaviours that turn a disputable order into an affirmed one.
5. Keep the record that reconstructs the decision
Log the instruction given, the permissions in force, the approvals, and the transaction itself. Without that chain you cannot show the purchase fell outside what anyone authorised.
What to note: all five steps are cheap, and together they move you from arguing about intent to presenting evidence of authority.
Risks and Limitations
- This is a developing area, and how courts apply apparent authority to autonomous agents is genuinely unsettled.
- Outcomes vary by jurisdiction, and the doctrines cited here are US-centred.
- A disclaimer can be undercut by conduct that contradicts it, so consistency matters more than wording.
- Insurance may not respond, since policies distinguish unauthorised transactions from authorised ones induced by error.
- Platform and model provider terms typically disclaim consequential loss, so recovery up the supply chain is unlikely.
Conclusion
Who is liable when an AI agent overspends? In most situations the business that deployed it, because the agent cannot hold an obligation and the deployer is the party whose conduct made the agent look authorised.
The defences people expect do not work. Nobody reviewed it is not a defence where contracts can form through electronic agents, a cap the vendor never saw may not limit what binds you, and keeping the goods afterwards can confirm the purchase you wanted to dispute.
What does work is unglamorous. Enforce the ceiling in the instrument that holds the money, state the limit in the agreements your counterparties actually read, require a person above a threshold, refuse unauthorised orders in writing straight away, and keep logs good enough to reconstruct who authorised what.
Read Next:
FAQs:
1. Can an AI agent be held liable for a purchase?
No. An agent is not a legal person and cannot hold an obligation, so liability falls on a party that can, which is normally the business that deployed it and whose conduct made the agent appear authorised to the counterparty.
2. Does an internal spending limit protect my company?
It limits damage but may not limit what binds you. Apparent authority is assessed from what the counterparty could reasonably perceive, so a cap the vendor never knew about may not prevent an order above it from being enforceable.
3. Is no human reviewed it a valid defence?
Generally not in the US, where electronic transaction statutes allow contracts to form through electronic agents without contemporaneous human review. The absence of review describes your internal process rather than defeating the contract.
4. What should I do in the first hour after discovering an overspend?
Stop further spending, state in writing that the order was unauthorised, and avoid using or deploying whatever arrived, because continued use can ratify the purchase. Then preserve the logs showing the instruction, the permissions, and the transaction.
5. Does the payment rail change who is liable?
It changes what recourse exists. Card fraud liability broadly follows tokenised transaction rules, non-fraud agent disputes remain unallocated with no liability shift, and stablecoin payments are final with recovery depending on the counterparty's cooperation.
Disclaimer:
This content is provided for informational and educational purposes only and does not constitute financial, investment, legal, or tax advice; no material herein should be interpreted as a recommendation, endorsement, or solicitation to buy or sell any financial instrument, and readers should conduct their own independent research or consult a qualified professional. Liability for autonomous agent transactions is an unsettled and rapidly developing area, the doctrines referenced here are US-centred and applied differently across jurisdictions, and nothing above is legal advice; consult qualified counsel about your own agreements, controls, and exposure before deploying an agent that can spend.
