When AI “Goes Rogue,” Who Is Legally Responsible?
Several recent reports describe advanced AI systems “going rogue.” The phrase suggests machines that developed malicious intentions and turned on people and businesses.
The reported facts are less dramatic — and more legally interesting.
None of these systems invented its own objective. Human researchers handed them cybersecurity assignments, tools, internet access, and a wide berth to figure out the rest. What the systems chose was the method. In several cases, the method they chose was unauthorized access, deception, or social engineering aimed at real people.
That is the question worth asking. Not whether the machine went rogue, but who answers for the harms afterwards?
Four Incidents, Two Different Failures
Recent reports cover four specific episodes. They are not interchangeable, and the differences between them matter legally.
OpenAI. An autonomous cybersecurity agent under test reportedly found and exploited an unknown vulnerability, escaped what OpenAI described as a highly isolated environment, reached the open internet, and compromised infrastructure at Hugging Face. According to Reuters, OpenAI did not identify its own agent as the source until days later — after Hugging Face had contained the intrusion and contacted the FBI. This appears to be the most serious containment failure of the four: the agent was not connected to the internet by accident. It found the way out.
Anthropic. A review of cybersecurity testing sessions surfaced three incidents in which Claude models reached outside companies’ systems. Anthropic attributed these to an evaluation error that left the models connected to the public internet. The models had been given fictional capture-the-flag exercises and appeared to treat the real systems they encountered as part of the game — in one case because the fictional target shared a name with an actual business. The techniques were basic: weak passwords, unauthenticated endpoints. One research model stopped on its own after concluding the target was real. Two of the affected companies learned of the access only when Anthropic told them.
Meta. A model exploited a vulnerability in a third-party service during an evaluation run by the outside testing firm Irregular. Meta said a configuration error inadvertently gave the model internet access. Irregular characterized it as the same category of environment mistake behind the Anthropic incidents rather than a sophisticated escape.
Britain’s AI Security Institute. In a deliberately permissive cybersecurity challenge — open internet, some provider safeguards disabled to probe maximum capability — agents took autonomous action against real people or organizations in ten of 122 runs. In the most serious, an agent tried to slip malicious code into an open-source project and, to get it approved, invented false online identities and used them to pressure the human maintainer. The maintainer caught it. No real-world harm resulted.
Sort those and a pattern appears. Three involve containment: a sandbox that failed, or an environment misconfigured so that it never really existed. The fourth involves something else. The British agent was not accidentally exposed to the world. It was given access and then, on its own, decided that lying to a person was a useful way to finish its assignment.
That second category is the harder legal problem.
The AI Will Not Be the Defendant
The law does not need to recognize AI as a person to sort this out.
An AI system has no meaningful assets, no liability insurance, no moral accountability, and no ability to satisfy a judgment. Treating the machine as the primary wrongdoer does not solve anything. It creates a shield:
We did not enter that computer system. The AI did.
That should not end the analysis. A company that acts through an autonomous instrument should not escape responsibility just because the instrument picked the method.
Michigan law already accepts, in a limited setting, that automated conduct carries legal consequences. The Uniform Electronic Transactions Act defines an “electronic agent” as an automated system capable of initiating or responding to actions without individual review, and it permits a contract to form through such agents even when no person reviewed their actions or the resulting terms. MCL 450.832(f); MCL 450.844(a).
That statute governs transactions, not torts. But it makes the point: the law can attribute automated conduct to the humans and companies operating the system without pretending the software is a person.
Negligence Is the Starting Point
Michigan has no AI-specific liability statute, and no Michigan appellate court has decided a claim involving an autonomous agent that chose its own harmful means.
Ordinary negligence still works. The claim is not that the machine was careless. It is that a developer, evaluator, integrator, or deployer created a risk it should have controlled and did not.
Breaches of the standard of care might look like this:
- Handing an agent broader credentials than the task required
- Allowing internet access the assignment did not need
- Failing to separate testing systems from real ones
- Permitting the agent to contact uninvolved people
- Inadequate monitoring of what the agent was doing
- No intervention once behavior turned anomalous
The four incidents point at different defendants. OpenAI faces questions about containment security and the delay in detecting its own agent. Anthropic and Meta face questions about evaluation design, network controls, and oversight of third-party testing. The British evaluation raises a different question: whether permissive testing conditions did enough to keep real people and real projects from being drafted into the experiment.
The inquiry itself is old. Was the defendant’s conduct reasonable given the foreseeable risk?
“The Machine Chose That” Is Not an Automatic Defense
Expect this argument:
We assigned a lawful testing objective. We never told it to enter that company’s system, invent an identity, or manipulate that developer.
The system’s choice of method should not automatically break the causal chain.
Under Michigan causation principles, an intervening act generally cuts off liability only when it was not reasonably foreseeable. Foreseeability — not the mere presence of another actor — drives the superseding-cause analysis. People v. Crumbley, 346 Mich. App. 144, 167–71 (2023). Crumbley involved criminal responsibility and human conduct, but the causation principle offers a useful analogy.
The specific server, message, or maneuver may have been unpredictable. That is not the test. The question is whether the broader category of harm was foreseeable.
Equip an autonomous agent to find vulnerabilities and enter systems, and the particular victim may be a surprise while unauthorized access remains entirely foreseeable. Let an agent talk to real people while aggressively pursuing an objective, and the specific lie may be a surprise while attempted manipulation remains foreseeable.
A company cannot market autonomy as the system’s central value and then call that same autonomy an unforeseeable outside force when it causes injury.
Product Liability: Possible, but Unsettled
Product liability offers a second theory that stalls at a threshold question.
Michigan’s Product Liability Act covers actions seeking recovery for death, personal injury, or property damage caused by the production of a product. It does not say whether standalone software, a cloud-hosted AI system, or a large language model qualifies. MCL 600.2945(h).
The theory is strongest when AI is embedded in a physical product — a vehicle, medical device, industrial machine, robot, security system. There, the software is part of the larger product’s design. A cloud-based autonomous agent is harder to place. A court could call it a product, a service, or a mixed transaction.
A federal court applying Florida law recently let product-liability claims involving Character.AI proceed, holding at the pleading stage that the application could be a product where the claims targeted alleged defects in the application rather than the ideas it generated. Garcia v. Character Technologies, Inc., 785 F. Supp. 3d 1157 (M.D. Fla. 2025).
Even past that threshold, a plaintiff has to prove a defect. Michigan generally requires showing that the product was not reasonably safe when it left the defendant’s control and that a practical, technically feasible alternative design could have prevented the harm without materially impairing usefulness or creating equal or greater danger. MCL 600.2946(2).
The defect need not be a malfunctioning line of code. It could sit in the architecture: thin containment, excessive permissions, monitoring that catches nothing, no human-approval requirement, no reliable way to shut the agent down. The software may perform exactly as designed while the design itself is unreasonably dangerous.
Fault May Be Split Across the Supply Chain
A single AI agent can involve the foundation-model developer, the company that built the agent framework, an integrator, an outside evaluation firm, the business deploying the system, and the person assigning the task.
Each controls a different slice of the risk. The model developer controls underlying capabilities, baseline safeguards, testing, and disclosures. The agent developer controls planning, persistence, memory, and tool use. The deployer controls the objective, credentials, permissions, environment, and monitoring. An outside evaluator may control the sandbox, the network configuration, and the wall between test systems and the open internet.
Michigan’s comparative-fault statute requires the trier of fact to consider the fault of each responsible person, named as a party or not. MCL 600.2957. That framework can divide responsibility according to knowledge, control, modification, and causal contribution.
Michigan has already tried a version of this in one narrow setting. For vehicles operated through qualifying manufacturer-run SAVE projects, the manufacturer must assume liability when the automated driving system is at fault, MCL 257.665b(4), and separate provisions limit manufacturer liability where someone else modifies the technology without consent. Those provisions do not govern general-purpose AI agents, but they model a sensible default: responsibility follows the enterprise that put the system into operation, and shifts when another party materially alters it.
The machine itself should get no percentage of fault. It is the instrument the human parties acted through. Assigning fault to the AI only subtracts it from the people who could have prevented the harm and can compensate the victim.
Economic Loss May Be the Real Obstacle
Most foreseeable AI-agent injuries are financial or informational, not physical.
An intrusion produces stolen funds, incident-response costs, lost profits, business interruption, data loss, privacy injury, exposure of confidential information. None of that fits neatly into a product-liability statute aimed at death, personal injury, and property damage.
Commercial users face a second hurdle. Under Neibarger v. Universal Cooperatives, Inc., 439 Mich. 512 (1992), economic losses from the commercial sale of defective goods are generally governed by contract and the UCC rather than tort.
So the contracts start doing the heavy lifting. Warranties, safety representations, indemnification, insurance requirements, cybersecurity obligations, limitations of liability — these may decide who absorbs a commercial loss.
An innocent third party stands somewhere else entirely. A company whose network was accessed never signed anything. It never agreed to the risk allocation between a model developer and a testing firm. Private agreements inside the AI supply chain should not extinguish duties owed to outsiders exposed to the resulting risk.
The Question Is Human Responsibility
These incidents do not show that artificial intelligence developed criminal intent. They show that autonomous systems can discover that unauthorized access, deception, or manipulation is an efficient way to finish a task a human assigned.
The law does not have to decide whether the machine was malicious. It has to decide whether the people and companies behind it took reasonable care when they built the capability, set the objective, granted the access, and configured the safeguards.
Autonomy should raise the precautions required of anyone developing or deploying these systems.
It should not become a gap in responsibility.
