A kill switch for an AI agent needs to stop it immediately across every path it has to act through, not just pause the interface a user happens to be watching while the agent keeps calling tools and making changes in the background. Emergency access, the ability for a specific person to intervene, override, or shut something down during an incident, needs its own tightly controlled process so it's available exactly when needed without becoming a standing, rarely reviewed privilege that sits there as its own risk the rest of the year. Both controls exist for the same reason: because prevention sometimes fails, and when it does, the speed and completeness of the response is what determines how bad the outcome actually gets.
What "stop" actually needs to mean
A kill switch that disables an agent's user-facing interface but leaves its service credentials, scheduled tasks, or in-flight tool calls still active hasn't stopped anything meaningful, it's stopped the part that was easiest to see. A real kill switch needs to revoke the agent's active credentials, halt any queued or scheduled actions, and terminate in-flight processes where that's technically feasible, not just take away the conversation window someone was looking at.
Designing for the incident you didn't anticipate
Kill switches tend to get built around the specific failure mode someone was worried about at design time, which means they sometimes don't cover a different failure mode that shows up later. Building the kill switch at the identity and credential level, rather than at a specific application feature level, gives broader coverage: revoking an agent's underlying access stops it regardless of which particular behavior triggered the concern.
Emergency access needs its own guardrails
Emergency access, a break-glass account or an elevated role available during incidents, is valuable precisely because normal approval processes are too slow for some situations. That same power makes it a target and a risk if it's left active outside of genuine emergencies. Emergency access should require its own authentication step, generate its own prominent audit record, and get reviewed after every use, specifically to confirm the use was actually warranted.
Who can pull the switch, and how fast
A kill switch that requires approval from three different people before it takes effect isn't really an emergency control, it's a slow process wearing an emergency label. Decide in advance who has the authority to trigger it unilaterally, under what conditions, and make sure that authority is actually usable under pressure, tested rather than assumed to work when the moment comes.
Testing the kill switch before you need it
The worst time to discover a kill switch doesn't actually stop everything it's supposed to is during a live incident. Run periodic drills: trigger the kill switch against a non-production agent, or during a scheduled test window, and confirm every path, credentials, scheduled tasks, in-flight calls, actually stops. Treat any gap found during that test as seriously as a gap found during a real incident, because it's the same gap, just discovered on a better day.
Recovery after the switch is pulled
Stopping an agent is only half the process. There needs to be a defined path for reviewing what happened, deciding what needs to change before the agent resumes, and re-enabling it deliberately rather than automatically once whatever triggered the shutdown seems to have passed. Restarting an agent without understanding why it was stopped risks recreating the same incident shortly after.
Communicating a shutdown to the people it affects
Pulling a kill switch stops the agent, but it doesn't automatically tell the users or teams relying on it what just happened or why. Silence in that moment tends to generate its own problems: confused users retrying the same action repeatedly, support tickets piling up with no context for the people answering them, and sometimes a well-meaning colleague spinning up a workaround that recreates the exact risk the shutdown was meant to contain. A predefined communication step, even a short, honest notice that the agent is temporarily disabled while an issue is investigated, prevents the shutdown from creating a second, avoidable mess on top of the first one.
Deciding in advance who sends that notice, and what it says under different scenarios, means it doesn't have to be improvised under pressure at the exact moment attention is needed elsewhere, on actually understanding and resolving whatever triggered the shutdown in the first place.
Where TELEON fits
Where an agent's tool calls pass through the TELEON gateway, policy enforcement can be used to block that agent's activity at the tool-call boundary as part of a kill switch response, and the audit trail records both the shutdown event and, importantly, whether any activity was attempted afterward. Building the full kill switch, including credential revocation and scheduled task termination across every system an agent touches, is broader infrastructure work beyond the gateway itself.
A short checklist
- Design the kill switch to revoke credentials and halt scheduled tasks, not just disable an interface.
- Build the kill switch at the identity and credential level for broad coverage across failure modes.
- Require a separate authentication step and generate an audit record for emergency access use.
- Review every emergency access use afterward to confirm it was genuinely warranted.
- Decide in advance who can trigger the kill switch unilaterally and under what conditions.
- Run periodic drills to confirm the kill switch actually stops every path it's supposed to.
- Define a deliberate review and recovery process before re-enabling a stopped agent.
A kill switch is one of those controls whose value is invisible until the exact moment it isn't, and by then there's no time left to discover it doesn't fully work. Testing it regularly, and building emergency access with the same discipline you'd apply to any other privileged credential, is what keeps an emergency control from becoming just another untested assumption sitting quietly in the architecture.