You run 200 customer-support agents in production, each capable of issuing refunds. A red-team report shows a viable injection chain. You have one hour to deploy a kill switch that suspends refund authority without taking the agents offline. Sketch the design.
Free · 2 AI evals / day
A **kill switch** lets you disable a dangerous capability fast without taking the whole product down. The trap is treating it as a code change or a prompt rewrite. Both are too slow and too risky in the middle of an incident.
The right shape is a config flag. Keep your tool registry (refund, cancel-order, escalate, etc.) in a runtime config store like LaunchDarkly, etcd, or a small KV the orchestrator polls. Each tool gets an enabled boolean. To kill refunds, you set refund.enabled = false. The change propagates to every agent process in seconds because the orchestrator reads the flag each time it dispatches a tool call.
The agents themselves keep running. If the model proposes a refund, the dispatcher intercepts the call, returns a templated message back into the conversation (refunds temporarily need human approval, a ticket has been opened), and pushes the case into a human queue. The customer sees graceful degradation, not an outage.
Log every blocked call with the user input and the retrieved context so you have evidence for the incident review. Test the switch every quarter so you know it works.
**Kill switch** in production agent terms is a per-tool config flag the orchestrator reads at dispatch time. Not a deploy. Not a prompt edit. A config flip that propagates in seconds.
The design: store your tool registry in a runtime config service (LaunchDarkly, ConfigCat, etcd, Consul, or an in-house KV that agent processes poll). Each tool entry carries an `enabled` boolean and optional scope (tenant allowlist, environment, region). The orchestrator checks the flag on every tool dispatch. When the red team finds an exploit on refunds, you flip `refund.enabled = false`. Within a few seconds, every agent in the fleet stops calling refund.
**Graceful degradation matters.** Agents stay online. When the model emits a refund tool call, the dispatcher short-circuits it and returns a templated tool-result that explains a human will follow up. A ticket is opened automatically. The customer keeps talking to the agent; the agent picks up the conversation from the new context.
**Evidence requirements:** every intercepted call is logged with the original model proposal, the user input, the retrieved context, and the rail decision. That log feeds the incident review and the regression test you write next.
And test the switch quarterly in a game-day exercise so you know the propagation latency before you need it.
Quick reference
TL;DR
A real kill switch is a per-tool config flag checked in the orchestrator at dispatch time, not a code deploy; flip, propagate in seconds, keep agents online.
Picture a busy kitchen where every cook can use any tool. One day someone notices the can opener has a sharp edge that is hurting people. You do not shut down the whole kitchen. You do not redesign the can opener overnight. You put a little sign on the can opener that says do not use, and you tell every cook to look at the sign before grabbing the tool. The cooks keep cooking the rest of the meal. When a customer orders something that needs a can, the kitchen sends a polite note saying that dish needs a manager to approve. That sign is the kill switch. The cooks stay working, only one tool is paused, and pulling the sign down restores normal service in seconds.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Agents call tools directly without going through a shared dispatcher There is no choke point to enforce the flag; you have to refactor to a centralised dispatch path first.
The dangerous action is the model's own text output rather than a tool call A tool-level kill switch does not stop the model from saying something harmful; you need an output rail instead.
You need to disable an entire product surface, not just one capability Use a maintenance-mode flag at the API gateway; a per-tool switch is too granular for a full-product takedown.
Quick scan · 2–4 min
Everything important, quickly.
6 min: anatomy of a real kill switch + the three properties + orchestrator dispatch enforcement + graceful tool-result shape + audit logging + quarterly game-day.
Real-world examples
Real products, models, and research that use this idea.
1LaunchDarkly and Statsig are the two flag platforms most LLM-product teams use for per-tool kill switches in 2026.
2Anthropic's Claude tool-use docs recommend gating each declared tool through an orchestrator-side allowlist that can be flipped at runtime.
3OpenAI Agent Builder and the Responses API let you mark tools as disabled at the project level without redeploying the agent.
4Sierra and Decagon, both customer-support agent vendors, document per-tool capability flags as their primary incident-response mechanism.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you keep the kill switch itself from being a single point of failure?
Sign in or go Pro to see the approach for this follow-up.
QWho is authorised to flip the switch, and how do you prevent accidental flips?
Sign in or go Pro to see the approach for this follow-up.
QHow does the kill switch interact with eval suites and CI?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Designing the kill switch as a code redeploy or a system-prompt edit. Both are too slow and too coarse; the right surface is per-tool config the dispatcher reads at runtime.