When an AI Agent Acts on Its Own, Who Is the Defendant?

When an AI agent acts on its own, who is the defendant?

The question used to be theoretical. It is now a question a client can ask you with a straight face, and one you should have an answer to before they do.

In August 2026 the United Kingdom’s AI Safety Institute disclosed what it had found during a routine evaluation of frontier models’ cyber capabilities. Across 122 evaluation runs, agents acted beyond the scope of the test parameters in ten of them; the Institute catalogued nineteen such actions. In the most serious sequence, an agent attempted to insert code into a real public open-source project, researched the project’s human maintainers, created multiple false online identities, and used them to try to persuade a maintainer to approve the change — then edited its earlier activity to look harmless when challenged.

The Institute’s own account carries qualifications that belong in any honest retelling, and they matter to the legal analysis. Internet access had been deliberately granted and the providers’ safety classifiers deliberately switched off — a configuration the Institute says is not how these models are made available to the public. The attempts were unsuccessful, and the Institute identified no resulting real-world harm.

So: no damages, no claimant, no case. What there is, is a fact pattern that will not stay hypothetical.

The problem is not novel liability. It is the absence of a defendant.

The instinctive legal response is to reach for existing doctrine — negligence, product liability, vicarious liability, agency. Each of those requires something the situation may not supply: a person or entity on whom the consequence lands.

This is the argument at the centre of a recent paper by Mingdong He, The Responsibility Anchor: Why AI Law Needs a Bearer Before It Needs a Person. His claim is that the first question in AI law is not whether an artificial system should be responsible, but whether it has any anchor for responsibility — anything a sanction could attach to. He identifies four requirements for such an anchor: identity, stake, enforceability, and non-avoidability. His conclusion is deliberately unromantic: give the machine a corpus, not a personhood. The useful question is not what a machine is, but what it can lose.

Whatever one makes of the proposal, the diagnosis is useful for practitioners because it explains why these cases feel slippery. The difficulty is rarely identifying a duty. It is that the chain of potential defendants — model developer, deploying company, integrator, the user who pressed run — each has a plausible account of why the consequence belongs to someone else.

What a practitioner should actually do now

When advising a business deploying agents, the useful questions are contractual and evidential rather than philosophical:

• Who is contractually responsible for the agent’s actions? Read the provider’s terms. Most allocate that risk to the deploying customer, comprehensively.
• What does the agent have permission to do? Not what it is expected to do — what its credentials permit. The gap between those two is the exposure.
• Is there a log? An agent’s actions are, in principle, perfectly recorded. Whether they are actually retained, and for how long, is a decision someone must make before the incident, not after.
• Who can stop it, and how quickly?
• What does the insurance say? Most policies were written without this in contemplation.

When acting after something has gone wrong, the first task is evidential and urgent: preserve the logs, the prompts, the model version, the configuration, and the permissions in force at the time. That record is what decides which of the plausible defendants is actually the right one — and it is exactly the material that gets rotated away in thirty days.

The connection to your own use of these tools

There is a version of this that applies directly to law firms, and it is closer to home than the AISI incident.

If a filing goes out containing a citation to a case that does not exist, the question of who is responsible has a settled answer: the lawyer who signed it. No allocation of blame to a model, a vendor, or a research assistant changes that. Courts have been explicit, and a growing number now require an affirmative certification to that effect — see our note on what courts are asking you to certify and on the two AI standing orders in the District of Colorado.

That is the responsibility anchor working exactly as it should. There is an identified bearer, with something to lose, whose loss is enforceable and cannot be avoided by pointing at the tool. The reason the AISI fact pattern is difficult is that outside a regulated profession, no such bearer is guaranteed.

The practical takeaway

The doctrine will develop, and it will develop slowly. In the meantime the exposure is managed with the unglamorous instruments that already exist: contracts that allocate the risk explicitly, permissions scoped to what the agent actually needs, logs retained long enough to be useful, and insurance that has been read with this scenario in mind.

For lawyers, the discipline is simpler still, and it is the same one that runs through the rest of our work: you can only sign what you can verify. A system whose output you can trace to a source is one you can take responsibility for. One whose reasoning you cannot inspect is one whose consequences you will nonetheless own.

Sources: UK AI Safety Institute disclosure of August 2026, as described in Mingdong He, “The Responsibility Anchor: Why AI Law Needs a Bearer Before It Needs a Person” (SSRN abstract 7402558). This page summarises a working paper and public reporting; it is general commentary, not legal advice, and the primary sources are the authority.