Designing Kill Switches for AI Features

A flag is not a kill switch until it stops the blast radius

Feature flags that only hide a button leave model calls, tool invocations, and queued side effects running. A true kill switch for AI features disables the capability path: no new generations, no tool writes, no outbound messages, and a deterministic product path that still lets users finish critical work.

Design the switch before launch, not during the first incident. Name the owner, the default safe state, the propagation SLA, and the user-facing copy when AI is off. If turning the switch requires a redeploy, you do not have a kill switch—you have a hope.

Scope by risk, not by vanity granularity

Prefer a small number of well-tested switches over dozens of half-wired toggles. Useful scopes include: all AI for a tenant, a single high-stakes action type, model route A versus fallback B, and tool writes versus read-only assistance. Each switch should map to a clear blast radius you can explain in an incident channel.

Separate soft degrade from hard stop. Soft degrade may increase refusal rate, force retrieval-only answers, or route to a smaller model. Hard stop removes AI from the critical path entirely. Operators under stress need both, with defaults that fail toward safety for irreversible actions.

• Propagate kill state to edge, workers, and clients within a defined SLA
• Make switches independent of the model provider status page
• Keep a non-AI path for checkout, auth, and data export flows
• Log who flipped what, when, and why for auditability

Test the dark path like a release gate

Staging should regularly run with AI killed. Verify empty states, support macros, analytics still make sense, and that in-flight jobs do not complete dangerous work after the switch flips. Chaos days that only test latency misses the failure mode customers actually fear: confident wrong actions.

Pair kill switches with automatic tripwires: cost burn, groundedness collapse, policy violation spikes, or elevated human escalation. Automation can propose or even execute a soft degrade; hard stops for customer-facing write actions usually deserve a human confirm unless the risk is catastrophic.

Communicate the outage as product, not apology spam

When AI is off, say what still works and how to complete the task. Vague 'assistant unavailable' copy drives retries that hammer an already stressed system. Internal runbooks should include customer messaging, support scripts, and criteria for re-enabling after eval health returns.

Kill switches are staff-level infrastructure for AI products. They turn model uncertainty into an operable control plane: you can ship ambitious features because you can stop them cleanly when reality diverges from the demo.

• LaunchDarkly — Kill switches
• Google SRE — Managing risk
• OWASP — LLM Top 10