AI agents create a different kind of legal problem from chatbots that only answer questions.
An agent can open an account, send a message, retrieve records, change a file, place an order, run code, or call another system. It may take several steps without asking a person to approve each one. If one of those actions causes harm, saying that the system acted on its own will not settle who is responsible.
California has now made that point explicit. Assembly Bill 316, effective January 1, 2026, says that a defendant who developed, modified, or used AI alleged to have caused harm cannot defend the case by asserting that the AI autonomously caused the harm.
The law does not make every AI developer or user automatically liable. A plaintiff must still prove the elements of a claim. Defendants may still dispute causation and foreseeability, raise other affirmative defenses, and present evidence about another person or entity's comparative fault.
But one escape route is closed. A company cannot place an AI agent between itself and the consequences of an action, then treat the agent's autonomy as the end of the responsibility analysis.
The Short Answer
- AI agents are not independent legal persons that absorb liability for the people and companies using them.
- Responsibility will depend on the claim, the harmful act, who built and deployed the system, who gave it authority, and what controls each party could reasonably exercise.
- The developer, deploying company, employee, vendor, and management team may face different theories of responsibility for the same incident.
- Contracts can allocate losses between companies, but they usually do not erase duties owed to regulators, consumers, employees, or other injured parties.
- The most useful evidence will often be operational: permissions, instructions, approval records, tool calls, logs, testing, warnings, and incident response.
California Has Rejected The Simplest Version Of “The AI Did It”
AB 316 is short, but its language reaches a broad set of actors. It applies to a defendant who "developed, modified, or used" artificial intelligence alleged to have caused harm.
That wording matters. The statute is not limited to frontier-model companies. It can reach a business that configures or deploys a third-party system, as well as a developer that builds one.
The statute also avoids declaring who must lose a case. It does not create strict liability. It does not say every unexpected output was foreseeable. It does not eliminate disputes over whether the AI actually caused the injury. And it preserves evidence about the comparative fault of other people and organizations.
Its point is narrower: autonomy by itself is not a defense.
Utah took a related approach in its Artificial Intelligence Policy Act. In covered consumer-protection matters, a person remains responsible for a violation committed through generative AI even when the AI made the statement or undertook the act at issue. These statutes address different conduct, but they share a basic premise. Businesses remain accountable when they choose AI as the means of acting.
Existing Law Still Does Most Of The Work
There is no single federal statute that assigns every AI-agent loss to a developer, deployer, or user. Courts and regulators will often start with laws that already govern conduct.
Depending on the facts, a dispute may involve negligence, product liability, contract, fraud, consumer-protection law, privacy, discrimination, employment law, professional duties, intellectual property, or computer-access restrictions.
That means the answer to "who is responsible?" changes with the act.
If an agent makes an unauthorized purchase, the dispute may focus on actual and apparent authority, contract terms, payment controls, and ratification. If it rejects a job applicant, employment-discrimination and automated-decision rules may dominate. If it retrieves protected data, privacy and security duties may matter most. If it sends a false claim to a customer, consumer-protection and misrepresentation theories may apply.
Agentic AI makes the factual chain more complicated. It does not remove the governing law.
Responsibility Can Sit In Several Places At Once
The Developer
A developer may face scrutiny when the system's design creates an unreasonable risk, when safety claims exceed actual testing, or when known limitations are not disclosed to customers.
The harder cases will involve systems sold for action rather than advice. A developer that markets an agent as capable of operating business systems may be asked what it knew about unauthorized actions, prompt injection, credential misuse, error recovery, and escalation to a human.
The developer will also want evidence showing where its role ended: what controls it supplied, what instructions the customer added, what integrations the customer selected, and whether the harmful behavior came from a material modification outside the developer's control.
The Deploying Company
The organization that gives an agent credentials, data, tools, and a business objective will often be the most visible target.
That company decides whether the agent may read or write, recommend or execute, draft or send. It chooses which systems the agent can reach and whether a person must approve a consequential action. It also decides whether the agent operates in hiring, finance, health, legal work, customer service, or another regulated setting.
Those choices can matter more than the fact that the underlying model came from a vendor.
The Employee Or Operator
Individual responsibility will depend heavily on the setting and the person's conduct.
An employee who follows an approved workflow in good faith is differently situated from someone who bypasses controls, grants excessive permissions, ignores warnings, or uses an agent for an unauthorized purpose. Professional rules may add another layer for lawyers, clinicians, financial professionals, and others who cannot delegate their duties simply by using software.
Employers may also face responsibility for employee conduct within the scope of work. Calling an agent a personal productivity tool does not necessarily resolve that question if the company approved, encouraged, or benefited from its use.
Vendors And Integrators
Many agent systems are assembled from several services: a model, orchestration software, cloud infrastructure, identity tools, external data, and specialized integrations.
When something goes wrong, each provider may point to another part of the stack. The model vendor may blame the deploying instructions. The integrator may blame the model. The customer may blame both. The contract may cap damages or assign defense obligations, but the technical record will still matter.
Who supplied the faulty component? Who controlled the relevant setting? Who knew about the risk? Who could have prevented the act? Those questions will shape both liability claims and contractual allocation.
Management And The Board
Not every AI-agent incident becomes a board-level issue. Repeated warnings, material security exposure, regulated operations, or a large financial risk can change the analysis.
Leadership may be asked whether the company approved the use case, assigned an accountable owner, set risk limits, and responded to known failures. A policy that says "human oversight required" will not help much if the system was designed to act at machine speed and no one had the time, information, or authority to intervene.
Authorization Is Becoming A Legal Fact, Not Just A Security Setting
The federal government is beginning to treat agent identity and authorization as a distinct systems problem.
NIST launched an AI Agent Standards Initiative in February 2026. Its National Cybersecurity Center of Excellence has also focused on applying identity and authorization standards to software and AI agents. The concern is practical: agents can take actions with limited human supervision, and the scale of those actions can expand quickly.
The June 2, 2026 executive order on advanced AI security points in the same direction. It directs the Attorney General to prioritize enforcement against people who use AI to unlawfully access or damage computer systems, steal data, or facilitate other crimes under existing federal statutes.
For companies, the question is not only whether a person was authorized to use the agent. It is whether the agent itself had a defined identity, limited permissions, a traceable sponsor, and boundaries that matched the approved task.
An agent using a shared administrator credential creates a much worse evidentiary position than one with its own identity, narrow permissions, and time-limited access.
Contracts Help, But They Do Not Solve The Whole Problem
AI-agent contracts should address more than ordinary uptime and confidentiality terms.
The parties should be clear about:
- which actions the agent is authorized to take;
- who configures permissions and approval thresholds;
- responsibility for third-party tools, models, and data;
- testing obligations before deployment and after material changes;
- notice when the model, orchestration layer, or safety controls change;
- logging, record access, and incident cooperation;
- responsibility for unauthorized transactions or communications;
- indemnity, liability caps, insurance, and exclusions; and
- suspension or shutdown rights when the agent behaves unexpectedly.
Those terms can decide who pays after a loss. They may also reveal who actually controlled the risk.
A broad disclaimer that AI can make mistakes will not answer whether the vendor promised a particular control, whether the customer disabled it, or whether either party ignored a known failure mode.
What A Defensible Agent Record Looks Like
When an agent acts, a company should be able to reconstruct the action without guessing.
That record should identify:
- the agent, model, and relevant version;
- the person or business owner who authorized the deployment;
- the task and instructions given to the agent;
- the systems, data, credentials, and tools it could access;
- the steps it took and external tools it called;
- the information it relied on;
- any human approvals, overrides, or ignored warnings;
- the resulting transaction, message, file change, or decision; and
- what happened after an error or incident was detected.
Logs alone are not enough if no one can interpret them. A defensible record connects technical events to business authorization and human responsibility.
This is also where privilege planning matters. Legal teams should decide which reviews need legal advice, while recognizing that ordinary operating logs and business records will not become privileged merely because lawyers care about them.
What Companies Should Do Before Agents Act At Scale
Companies do not need to resolve every future liability question before using AI agents. They do need to make responsibility visible.
Start with an inventory of agents that can take external action or change a system of record. Assign a named business owner and technical owner. Separate low-risk assistance from consequential execution. Use individual agent identities where possible, keep permissions narrow, and require approval for actions that are hard to reverse.
Test the full workflow rather than the model in isolation. That includes credentials, retrieved data, connected tools, fallback behavior, error handling, and the ability to stop the agent.
Review vendor terms against the actual use case. A general-purpose AI contract may not address payment authority, regulated decisions, customer communications, or the evidence needed after an incident.
Finally, preserve a record that connects authorization to action. If the company cannot show who approved the agent, what it was allowed to do, and what it actually did, the responsibility question will be answered from fragments after the dispute begins.
Bottom Line
AI agents can act with less immediate human involvement. They do not act outside the legal relationships created by the people and organizations that build, configure, authorize, and use them.
California AB 316 makes one part of that principle explicit: a defendant cannot avoid a case simply by asserting that the AI autonomously caused the harm. Other defenses remain, and responsibility may be divided among several parties.
The practical question is therefore larger than "who clicked the button?"
Who gave the agent authority? Who controlled its permissions? Who understood the risk? Who could have prevented the act? And who can prove those answers from a coherent record?
Those questions are likely to decide many of the first serious AI-agent disputes.