Who Is Liable When an AI Agent Makes a Mistake?

You are. In every commercial deployment we have seen, the operator of the agent carries the liability for what the agent does, not the model provider and not the deployment vendor. That is precisely why the only defensible architecture is one where a human approves any action that is expensive, irreversible or customer-facing, and where every action the agent took is logged in an account you control.

This is an operational reading from a team that deploys agents into other people’s businesses. It is not legal advice, and your jurisdiction, your contracts and your insurance will shape the specifics. But the shape of the answer has been consistent across every deployment we have scoped, and it is worth understanding before you give an agent its first credential rather than after.

Who is legally responsible when an AI agent acts?

The operator. The business that gave the agent its access, its instructions and its job.

The reasoning is not exotic. An AI agent has no legal personhood. It cannot hold a licence, sign a contract or be sued. When it sends an email, the email came from your domain under your authority. When it moves money, the transfer went out of your account under a credential you issued. When it deletes a record, the record was in your system and the agent was acting as your delegate. From the outside, and from the perspective of the person affected, the agent did not do anything. You did, using a tool.

That framing is the one courts and regulators have historically applied to automated systems of every kind, from trading algorithms to automated billing, and nothing about language models changes the underlying principle that a business is responsible for the tools it operates. Treat it as settled for planning purposes.

What do model provider terms actually say about liability?

Broadly, that it is yours. We are describing the general shape here rather than quoting any specific contract, because those documents change and you should read the current version for the provider you actually use.

The common pattern across commercial model APIs is a licence to use outputs, a disclaimer that outputs may be inaccurate, a requirement that the customer is responsible for how outputs are used and for compliance with applicable law, and a liability cap tied to fees paid. Some providers now offer indemnification for specific intellectual-property claims on certain enterprise tiers. None that we are aware of accept responsibility for the actions your agent takes with the model’s output, and it would be strange if they did, because they cannot see those actions.

What this means operationally is that the model is a component you are using, in the same category as a database or an email API. The provider warrants that the component works roughly as described. What you build with it is on you.

Which actions should always require a human approval gate?

Four categories. This is the list we apply to every agent we deploy, and it maps directly to where liability concentrates.

1. Money movement. Payments, refunds, transfers, invoice issuance, anything that changes a financial balance. The agent can prepare it. A person releases it.
2. Anything that leaves the building. Outbound email, SMS, social posts, API writes to a third party’s system. Once it is sent it is evidence, and it was sent under your name.
3. Deletion or destructive change. Removing records, overwriting data, revoking access, deploying to production. The common property is that undo is expensive or impossible.
4. Anything a customer will read. Proposals, support replies, published content, contract language. The quality bar is the relationship, and an unreviewed send is the failure a customer will actually notice.

Everything outside those four categories, which is most of the useful work, the agent can do alone: reading, reconciling, drafting, classifying, summarising, flagging. In our own operations the agent reads every inbox, drafts every reply and reconciles every ledger, and is structurally unable to send, pay or delete without a named person approving.

The word structurally matters. A gate that lives in the prompt (“always ask before sending”) is a request, and language models do not reliably honour requests under all conditions. A gate that lives in the runtime, where the send tool simply does not execute without an approval token, is a control. Only the second kind counts when you are explaining to someone what went wrong.

How do you prove what an agent did?

With logs you own, in an account you control, that the agent cannot edit.

When something goes wrong, the first questions are what the agent did, in what order, on what inputs, and who approved the gated steps. If you can answer those from a durable record, you have an incident. If you cannot, you have a mystery, and mysteries are what turn a contained mistake into a dispute.

The practical requirements:

• Every tool call recorded with its inputs and outputs, not just a summary of the run.
• Every gated action tagged with the approver’s identity and the time of approval.
• Logs written to storage the agent has no delete permission on. An agent that can tidy up its own history is not auditable.
• The record in your account, not the vendor’s. If the audit trail lives on a platform you rent, you can produce only what the platform chooses to export, on the platform’s timeline, for as long as your subscription lasts.

That last point is the quiet argument for customer-owned infrastructure arrived at from the legal side rather than the cost side. The ability to produce the complete record on demand, years later, without asking anyone’s permission, is worth more in an incident than any feature.

Does customer-owned deployment change the liability picture?

It does not transfer the liability. It makes the liability defensible.

Running the agent in your own cloud account does not make the model provider or the deployment vendor responsible for the agent’s actions. You are still the operator. What it changes is your ability to demonstrate that you operated responsibly: that the gates were real, that the approvals were recorded, that the access was scoped, that the logs are complete, and that when you decided to shut it off you could do so yourself, immediately, without filing a ticket.

Those are the facts that determine whether an incident is a documented, bounded operational error or an open-ended question about what your systems were doing. The architecture does not change who answers. It changes how good the answer is.

What should be in an AI governance policy before you deploy?

A short document, written before the first credential is issued, that a new employee or an auditor could read in ten minutes. Ours covers:

1. Scope. The named jobs the agent performs, and a plain statement that anything else is out of scope.
2. Autonomous actions. The list of things the agent may do without approval. Keep it to read, draft, classify, reconcile and flag.
3. Gated actions. The four categories above, and any additions specific to your business.
4. Approvers. Named people, not roles, with a backup for each.
5. Access. Which systems the agent can reach, with what permission level, and the principle that write access is granted per job and never as a blanket.
6. Logging. Where the records live, who can read them, and the retention period.
7. Revocation. The exact steps to shut the agent off, who can execute them, and a confirmation that they have been tested.
8. Review cadence. How often the scope and the gate list are re-read against what the agent is actually doing.
9. Incident process. Who is told, what is preserved, and what is paused when the agent does something unexpected.

If you can fill in all nine sections in an afternoon, you are ready to deploy. If section four or seven is hard to write, you have found the real work.

The short version

The operator answers for the agent. Plan on that being you, build the gates into the runtime rather than the prompt, keep the logs where only you control them, and write the governance policy before you need it. The security baseline covers how a Sovereign Agent implements each of those controls, and the harness engineering article explains why the boundary around the model, not the model itself, is where agent projects succeed or fail. For a worked example of an agent that reads everything and sends nothing on its own, see the executive inbox triage use case.