AI Agent Liability: Who Answers When an AI Agent Causes Harm

AI agent liability is the allocation of legal responsibility for harm caused by an autonomous software agent's actions — divided among the organisation that deployed the agent, the developer that built it, the provider of the underlying model, and whoever integrated it into a live system. It is a question about conduct rather than content, which is what separates it from the AI legal questions that came before it.

A chatbot that is wrong produces a wrong answer. An agent that is wrong has already done something: issued a refund, modified a customer record, called a third-party API, committed the organisation to a transaction. By the time anyone reviews the output, the action is in the world — and the legal system, having no category for harm caused by nobody, looks for a person or a company standing behind the act.

Who is actually liable when an AI agent causes harm?

Four parties usually sit somewhere in the chain: the model provider, the platform or framework operator, the integrator who connected the agent to real systems, and the organisation that deployed it. In practice the deploying organisation carries primary accountability, because it decided to deploy, chose the permissions, and controlled the environment in which the harm occurred. That is not a prediction — it is the direction both US and EU law moved in over the last two years.

Why agency law is the right analogy

The useful analogy here is not drawn from computing. It is the law of agency, which has spent centuries on a version of this exact question: who answers when someone acts on your behalf?

Agency law starts from a relationship between a principal and an agent. The principal can be held responsible for the agent's acts within the scope of the authority the principal granted. It distinguishes actual authority — what the principal expressly or impliedly authorised — from apparent authority, where the principal's own words or conduct lead a third party to reasonably believe the agent was authorised.

Writing for Baker McKenzie's Connect On Tech in June 2026, Jonathan Tam sets out why this framework travels so well. Because AI agents can access systems and bind humans to transactions, they "drop AI into bodies of law built to govern action — such as agency, tort, contract, and computer access," in addition to the content-focused rules that govern chatbots. Applied to agentic AI, Tam writes, agency concepts point at concrete engineering questions: "what permissions, credentials, instructions, workflows, and system access a company or employee gave an AI agent, and how the agent's authority was presented to users or counterparties."

Every item on that list is a configuration decision, and every configuration decision leaves — or fails to leave — a record.

The analogy also carries a warning. Apparent authority means an organisation can be bound by an agent doing something it never intended to permit, if the organisation's own setup made that action look sanctioned. An over-broad service account is not just a security problem. It is an authority problem with a legal shape.

What US and EU law now say

California closed the "the AI did it" defence. AB 316 (Krell) was signed on 13 October 2025 as Chapter 672, adding Section 1714.46 to the Civil Code. Its operative sentence is short: in an action against a defendant "who developed, modified, or used artificial intelligence that is alleged to have caused a harm to the plaintiff, it shall not be a defense, and the defendant may not assert, that the artificial intelligence autonomously caused the harm to the plaintiff."

Note what it does not do. Subsection (c) expressly preserves other affirmative defences, "including evidence relevant to causation or foreseeability," and evidence going to another party's comparative fault. The statute does not make deployers strictly liable. It removes one argument — autonomy as a circuit breaker in the chain of causation — and leaves the ordinary fight over causation, foreseeability and apportionment intact. That fight turns on evidence about what the agent was permitted to do and what it actually did.

Europe reached the same place by a different route. The directive written specifically for this problem did not survive: in its 2025 work programme of 11 February 2025, the European Commission listed the proposed AI Liability Directive for withdrawal, recording "no foreseeable agreement" and noting it would "assess whether another proposal should be tabled or another type of approach should be chosen."

What remains is the revised Product Liability Directive, Directive (EU) 2024/2853 of 23 October 2024, and it reaches AI directly. Article 4(1) defines a "product" as "all movables… it includes electricity, digital manufacturing files, raw materials and software." And Article 8(2) should interest anyone deploying an agent they did not build: "Any natural or legal person that substantially modifies a product outside the manufacturer's control and thereafter makes it available on the market or puts it into service shall be considered to be a manufacturer of that product for the purposes of paragraph 1."

Member States must bring implementing law into force by 9 December 2026. Whether heavily configuring or re-scoping a third-party agent amounts to a substantial modification is unsettled — but the question is on a clock, and the organisations best placed to answer it are the ones who can show exactly what they changed.

What an organisation needs to be able to show

Both regimes converge on the same evidentiary demand, and Tam states it plainly: companies "should know what authority their agents have, what systems they can access, what actions they can take, how those actions are supervised, and how they will be explained after the fact." Governance, on this view, is "built into the design and deployment process from the beginning, through documented authority limits, human approval points, monitoring and logging, security controls, vendor responsibility allocations, and periodic reviews as agentic capabilities and use cases evolve."

That resolves into five things a deployer should be able to produce on demand:

A defined authority limit for each agent — not a description of intended behaviour, but a rule in force at the time of the action, with a version history showing when it changed.
An identity for every action, attributable to a real person or a named agent rather than a shared service account that makes the question unanswerable. This is the same gap that surfaces in a SOC 2 audit, where CC6.3 expects privileged actions to trace back to an accountable individual.
A human decision point on consequential actions, with a record of who approved what and when.
A contemporaneous log of what the agent did, produced as the run happened rather than reconstructed afterwards.
A causal account of why — not just that a step ran, but what the agent decided, what it was given, and what fired.

An organisation that cannot produce these is weaker not because its agent misbehaved, but because it cannot describe the authority it granted — precisely the fact the ordinary defences turn on.

The failure mode is not hypothetical. Tam describes an early US test case in which a major online marketplace sued the developer of an AI browser agent, alleging the agent accessed password-protected areas of the site, used customer accounts, and disguised automated activity as ordinary human browsing. However that dispute resolves, it is the shape of the problem: an agent operating past the boundary its operator believed it had.

How Waxell handles this

Waxell produces the authority record at different boundaries, because the boundary an agent crosses determines which record answers the question.

The Waxell MCP Gateway — sold standalone, and included in Waxell Connect — governs the tools/call traffic that traverses it. Each such call is resolved to a real user identity rather than a service account, so a write reaching GitHub, Slack or Notion shows the person who triggered it in the upstream's own audit log. Newly discovered tools cannot be called until an admin approves them, and calls requiring approval are parked for a human with the connection held open, so the agent resumes rather than fails. The audit log records the resolved identity, the decision and the rules that fired; it is durable for years and exports to CSV, without retaining argument values or result bodies. That is an authority record in the agency-law sense: what was permitted, to whom, and on whose say-so.

Waxell Observe covers the model-call boundary for agents you built. Two lines of Python auto-instrument 200+ libraries — the SDK is Python-scoped — capturing LLM calls, tool invocations and decisions as OpenTelemetry parent-child traces. Its 50+ policy categories, including Identity, Delegation, Control and Audit, are evaluated during execution rather than reviewed afterwards; when one triggers, the agent gets structured feedback: retry, escalate, or halt.

Waxell Runtime is for workflows where the wrong step is expensive. Policies gate each step before it runs, kill switches stop an agent, workflow or session immediately, and a policy trigger needing human input pauses the workflow at a checkpoint and resumes from that point once answered.

Waxell Connect sits above the single agent: its audit trail records handoffs, file versions and agent actions, so a multi-agent chain reads back as a sequence of delegations rather than disconnected logs.

None of this decides a case. It makes the deployer the party that can describe, precisely and contemporaneously, the authority it granted — which is what the defences preserved in AB 316(c) and the arguments under Article 8(2) are built out of.

FAQ

Who is liable if an AI agent causes harm?

In most enterprise deployments, primary accountability sits with the organisation that deployed the agent, because it chose to deploy, configured the permissions, and controlled the environment. Model providers, framework operators and integrators can also be drawn in depending on the facts. Liability is allocated across a chain rather than assigned to a single party, and the allocation turns on evidence about authority, causation and foreseeability.

Does California's AB 316 make companies automatically liable for their AI agents?

No. AB 316 adds Section 1714.46 to the California Civil Code and bars a defendant who developed, modified or used AI from arguing that the AI autonomously caused the harm. Subsection (c) preserves other affirmative defences, including evidence relevant to causation and foreseeability, and evidence of another party's comparative fault. It removes one specific defence; it does not create strict liability.

Is there an EU law covering AI agent liability?

The proposed AI Liability Directive was listed for withdrawal in the European Commission's 2025 work programme for lack of foreseeable agreement. The revised Product Liability Directive (EU) 2024/2853 remains, and its Article 4(1) definition of "product" includes software. Member States must bring implementing measures into force by 9 December 2026.

Can we transfer AI agent liability to our vendor by contract?

Contracts allocate risk between the parties who signed them; they do not decide what a third party or a regulator may claim against you. Under Article 8(2) of Directive (EU) 2024/2853, someone who substantially modifies a product outside the manufacturer's control and puts it into service is treated as a manufacturer of the modified product — so heavy reconfiguration of a third-party agent may move responsibility toward the deployer rather than away from it.

What evidence should we keep about our AI agents?

At minimum: the authority rule in force at the time of the action, with its version history; an identity for each action that resolves to a person or named agent; a record of human approvals on consequential actions; a contemporaneous execution log; and a causal account of what the agent decided and why. Evidence assembled after a dispute begins is worth less than evidence generated as the run happened.