Who's Liable When the AI Agent You Built for a Client Goes Wrong? A Contract Checklist

If you built an autonomous AI agent for a client and it takes a wrong action in production, say it issues a refund it should not have, sends a defamatory message, or deletes records, the question of who pays is decided in two places. The law decides attribution: under the electronic-agent rules in UETA and similar frameworks, an agent's actions are generally attributed to the party that deployed it, which is usually your client. The contract decides who actually absorbs the cost between you and that client. Most freelance contracts I see in 2026 leave that second question dangerously open, and the builder ends up sitting uncapped between a client who expects total cover and a model vendor who caps its own liability at a month of fees.

This is the gap Clifford Chance flagged in its February 2026 briefing "Agentic AI: the liability gap your contracts may not cover." That briefing was written for in-house counsel at large enterprises. There is almost nothing written for the freelancer or small studio actually shipping the agent. So this is my attempt to translate it into clauses you can put in your next statement of work.

Who is actually liable when an AI agent goes wrong?

The short answer is that liability splits into attribution and allocation, and you need to win on both. Attribution is the legal question of whose act the agent's action counts as. Allocation is the contractual question of who pays for it.

On attribution, the helpful news for builders is that the long-standing principle in electronic-transaction law, including Section 9 of UETA in the US and parallel provisions elsewhere, is that a person who uses an electronic or automated agent is bound by its actions even when no human reviewed the specific output. The deployer owns the agent's behaviour the way a company owns the acts of an employee acting in scope. In a normal build-and-handover engagement, the deployer is your client, not you. You wrote the code; they pointed it at production and gave it credentials and authority.

That default is good for you. The problem is that contracts routinely override it. A broad indemnity, a "developer warrants the software is error-free" clause, or an uncapped liability term can pull the cost back onto you regardless of who legally "acted." So the attribution default protects you only if your contract does not quietly bargain it away.

What is the indemnity mismatch, and why does it land on the freelancer?

The indemnity mismatch is the structural trap of agentic work: the model vendor caps its liability to you at roughly one month of fees, while your client wants you to cover unlimited downstream loss, so you absorb the difference personally. You are the thin layer in the middle with the thinnest wallet.

Look at where the money actually sits in a typical stack:

The vendor has read its own terms carefully. Their agreement disclaims warranties on AI output, caps recoverable damages at the fees paid in the prior month or two, and excludes consequential loss. You cannot pass a million-dollar loss up to a vendor who has capped you at a few hundred dollars. So if your client contract leaves you exposed, that exposure stops at you. There is no one below you to push it onto.

This is the single most important thing for freelancers to internalise. The enterprise reading the Clifford Chance briefing worries about a gap between two large insured parties. You face the same gap with no insurance and no balance sheet behind you. The fix is not to find a generous vendor. It is to write your client contract so your maximum exposure matches what you can actually survive.

The six clauses I put in every AI agent contract

Here is the checklist. I treat these as non-negotiable on any engagement where the system can take actions, not just generate text a human then uses.

1. Liability cap tied to fees. Cap your aggregate liability at the total fees paid under the agreement, or a fixed low multiple of them. This is the one clause that converts an unbounded risk into a known one. If a client refuses any cap on an autonomous system, that is a signal to walk.

2. Scope-of-autonomy definition. Define in writing exactly what the agent is authorised to do and what it must never do without human approval. Anything outside that envelope is the client's operational decision, not your defect. This clause is where you draw the line between "the system did what we specified" and "someone changed the config."

3. Human-in-the-loop carve-out. Require human approval for a named list of high-risk actions: payments above a threshold, irreversible deletions, external communications to third parties. When a human approves the action, responsibility for that decision moves to the approver. This is the clause that maps cleanly onto the UETA attribution default and reinforces it.

4. Acceptance and handover trigger. Define when the build is "accepted" and responsibility for operating it passes to the client. After acceptance, you are responsible for defects you introduced, not for how they run it, retrain it, or extend it. Without this, every future incident gets blamed on the original build.

5. AI-output disclaimer that mirrors your vendor. State plainly that AI-generated outputs are probabilistic and not warranted to be accurate, and that the client is responsible for validation appropriate to their use. You are passing through the same reality your model vendor already disclaimed to you. Do not warrant something upstream refuses to warrant to you.

6. Indemnity that flows the right way. The client indemnifies you for third-party claims arising from their use, configuration, and data, and from actions the agent took within its authorised scope. You indemnify only for your own IP infringement and gross negligence. This is the clause that directly closes the mismatch.

Here is roughly how clauses 1 and 2 read in a real statement of work. This is illustrative drafting, not legal advice, and you should have a lawyer in your jurisdiction review the final language.

9. LIABILITY
9.1  The Developer's total aggregate liability arising out of or in
     connection with this Agreement, whether in contract, tort
     (including negligence), or otherwise, shall not exceed the total
     fees paid by the Client under this Agreement.
9.2  Neither party shall be liable for indirect, consequential, or
     special losses, including loss of profit, revenue, or data.
9.3  Nothing in this clause limits liability that cannot be limited
     by law.

10. SCOPE OF AUTONOMY
10.1 The Agent is authorised only to perform the actions listed in
     Schedule A ("Authorised Actions").
10.2 The Actions listed in Schedule B ("Restricted Actions") require
     documented human approval before execution. The Client is
     responsible for the approval process and for any Restricted
     Action approved by its personnel.
10.3 Any modification to Schedule A or B after Acceptance is the
     Client's responsibility and is outside the Developer's warranty.

Note clause 9.3. In many jurisdictions you cannot contract out of liability for death, personal injury, fraud, or gross negligence, and a cap that tries to is at risk of being struck down entirely. Leave the carve-out in so the rest of the cap holds.

How do I price and document the risk so the cap actually holds?

A liability cap only protects you if the rest of the engagement is consistent with it, which means your pricing, your logs, and your scope all have to tell the same story. A cap of "fees paid" on a fixed-fee project is far stronger than the same cap on a thin hourly invoice, which is one more reason I have moved most agent work to value-based engagements. I wrote about that shift in hourly versus value-based pricing ↗, and agent liability is a clean example of why the model matters: a higher project fee both raises your cap to a useful level and reflects the risk you are carrying.

Documentation is the other half. The single best evidence that the agent acted within scope is a log that proves it. So I build agents with an audit trail from day one:

def execute_action(action, context):
    if action.type in RESTRICTED_ACTIONS and not context.human_approved:
        log_event("BLOCKED_PENDING_APPROVAL", action, context)
        raise ApprovalRequired(action)
    result = run(action)
    log_event("EXECUTED", action, context, result=result,
              within_scope=True, approver=context.approver)
    return result

When something goes wrong, that log is what separates "the agent did exactly what Schedule A authorised" from "someone bypassed the approval gate." It turns a finger-pointing argument into a record. I treat the audit log as a deliverable, not an afterthought, the same way I treat tests as a deliverable when I take over an inherited codebase. If you do a lot of that kind of cleanup, the same defensive instinct applies, and I go deeper on it in rescue engineering for vibe-coded apps ↗.

A few practical habits that make the paperwork match reality:

• Keep Schedule A and Schedule B in the repo, version-controlled, next to the code that enforces them.


• Log every restricted action, every approval, and every block, with the approver's identity.


• Snapshot the agent's prompts, tools, and config at the moment of acceptance so "the build" is a fixed thing you can point to later.


• Never let a client talk you into "just give it write access to fix this faster" without updating Schedule A in writing first.

Does a contract cap replace insurance?

No. A cap protects you against the party you signed with; it does nothing for a third party who was harmed by the agent and sues you directly. That is the one exposure a clever contract cannot close on its own.

If your client's customer is defamed by an agent message or loses money from a wrong automated decision, that customer is not bound by your liability cap, because they never signed your contract. They can come after the deployer, and depending on the jurisdiction and the facts, sometimes after you. The tool for that gap is tech errors-and-omissions insurance, sometimes with an explicit AI endorsement, which a growing number of insurers now offer in 2026. For solo builders shipping production agents, I now treat E&O cover the way I treat backups: boring, slightly annoying to pay for, and the thing you are extremely glad to have on the one bad day.

Put together, the picture is simple. Attribution law is mostly on your side and points liability at the deployer. Your contract has to avoid bargaining that protection away, cap what is left, and define scope so clearly that your logs can prove you stayed inside it. Insurance backstops the third-party gap the contract cannot reach. None of this requires you to be a lawyer. It requires you to stop signing an enterprise's standard MSA unchanged, and to bring your own six clauses to the table.

If you are building agents for clients, scoping that work so the risk is shared fairly is part of my AI agents and automation ↗ work.

If you are about to ship an agent and you are not sure your current contract survives a bad day in production, that is exactly the conversation I have with clients before the build starts, not after. You can reach me through my contact page ↗ and I am happy to talk through where your real exposure sits.