# Who is liable when an AI agent acts? Author: Joe Quenneville Published: 2026-10-26T08:19:41.726+00:00 Updated: 2026-10-26T14:21:26.076447+00:00 ## Answer The company that put the agent into service under its authority is the first person the law names. Vendors share exposure as providers, and software can be a product after 8 December 2026. Prompt injection does not move the loss. The model is not the defendant. ## Takeaways - The deployer (Article 3(4)) is the legal person using the system under its authority — usually the company the agent acts for. - Article 25 can make a customer the provider after branding, substantial modification, or a purpose change. - Directive (EU) 2024/2853 treats software as a product for no-fault claims on products placed after 8 December 2026. - OWASP LLM01 and LLM06 explain how injection plus excessive agency produces the loss; they do not reassign it. - Colorado’s 2024 AI Act was replaced by SB 26-189 (effective 1 January 2027); California SB 53 binds frontier developers, not every deployer. ## Article An AI agent does not take legal personality because it booked a flight, approved a refund, or called an internal API. A legal person does. The question is which one: the company that deployed the agent, the vendor that provided the model or the runtime, the person who approved the action, or — in a narrowing set of cases — more than one of them at once. Counsel who treat “the model did it” as an answer will lose the first serious claim. The law already has names for the people around the model. Use those names. ## What is an agent, in law, not in product marketing? In engineering, an agent is a system that chooses tools and takes actions. In the EU AI Act, that system is still an “AI system” under Article 3(1): a machine-based system designed to operate with varying levels of autonomy that infers how to generate outputs — predictions, content, recommendations, or decisions — that can influence a physical or virtual environment. Autonomy is in the definition. It is not a liability shield. The Act then splits the humans around the system into provider (Article 3(3)) and deployer (Article 3(4)). The deployer is the person using the system under their authority. That is the company on whose behalf the agent acts. Common-law agency is older than any of this. A principal is bound by an agent acting with actual or apparent authority. Giving a software agent production credentials, a customer-facing channel, and a mandate to “resolve tickets” is how you create apparent authority. The software does not have to be a legal agent for the company to be bound by what it does. Do not conflate the two vocabularies. “Agent” in the vendor brochure is not “agent” in a power-of-attorney statute. The brochure does not move the loss. ## Who is the deployer when the agent acts? If the company turned the system on, gave it identity, and let it act toward staff, customers, or counterparties, the company is the deployer. Article 3(4) excludes only personal, non-professional use. That is true for a hosted API and for a model on your own metal. Hosting does not decide the role. Authority does. The deployer is the first person a customer, a regulator, or a plaintiff’s lawyer will name. Employment law, consumer law, and sector rules do not pause because the email was drafted by a model. If the agent discriminated in hiring, the employer is still the employer. If it mis-sold, the firm is still the firm. Article 26 will, when it applies to high-risk systems, require deployers to use the system as instructed, assign human oversight to people with competence and authority, and monitor. Those duties were postponed for most high-risk systems to 2 December 2027 (Annex III) or 2 August 2028 (Annex I). They describe the standard a court will already look for when it asks whether the company was careless. Build them now. ## When does the vendor become the one who pays? The vendor is the provider if it developed the system or model and placed it on the market or put it into service under its name (Article 3(3)). Provider duties for high-risk systems sit in Article 16 and the Chapter III requirements. GPAI provider duties in Chapter V have applied since 2 August 2025. A contract that says “the customer is solely responsible for outputs” does not rewrite Article 3. It may allocate indemnity between the two of you. It does not bind a regulator or a third-party victim. The allocation flips when the customer becomes a provider under Article 25: putting their name or trademark on a high-risk system, making a substantial modification, or changing the intended purpose. Fine-tuning plus a new purpose is the usual path. At that point you carry Article 16, not just Article 26. For injured natural persons in the Union, Directive (EU) 2024/2853 (the new Product Liability Directive) is the other statute. The Commission and the legislator were explicit: software is a product for no-fault liability, regardless of how it is supplied. The Directive applies to products placed on the market or put into service after 8 December 2026 (Article 2(1) as corrected on 7 May 2026). An agent shipped after that date that causes covered damage can put a manufacturer, a component supplier, or — in listed cases — another economic operator on a no-fault hook. This is parallel to the AI Act, not a substitute. US product-liability and negligence claims do not need the Directive. They need a duty, a defect or a breach, and damage. An agent with tool access and no effective human gate is a fact pattern, not a hypothetical. ## What if a prompt injection made it do that? OWASP’s 2025 LLM Top 10 puts prompt injection at LLM01 and excessive agency at LLM06. The 2026 Agentic Top 10 names the same failure in operational language: ASI01 Agent Goal Hijack, ASI02 Tool Misuse, ASI03 Identity and Privilege Abuse. Those catalogues do not assign fault. They describe how an attacker, or a careless document, turns the agent’s own tools against the principal. If the company gave the agent mailbox send-rights, production write-rights, or the ability to execute code, the injection is the method. The permission is the cause. A board that asks “were we hacked?” after an agent wires money has asked the wrong first question. The first question is “what could it do without a human?” LLM06 calls the failure modes excessive functionality, excessive permissions, and excessive autonomy. A competent CISO designs against all three. A competent GC writes that design into the record before the incident, not after. ## Does a human-in-the-loop save you? Sometimes. Not as a slogan. Article 14 will require high-risk systems to be designed so that natural persons can oversee them effectively. Article 26(2) will require deployers to assign that oversight to people with the competence, training, authority, and support to do it. A click-through “approve all” is not oversight. A person who cannot see the tool call, the source document, or the payment file is not a gate. Human-in-the-loop is also how you defeat apparent authority. If counterparties know — because you told them, and because the channel enforces it — that no agent action binds the company until a named person confirms, you have a cleaner agency story. If the agent sends the wire and the human only sees a weekly dashboard, you do not. ## What should be in the contract? Three allocations, in writing, with no marketing language. Role. Who is provider and who is deployer for each system, including after fine-tunes and connectors. Name Article 25 events that change the answer. Authority. Which actions the agent may take without a human, which actions require a named approver, and how the counterparty is told. This is the agency clause. Software vendors often omit it. Evidence. Logs, prompts, tool traces, model identity (name, version, hash if you have one), and retention. The Product Liability Directive and every serious discovery request will ask for the same bundle. If you cannot produce it, you will be arguing from reconstruction. Indemnity is necessary and insufficient. Indemnity moves money between contracting parties after a loss. It does not restore a customer relationship or answer a market-surveillance authority. ## What do US and Indian rules change? They change the privacy and sector overlay, not the basic principal-first answer. California’s Transparency in Frontier Artificial Intelligence Act (SB 53, signed 29 September 2025) binds frontier developers, not every enterprise deployer. It is about catastrophic-risk frameworks, safety incidents, and — in the chaptered definitions — unauthorised access to, modification of, or exfiltration of frontier-model weights that results in death or bodily injury. It is relevant if you train or initiate training of a frontier model. It is not a general agent-liability statute. Colorado enacted SB 24-205 in 2024, then repealed and reenacted the scheme as SB 26-189 on 14 May 2026. The new Automated Decision-Making Technology law takes effect on 1 January 2027. From that date, developers of covered ADMT used to materially influence consequential decisions must give deployers technical documentation; deployers pick up use, notice, and correction duties. Hiring, housing, credit, insurance, and essential public services are the listed arenas. An agent that “materially influences” those decisions is in the text. An agent that only drafts email is not, unless you stretch “materially influence.” India’s Digital Personal Data Protection Act, 2023 makes the Data Fiduciary responsible for processing done by a processor on its behalf (section 8(1)–(2)). An agent that processes personal data is a processing operation. Consent or a legitimate use must exist (section 4). A breach requires intimation to the Board and to affected Data Principals (section 8(6)). The DPDP Rules, 2025 stagger commencement: rules 1, 2 and 17–21 on Gazette publication in November 2025, rule 4 (consent-manager registration) one year later, and rules 3, 5–16, 22 and 23 eighteen months after publication. The Act’s processor-on-your-behalf rule does not wait for an agent-specific statute. None of these texts say the model is the defendant. ## What to do next - List every agent with tool access. For each, write the legal person it acts for, the actions it may take alone, and the human who can stop it. - Run Article 25 over every fine-tune, connector, and branded wrapper. Record the role. - Cut send, write, and pay permissions that are not required for the stated purpose. LLM06 is the checklist. - Put retention around prompts, tool traces, model identity, and approver identity. If you cannot replay an action, you cannot defend it. - Where the estate is mixed — vendor APIs, internal agents, and systems that may be high-risk — use an [Architecture Review](https://www.aistandards.inc/#book) to map which box is whose, on the record. The agent acted on your behalf because you set it up to. Liability follows that setup. Change the setup, or own the acts. ## FAQ ### Can we say the model is responsible? No. The AI Act names providers and deployers. Product-liability and agency name economic operators and principals. The model is not a legal person. ### Does a vendor contract that blames the customer settle it? It may allocate indemnity between the parties. It does not bind a regulator or an injured third party, and it does not rewrite Article 3. ### What if the agent was prompt-injected? Injection is the method. Permissions and missing human gates are the cause. OWASP LLM06 is the control checklist; it is not a defence by itself. ### Does human-in-the-loop remove liability? Only if the human has competence, authority, and sight of the action. A click-through “approve all” is not oversight under the standard Article 26 describes. ### Is Colorado’s 2024 AI Act still the rule? No. SB 26-189, signed 14 May 2026, repeals and reenacts the scheme as an automated decision-making law effective 1 January 2027. ## Sources - [AI Act Article 3 — Definitions](https://artificialintelligenceact.eu/article/3/) - [AI Act Article 25 — Value chain](https://artificialintelligenceact.eu/article/25/) - [AI Act Article 26 — Deployer obligations](https://artificialintelligenceact.eu/article/26/) - [Directive (EU) 2024/2853 — Product liability](https://eur-lex.europa.eu/eli/dir/2024/2853/oj/eng) - [Corrigendum to Directive (EU) 2024/2853 (OJ L 2026/90364, 7 May 2026)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202690364) - [OWASP LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) - [OWASP LLM06:2025 Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) - [OWASP Top 10 for Agentic Applications 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) - [California SB 53 — Governor signing statement](https://www.gov.ca.gov/2025/09/29/governor-newsom-signs-sb-53-advancing-californias-world-leading-artificial-intelligence-industry/) - [Colorado SB26-189 — Automated Decision-Making Technology](https://leg.colorado.gov/bills/sb26-189) - [Colorado Attorney General — AI / ADMT page](https://coag.gov/ai/) - [Digital Personal Data Protection Act, 2023 (MeitY)](https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf) - [Digital Personal Data Protection Rules, 2025 (MeitY)](https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf)