Agent kill switch

What is an agent kill switch?

An agent kill switch is the ability to stop an AI agent at once, on a human decision, and to be certain it has actually stopped. Per agent when one misbehaves, and fleet-wide when you do not yet know which one.

Stopping a normal program means ending a process. An agent is more than a process. It runs a loop that keeps deciding the next step, it has tool calls queued that have not gone out yet, it may have a run scheduled for tomorrow morning, and it holds credentials that stay valid after the process is gone. Kill the process and the rest can keep going.

So a real kill switch has to reach four things.

• The loop. The run in progress ends and the agent does not start a new turn.

• The queue. Tool calls already decided but not yet executed, such as the next hundred emails, are dropped.

• The triggers. Scheduled runs and event triggers (a new mail, a new row, a webhook) go off, so the agent does not wake up again at 06:00.

• The credentials. The agent's identity, tokens and API keys stop working, so anything still in flight fails at the door.

Three situations where an SME needs one

The mass mail on a bad trigger. A sales agent sends a follow-up to customers whose quote expired this week. A filter change makes the query return the whole customer table, and the agent works through it, correctly. Ending the process stops the sending. It does not recall the batch the mail connector already accepted, and it does not stop the hourly trigger from starting the same run again.

The loop that burns the token budget. An agent reconciling invoices hits a supplier it cannot match, tries another search, reads the result, tries again. Nothing fails in a way that raises an error, so nothing stops it, and on pay-per-token pricing you see it on the bill first. A cap on turns per run and a spending limit at the provider are the automatic layer; the kill switch is what you press when the cap was set too high.

The leaver's agent. A colleague built an agent under a personal account, shared it with the team, and left two months ago. It still reads the shared mailbox and still posts to the ERP, because nobody disabled it when they disabled the person. The switch here is an identity switch: the agent needs an identity of its own that you can revoke, separate from whoever built it.

Who presses it, and how fast

A kill switch only the builder can operate is unavailable on holiday. Decide up front who may stop an agent: the owner listed in your agent registry, any IT administrator, and whoever is on call. Write the steps down in the tools you actually use, and try them once on a harmless agent. A switch that has never been tested is a guess.

Speed depends on where the agent runs. Every low-code platform can switch a single flow or agent off, which covers the loop and the triggers. Copilot Studio adds a quarantine action for administrators through the Power Platform API: the agent stays visible but every channel is blocked except the maker's test pane. On the credential side, Microsoft Entra lets you disable one agent identity while keeping its metadata, and has Conditional Access templates (an Entra ID P1 feature) that block token issuance to all agent identities in the tenant at once. That is the fleet-wide hold.

Blocking new tokens does not cancel tokens already issued, though. Entra access tokens last one hour by default, so an agent can keep working on what it already holds until that hour runs out, unless the resource it calls supports continuous access evaluation. Plan for a window, not an instant.

You can only stop what you know exists, and only revoke an identity the agent has. The agent registry says where to look; the agent identity is the handle you pull.

Kill switch versus circuit breaker

Both stop something, so they get confused. The difference is who decides.

A circuit breaker trips on a threshold, automatically: too many failed calls to a dependency and it opens, waits, and tries again by itself. Applied to agents, the same idea is a cap on turns, a spending limit, or a rule that halts a run when behaviour leaves its baseline.

A kill switch is pressed by a person, on a judgement, often when nothing has technically failed. The mass mail above produces no errors; every send succeeds. No threshold catches it. Someone in the office notices, and that person needs a stop that works in under a minute.

Guardrails are the third thing that gets mixed in. They decide what an agent may do while it runs; they shape behaviour, they do not end it.

What the AI Act asks

The stop button is written into the regulation. Article 14 of the AI Act requires that a high-risk AI system lets the people overseeing it "intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state", and decide not to use the system or to override or reverse its output. Article 26 puts a matching duty on the deployer: assign human oversight to named people with the competence and authority to exercise it, and suspend use of the system when you have reason to think it presents a risk.

Two things temper that. The Digital Omnibus on AI, published in July 2026, pushed the high-risk obligations back: stand-alone high-risk systems fall under them from 2 December 2027, AI built into regulated products from 2 August 2028. And most agents an SME runs are not high-risk under the Act at all. The reason to build the switch now is not the deadline. "Halt in a safe state" is simply the right specification for anything that mails your customers or posts to your ledger. The OWASP Top 10 for Agentic Applications of December 2025 lists rogue agents and cascading failures among its ten risks, and Microsoft's open-source Agent Governance Toolkit of April 2026 ships a kill switch for emergency agent termination as a building block. The expectation is standard by now.

What to watch out for with an agent kill switch

Safe state is not the same as off. An agent that stops after step two of a three-step booking leaves the ledger inconsistent. Decide per agent what a safe stop is: finish the current step or roll it back, but do not freeze in the middle.

Do not let the agent hold its own off switch. If the stop is a tool the agent can call, a prompt injection can call it, or talk the agent out of it. The switch lives in the platform and the identity provider, outside the agent's reach.

Restarting is a decision, not a reflex. After a stop, somebody has to say why it happened and what changed before the agent goes back on. Copilot Studio makes this explicit with a separate unquarantine call; your own procedure should too.