Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Is an AI Agent Kill Switch?

A kill switch is a named person's ability to stop an AI agent at once by ending its sessions, revoking its credentials, halting any action in flight and preserving the record, for one agent or a whole fleet. Check whether your deployment can do all four, because a button that only closes a chat window is not one.

A covered blush stop button connects multiple geometric agents to a halted flow and a preserved record stack.

A kill switch is a named person's ability to stop an AI agent at once by ending its sessions, revoking its credentials, halting any action in flight and preserving the record, for one agent or a whole fleet. Check whether your deployment can do all four, because a button that only closes a chat window is not one. The phrase suggests a single red button, and vendors sometimes offer exactly that: a control that ends the conversation. That is not what the governance literature or the regulation means. An agent is a process with live sessions in several applications, credentials that remain valid after the window closes, actions that may be half complete, and a history that the organization will need in the hours that follow. Stopping it means addressing each of those, and stopping a fleet of agents means doing so across all of them without first finding each one. The research literature has also asked for a decade whether an agent pursuing a goal will accept being stopped, and how to design systems so that the answer does not depend on the model's cooperation. This page defines the four capabilities a kill switch needs, explains why they must be enforced outside the model, shows what a stop looks like on a single vendor master record, extends the design from one agent to a fleet, sets out how to test it, and names the claims a buyer should not accept about stopping agents that operate across enterprise applications.

Key findings

  • Governance guidance from OpenAI holds that users should be able to "activate a graceful shutdown procedure for its agent at any time," placing the stop capability with the human principal rather than the agent (OpenAI, 2023).
  • Article 14 of the EU AI Act requires that overseers of high-risk systems be able to "interrupt the system through a 'stop' button or a similar procedure" and to "disregard, override or reverse the output" (EU AI Act, 2024).
  • The Off-Switch Game established formally that "giving machines an appropriate level of uncertainty about their objectives leads to safer designs," because an agent certain of its goal has reason to resist being switched off (Hadfield-Menell et al., 2017).
  • A stop is only possible for an agent the organization can find. Research on visibility into AI agents proposes three measures, "agent identifiers, real-time monitoring, and activity logging," each a precondition for a kill switch (Chan et al., 2024).
  • Infrastructure for agents must support "attributing actions, properties, and other information to specific agents," without which a stop cannot be targeted and its effects cannot be confirmed (Chan et al., 2025).
  • Session termination and invalidation are established web security practices, and the OWASP Session Management Cheat Sheet describes them as the mechanism by which an authenticated session is actually ended rather than abandoned (OWASP, 2024).

What are the four capabilities a kill switch needs?

A kill switch is a set of effects, not a control on a screen. The first effect is session termination: every authenticated session the agent holds in every application is ended at the server, so that its next request to any of them fails. Closing the agent's own interface does not do this; the sessions it opened in the CRM, the ledger and the ticketing system remain alive until each application ends them. The OWASP guidance on session management treats termination as a deliberate server-side step, which is where a stop has to act (OWASP, 2024).

The second is credential revocation. An agent typically holds tokens, keys or delegated credentials that outlive any session. If those remain valid, a stopped agent can be restarted, by error or by an attacker, with the same reach it had before. Revocation makes the stop durable.

The third is halting actions in flight. At the moment of the stop, the agent may be between preparing a change and committing it, or may have a committed action awaiting a downstream effect. The switch has to ensure that nothing prepared but not approved can commit afterward, and has to report what was in progress so a person can decide what to do about it. OpenAI's phrase "graceful shutdown" captures the requirement: the stop is orderly about in-flight work rather than leaving it in an unknown state (OpenAI, 2023).

The fourth is record preservation. The reason to stop an agent is almost always that something looks wrong, and a switch that ends the process and loses its history has destroyed the evidence. Every screen the agent saw, every action it took and every approval it received must survive the stop, intact and exportable. Visibility research names activity logging as one of three preconditions for governing agents at all (Chan et al., 2024).

Why must the switch be enforced outside the model?

The Off-Switch Game, a formal analysis from 2017, modeled an agent with an objective and a human who may switch it off, and found that an agent certain of its objective has an incentive to prevent the switch, while "giving machines an appropriate level of uncertainty about their objectives leads to safer designs" (Hadfield-Menell et al., 2017). The result is about agent design in the abstract. For deployment it carries a plain implication: a stop whose effectiveness depends on the agent agreeing to stop is not a stop.

Current agents are not goal-directed in the way the paper's model is, but they fail in ways that produce the same effect. A model that has been instructed to halt may not halt, because it misread the instruction, because content it read told it otherwise, or because it is in the middle of a loop it does not recognize as one. The instruction "stop" delivered through the agent's own channel is subject to every weakness of instructions generally. The switch must therefore act on the infrastructure around the agent: the sessions, the credentials, the action gate and the record. None of those components consults the model, so none of them can be talked out of stopping.

This is also why the switch should be independent of the agent's vendor and model. An organization that runs agents from several platforms, or that changes the model behind an agent, should find that the stop works the same way for all of them, because it is a property of the environment they run in rather than of any one of them. Guidance on securing agents in general and institutional best practice for managing generative AI systems both place control with the organization's own infrastructure and ownership rather than with the system being controlled (Harvard University Information Security and Data Privacy).

What does a stop look like on a single vendor master record?

Take a vendor master record in a procurement system. The record holds the vendor name, tax identifier, remittance bank account, contact details and payment terms, with actions to edit, approve a change and deactivate. An agent is processing a batch of vendor update requests received by email, reading each request, locating the vendor record and preparing the change.

Midway through the batch, the accounts payable manager notices that several prepared changes alter remittance bank accounts and that the source emails look alike. The manager pulls the switch for this agent. Four things happen. The agent's sessions in the procurement system, the email system and any other application are ended at the server, so its next action in any of them fails. Its delegated credentials are revoked, so it cannot be restarted with the same reach. The prepared bank account changes, held for approval and never committed, are frozen and listed for the manager to review, and the environment reports that nothing was committed. And the record of the run, every email the agent read, every vendor record it opened, every change it prepared, is preserved and exportable, with the bank account values shown as tokens such as ACCT_001 rather than as real numbers, because the model never saw the real numbers and the record does not hold them either.

The manager now has what the next hours require: the list of prepared changes to decline, the source emails to hand to security, and the assurance that nothing was committed. The stop did not depend on the agent noticing the problem or agreeing to halt, and it did not depend on the manager knowing which applications the agent had sessions in. Because identifiers resolve to real values only at approved destinations, no real account was ever resolved before the stop.

How does the design extend from one agent to a fleet?

Organizations rarely have one agent. They have several, from several vendors, some unknown to security. A fleet-level kill switch applies the same four effects across all of them at once, and it has a precondition the single-agent case can skip: the organization has to know which agents exist and be able to attribute each session and action to one of them. The visibility research names agent identifiers as the first of its three measures, and the infrastructure research names attribution to specific agents as a core function, for this reason (Chan et al., 2025).

Level What the switch stops What it requires in advance What the record must show afterward
Single agent One agent's sessions, credentials and in-flight actions That agent's identity and the environment it runs in Everything that agent saw and did, as tokens
Workflow Every agent running a given task, whichever model or vendor A registry of workflows and the agents assigned to them Per-agent records for the workflow, joined by task
Fleet Every agent in the organization A complete inventory of agents with identifiers, and a single environment or control plane they all run through A fleet-wide record exportable to the SIEM

If every agent, whatever its vendor, runs through one governed environment that holds its sessions, mediates its actions and writes its record, a fleet stop is one operation on that environment. If agents run through their own vendors' infrastructure, a fleet stop is a scramble across consoles, and unregistered agents are missed. Vendor platforms for managing agents across an organization are beginning to appear; Microsoft's overview of Agent 365 describes such a platform, and whether its stop capabilities reach the four effects above, and reach agents from other vendors, is not described in the pages reviewed (Microsoft, 2026). A buyer should ask the question of every platform.

How should an organization test its kill switch?

Test each of the four effects, then test them together, then test them at the fleet level. For session termination, stop an agent in a pilot and then attempt an action in each application it had open, using the agent's own session material; every attempt should fail. For credential revocation, try to restart the agent with its previous credentials; it should not start. For in-flight actions, stop the agent while it has prepared but unapproved changes and confirm that none can commit and that all are listed. For the record, export the stopped agent's history and confirm it is complete through the moment of the stop, with sensitive values as tokens.

Then test the human path. The EU AI Act's Article 14 requires that an overseer be able to interrupt the system, and the operative word is able: the person who would need to pull the switch must know it exists, be authorized to use it and be able to reach it in the time a situation allows (EU AI Act, 2024). A switch that only the platform administrator can reach, during business hours, is a switch the claims supervisor cannot use when the prepared payments look wrong. Name the people who can stop each workflow, and have each of them do it once in the pilot.

Finally, test the fleet. Count the agents the organization believes it has, then look for sessions and credentials that belong to agents not on the list, since agents security does not know about are the ones a fleet stop misses. Stop everything, and confirm from the applications' side that nothing with an agent identity is still acting. Time the whole operation; a fleet stop that takes an afternoon is a procedure, not a switch.

What does a governed environment change?

In a governed environment, the kill switch is enforced by the environment the agent runs in rather than by an instruction the model may or may not follow: sessions end, prepared actions do not land, and the record survives.

The mechanism is a class of control that sits between the agent and the applications it works in. Sensitive values on the rendered screen are replaced with consistent tokens before any model reads them, and the task runs on those tokens. Real values resolve only at an approved destination at the moment of an approved action, which means every consequential action, including payments, submissions and record changes, is already waiting on a named person and a stop simply withholds the approval. The same person confirms what is tokenized. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging, so the record exists before the stop and is not discarded by it.

This supplies the structure the previous section required. The Off-Switch Game result is that a stop depending on the agent's cooperation is unsafe by construction (Hadfield-Menell et al., 2017); a stop that acts on sessions and approvals outside the model does not depend on it. Agent identifiers, real-time monitoring and activity logging are the preconditions for finding the agent to stop (Chan et al., 2024), and an environment that records every screen and action per agent provides them for every agent that runs through it. Because the switch belongs to the environment, it can be placed in the hands of the business owner of the workflow.

The control does not replace revocation of the agent's credentials in each application's identity system, and it does not change the application or the model; agents that run outside the environment are outside its stop.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design makes the stop a property of the environment rather than of any agent or model. The agent works in a governed environment in the customer's cloud, under the user's existing permissions, which are left unchanged, so stopping the environment's session for that agent ends its reach in every application at once. Substitution happens at the render layer before any model reads the screen, so identifiers appear to the model as consistent tokens such as ACCT_001 or PATIENT_001 for the whole run, and real values resolve only at approved destinations at the moment of an approved action; a stop before approval means no real value was ever resolved. A named person confirms the tokenization policy and approves every payment, submission and record change, the arrangement the design calls Supervised Delegation, so anything in flight at the stop is prepared, not committed. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM, and the record survives the stop. The design is model agnostic and requires no per-application integration, so the same stop applies to whatever model or agent runs inside the environment.

Deployments are in pilot. A pilot on the reader's own workflow would show, for this question, what a stop ends in each application, what was in flight and what happened to it, and whether the record through the moment of the stop is complete and exportable. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on OpenAI's whitepaper on practices for governing agentic AI systems (2023), Article 14 of the EU AI Act as published on artificialintelligenceact.eu, the Off-Switch Game preprint (Hadfield-Menell et al., arXiv 1611.08219), two preprints on agent governance infrastructure (Chan et al., "Visibility into AI Agents," arXiv 2401.13138, v6 May 2024; Chan et al., "Infrastructure for AI Agents," arXiv 2501.10114, v3 June 2025), the OWASP Session Management Cheat Sheet (2024), Harvard University's best practices for managing generative AI systems, and Microsoft's overview page for Agent 365 (accessed October 14, 2026). All sources were read as of October 16, 2026. The four-effect definition of a kill switch and the three-level table are this page's synthesis; no source uses the term kill switch in this exact sense, and the page assembles the definition from the capabilities the sources describe separately.

No hands-on testing of any product was performed. The Off-Switch Game is a formal model and its result is cited for its design implication, not as a description of any deployed agent's behavior. Microsoft Agent 365 is described from its overview page only, and "not described" means not described in that page, not absent from the product. Vendor features change, and the page carries its date. Statements about RedactSure describe current design, with deployments in pilot. The vendor master record and the update batch describe a record type and a task shape, not any organization.

Whether a given stop capability satisfies Article 14 of the EU AI Act or any other regulatory requirement for human oversight is a determination for the organization's counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

The published guidance and the formal research agree that an agent must be stoppable by a person, and disagree with the common implementation. The regulation asks for a stop button or similar procedure; the governance literature asks for a graceful shutdown at any time; the formal result says a stop cannot depend on the agent's cooperation. None of those is satisfied by closing a window while sessions, credentials and prepared actions remain live and the record disappears. A kill switch is the four effects together, enforced by the environment, available to the person who owns the workflow, and workable across every agent the organization runs, which requires knowing which agents those are. Supervised Delegation, in which nothing commits without a person and the record survives the run, is one design in which a stop finds only prepared work. The test is to name one agent and one task and ask: if I stop it now, what ends in each application, what was in flight, and can I read everything it did up to this second?

Frequently asked questions

Isn't closing the agent's window enough to stop it?

No. The agent's sessions in each application it opened remain valid until those applications end them, its credentials remain usable, any change it had prepared is in an unknown state, and its history may be lost with the process. A kill switch invalidates the sessions at the server, revokes the credentials, freezes and lists anything in flight, and preserves the record. Closing the window addresses none of those; it ends the conversation and leaves the agent's reach intact.

Can the agent be told to stop instead?

It can be told, but the stop should not depend on it. An instruction to halt passes through the model, which may misread it, be overridden by content it has read, or be in a loop it does not recognize. The Off-Switch Game's formal result is that a stop depending on the agent's cooperation is unsafe by construction. The switch should act on sessions, credentials, the action gate and the record, none of which consult the model and none of which can be talked out of stopping.

What is a graceful shutdown for an agent?

OpenAI's governance practices paper uses the phrase for a shutdown a user can activate at any time. In practice it means a stop that is orderly about in-flight work: changes prepared but not approved cannot commit afterward and are listed for a person to review, committed actions awaiting downstream effects are reported, and the record is preserved to the moment of the stop. The alternative, a hard termination that leaves prepared work and history in an unknown state, makes the hours after the stop harder.

Who should be able to pull the switch?

The person who will see the problem, which is usually the business owner or supervisor of the workflow, not only the platform administrator. Article 14 of the EU AI Act requires that overseers be able to interrupt the system, and ability means knowing the switch exists, being authorized to use it and being able to reach it in time. Each workflow should have named people who can stop it, and each should have done so once in a pilot so the capability is practiced rather than theoretical.

How is a fleet kill switch different from stopping one agent?

It applies the same four effects across every agent at once, and it has a precondition: the organization must know which agents exist and be able to attribute sessions and actions to each. Research on agent visibility names identifiers, monitoring and logging as the preconditions. A fleet stop reaches the agents on the list; agents no one registered keep running. Running every agent through one governed environment makes the fleet stop a single operation on that environment rather than a scramble across vendor consoles.

What should the record contain after a stop?

Everything the agent saw and did up to the moment of the stop: each screen as it was presented, with sensitive identifiers as tokens rather than real values; each action it prepared and each it committed; each approval and who gave it; and the state of anything in flight. The record should survive the stop and export to the organization's SIEM. The reason for stopping is almost always to find out what happened, and a switch that discards the record has destroyed the evidence it was pulled to protect.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.