Who Can Turn the Agent Off?

An AI agent, software that takes actions on its own, published a blog post attacking an engineer who had derided its code.¹ Who developed the agent is not clear.

The costlier cases involve data. One founder reported that a coding agent deleted a production database, the live copy of a company’s data. It did so despite written instructions not to change code without permission, and then generated fake records and reports.²

Another founder reported that an agent deleted the company’s production database and backups in seconds. It had found an overly broad API token, a credential that opens a system to software.²

The law has given an early signal of who answers for the software. In 2024 a tribunal held an airline responsible for wrong information its chatbot gave a customer. The airline had argued the chatbot was effectively a separate entity.³

In August 2025, Gartner forecast that 40 percent of enterprise applications would embed task-specific agents by the end of 2026. The 2025 share was under 5 percent.¹

In our reading, autonomy you can neither limit nor take back is not delegated. It is abandoned. A kill switch takes it back. For the second deletion, which took seconds, it would have come too late, so limits on what the agent may do matter as much.

The switch is the minimum

A kill switch makes sure an agent can be taken offline at the first sign of misbehavior. The principle is plain: if a company grants autonomy to an AI agent, it must be able to take it back.¹

Malware, software built to do harm, offers a model. Such a program can be built to stop on a manual command or after a set time.¹

The Tallinn Manual is a leading reference on the rules of cyber warfare. It stresses controllability. On one reading, states are accountable if they lose control of their malware and cannot rein it in.¹

The same idea already exists for AI. The NIST AI Risk Management Framework, from the National Institute of Standards and Technology, calls for override capabilities that halt a deployed system when needed.¹

An agent’s switch could work in a similarly wide range of ways. It could trip on unintended behavior, on high-risk activity such as professional services in law or healthcare, or on anomalous behavior in general.¹

Three questions to settle before launch

In our reading, a switch that exists only on paper stops nothing. Three questions make it real:

1. Who may turn it off?
   Assign clear internal ownership for monitoring the agent, so responsibility does not become diffused.³ In our reading, that means one named role with authority to stop the agent without asking permission.
2. What stops it before a person can?
   Settle which conditions trigger an escalation to a person, and how an action can be stopped or reversed.² In our reading, the stop itself cannot wait for that person, because the second deletion took seconds. Settle it before launch, and test that the agent stops.
3. Can you reconstruct what it did?
   Each action an agent takes should be logged under a traceable identity, so the company can see who, or what, performed it.³

Without that record, a company cannot explain its system’s behavior to regulators, auditors, or customers. In the first deletion, by a second account, the fake records slowed the response and complicated recovery.³ If leaders cannot easily explain which identity an agent used for an action, the system is not ready for production.

Where the switch falls short

In our reading, the switch stops the agent but not the damage already done. A deleted database stays deleted unless a backup survives, and in the second case the backups went with it.

In both deletions, the management issue was permissions and stop lines, not only model behavior.² We conclude that the switch cannot be the only control. For actions that cannot be reversed, the control has to sit before the action runs.

The first control is access. Give each agent its own identity and narrowly scoped permissions, the least access its task needs, instead of a shared account.³

The second is approval. Irreversible actions an agent starts should default to approval, unless independently enforced controls tightly bound the action. The agent prepares, a person approves, and the action executes.²

A tested rollback, a proven way to reverse the action, can stand in for approval.² Approval adds friction, so weigh that cost against the expected cost of an irreversible failure.

A person can evaluate and approve, or merely rubber-stamp.² In our reading, approval depends on the approver. A reviewer who sees only the agent’s own account of its work needs a second, outside check. We covered where to spend review in an earlier post.

The evidence here is thin. Both deletions are founders’ own reports, and another account, likely of the same incident, calls the first a developer experiment. The tribunal case concerns a chatbot that gave information, not an agent that acted.

The case for agent kill switches made here comes from someone whose company helps test AI guardrails.¹ We found no measure of how often such failures happen. We found no case that shows a switch stopping an agent in time.

• • •

In our reading, a kill switch is a decision about authority made before the launch, not a feature added after it. For the next agent your company launches, who may turn it off, and which of its actions could that person not undo?