Writing a Kill Switch for an AI Feature

"Stop" means different things in different incidents. A useful distinction is between containment, which denies specified consequential actions, and quiescence, which additionally requires running work and queued jobs to reach verified terminal states; a paused job is not terminal, and completed work may already have produced effects that need recovery per this operational analysis.

Consider an invoice-processing agent that starts submitting the same job repeatedly. Disabling its identity may succeed while the workload keeps going through a provider key, export writes or already-accepted jobs. The stop objective is not "end model access," it is "no further duplicate submissions and no further export changes." That reframing changes where you place the gate.

Use a stop-scope table for the feature you are gating. Fill it in with the engineer who owns the request path.

The rule: every row needs a gate that is outside the thing being stopped. If the agent process can read or write the flag that controls it, you do not have a switch.

The narrowest chokepoint is the single place every request must pass through on its way to a consequential effect. In most AI features there are two, and you should build both.

The first is the model API gateway. If all model calls go through one proxy you control, a flag there ends model spend for the whole feature in one change. That is the reasoning behind separating caller and backend authentication in front of AI APIs, so an operator can withdraw access without the caller's cooperation, and enforcing the decision at an inbound policy before the backend is called per the gateway pattern. If you use one key for every model through a single endpoint, an OpenAI-compatible inference API keeps that chokepoint to one address and one revocation step.

The second is the tool executor. An agent's danger is its write access, and runtime policy enforcement means checking each action against policy before it runs at a gate outside the model. A rule in the system prompt is text the model reads and a prompt injection can override it, while a rule at the gate is outside the model's reach per the runtime enforcement guide. The same guide recommends routing shell, cloud API, Kubernetes and MCP calls through one enforcer, and notes that infrastructure backstops such as admission control and cloud IAM still hold when an agent-side check is skipped.

Two more gates get forgotten. Agent loops need their own stop because a loop can keep planning against a denied tool: the controller should check the flag at the top of each iteration. Data egress needs a gate because an agent can exfiltrate through channels your gateway never sees. Network controls are not proven by a policy file; you test them from inside the actual runtime and include cloud metadata and cluster-management endpoints in the denied review, and if your policy depends on an egress gateway you test what happens when that gateway is unavailable, expecting a failed task with a clear error rather than a route around the restriction per the sandbox egress guide.

A practical ordering test: list the effects still possible after each candidate gate. If flipping the model gateway still leaves export writes open, that gateway is not your switch for that incident. Prioritize by effects remaining, not by the admin action that is easiest to perform per the operational analysis. And keep the control plane out of the agent's reach: the switch is not part of the agent harness but a separate control plane outside the model's reasoning loop, so the agent cannot ignore, override or disable it in the enterprise overview.

A shutdown button without decision rights is not a control, it is a rumor: the governance questions are about decision rights, thresholds, evidence and accountability, not about a button hidden in a menu per the board-level governance note. Boards should ask for clear activation thresholds, named owners, audit logging, rollback procedures and a formal restart decision path, and a vendor promise that someone else will act fast enough is not control either per the same note.

The runtime policy tiering already assumes this shape: reversible, wide-reach actions are held for one named approver, irreversible actions need two or more, and security-sensitive changes are refused through a change made outside the agent per the action tier table. Your stop authority should mirror those tiers. The person who can flip the hard stop is an on-call function, not the pilot's sponsor, because the sponsor is the person most invested in seeing the pilot survive.

Two rules keep the role real. The authority must be exercisable by someone who does not need the agent's cooperation, and the stop must be reachable by a person outside the agent with the information needed to stop consequential activity per the operational analysis. And the restart is a separate decision with its own approver, documented in advance, because removing a flag has consequences.

Implement the switch as configuration, not code, and read it at the gate on every request. Do not cache it longer than a short, stated interval: a minute-long cache means your incident lasts at least a minute longer than you think.

# Pseudocode: run at the top of every model or tool request.
def admit(request, kill_state):
    feature = request.feature  # e.g. "invoice-agent"

    state = kill_state.get(feature)  # config store, short TTL
    if state.mode == "hard":
        log_stop_event(
            feature=feature,
            actor=state.actor,
            reason=state.reason,
            request_id=request.id,
        )
        raise HardStop("feature_disabled")  # non-retryable
    if state.mode == "soft":
        return pause_and_hold(request)      # quarantine, no forward
    return forward(request)

Three details carry most of the value. Hard errors must be unmistakable and final, with a distinct error code that client retries will not loop on, and the error path must not call the model you just disabled to write a friendly explanation. Every flip must log who flipped it, when, which feature, the reason code and the incident link. And for long-running work, prefer the soft stop first: a quarantine suspends the problematic thread or queue without crashing dependencies and can be removed once the problem is corrected, with rollback to a known safe state if it cannot be per the kill switch types overview. Use the hard stop when the soft stop has not held within your stated window.

Spend deserves its own breaker, because it can trip automatically. The cost that matters is expected cost per completed task, which divides attempt cost by success rate and includes cleanup for wrong outputs that escape checks per the cost-per-task analysis. A runaway loop shows up as a spike in attempts per accepted result long before anyone notices quality. Wiring a spend threshold as a circuit breaker turns an ambiguous "this feels expensive" into an automatic soft stop a named owner reviews per the same overview. Set caps in dollars per feature per hour, from your own measured cost per task rather than a vendor price sheet, since token counts are not comparable across providers per the model economics analysis.

A switch you have not fired is a hypothesis. The drill converts it into a fact, and it runs with real traffic, on a schedule, with a written acceptance result. Incident response practice draws the line clearly: a tabletop is discussion-based and touches no production systems, while a functional exercise has participants perform assigned tasks in a simulated or controlled environment per the exercise taxonomy. A kill switch test is a functional exercise. Sitting in a room agreeing that someone would flip the flag proves nothing about the flag.

Run it in this order:

1. Record the baseline. For ten minutes, note requests per minute, success rate, error rate and average cost per completed task.
2. Fire a canary request. Send one request that exercises the full path (model call, tool call, egress) and confirm it succeeds. Flip the flag as the named role, resend the identical request, and confirm it fails with your distinct error code while the log entry names the actor.
3. Watch the error rate move. Confirm admitted traffic drops to zero, or to the stated floor if a soft stop holds sessions. If other features on the shared gateway also fail, your gate is too wide.
4. Check the side paths. Confirm queued jobs are drained or held, egress attempts fail from inside the runtime, and no background process still calls the model directly.
5. Restore and measure restart time. Flip back as the designated restart approver, resend the canary, and record how long until traffic returns to baseline.
6. Write the acceptance report. Record observed coverage, timing and persistence per the operational framing, with the canary request IDs attached.

State the target before the drill. A workable one for an internal feature: error rate for the feature reaches zero within the time to change a config value plus the cache TTL, and the stop event appears in the log in the same window. Then quote it in the runbook. Add two checks that catch what a first drill misses: test revocation while a task is still running to see how the application handles its next failed authenticated request, and repeat the drill after any change to the gateway, egress configuration or agent framework, because the test is only valid for the configuration you tested per the sandbox guide.

A worked example with numbers

Suppose the invoice agent handles 1,200 requests per hour at peak and the gateway caches the kill flag for 30 seconds. The switch is flipped at 14:00:00. Requests admitted after 14:00:30 fail; requests admitted between the flip and cache expiry proceed. At roughly 20 requests per second, about 600 requests fall in that gap. Those are the "in flight at flip time" requests, and your stop scope should say whether the gate holds them or lets them complete.

Now cost. If measured cost per completed task is $0.40 at a 90 percent success rate, the expected model cost per solved task is about $0.44, because attempt cost is divided by success rate per the cost-per-task formula. If an incident drives success to 40 percent at the same attempt cost, cost per solved task rises to about $1.00 for the same work while the failed attempts accrue in real dollars. That is why the spend breaker should trip on cost per solved task, not total spend alone per the cost-per-task ledger.

Finally, decide in advance which results justify a kill versus a scale. A scorecard that marks each metric green, amber or red and refuses to let a high average hide a safety or auditability failure gives you shared vocabulary for the day-30 conversation per the kill-or-scale scorecard. The kill switch is the mechanism that enforces the red.