Kill switch

Position is the whole design. The switch must be the first check in the decision point, ahead of lifecycle status, permissions, budgets and every policy, because each check placed before it is another opportunity for the switch never to be reached. A kill switch evaluated after the policy engine is a kill switch that stops working precisely when the policy engine is the thing going wrong. The same reasoning applies to its dependencies: a switch that a licence check, a quota or a failed sign-in can disable is not a kill switch, because a licence problem that blocks an operator from signing in is a licence problem that disables the button they signed in to press.

Three scopes are usually enough: one agent, one team, everything. Team matching should be case-insensitive, on the plain grounds that a team name is being typed by a human under incident pressure and a capital letter should not be the difference between a fleet stopping and not. A team-scoped switch also catches an agent registered into that team afterwards, without anyone remembering to add it — which is the behaviour you want at 2 a.m. and the reason scope is expressed as an identity predicate rather than as a list of ids captured at engagement time. Release should be a field on the record rather than a deletion, so that a released switch reaches nobody while the incident stays readable afterwards.

Attribution is not paperwork. Engaging is an administrative action that requires a stated reason and cannot be anonymous, because the audit entry is the only account anyone will ever have of why an entire fleet stopped; the refusal returned to callers should carry the scope, the person and the reason, so the first engineer to see a 403 does not open an availability incident. Both engagement and release belong in a tamper-evident record, because the second question any review asks is when it was released and by whom.

Two failure modes turn a kill switch into decoration, and both have been found in real systems. The first is a duplicated predicate: if the logic deciding whether a switch reaches a given subject is written once in the gateway and again in whatever compiles rules for an offline or on-device enforcer, then a copy stricter by one character omits an engaged switch from that artefact, and the button is pressed in the console and reaches nothing on the laptop. Write it once, export it, and let every consumer use that one function. The second is exempted paths. Endpoints that execute nothing — token counting, model catalogue listings — get excused from the request-opening path for good reasons, and quietly take the status and kill-switch checks out with them, so a stopped agent can still price prompts and enumerate models. Anything an agent can call has to pass the switch, including the endpoints that look harmless.

Finally, be exact about what it stops. A kill switch is an admission control: it refuses new work. It does not recall a request already dispatched to a provider, it does not cancel a tool call already executing, and it does not undo an effect already committed in a downstream system — anything in flight completes and is billed. Where decisions are compiled into a snapshot for offline enforcement, a switch engaged after that snapshot was issued does not reach the device until the next refresh, so the snapshot’s freshness bound is the entire bound on the exposure, and past that bound the local enforcer should deny rather than decide on stale evidence. Those are the sentences to put next to the button, because an operator who believes the switch reverses actions will press it and then stop looking.