The Kill Switch route lives at /kill-switch (top-level sidebar entry, separate from settings). Use it to immediately halt a misbehaving agent, runaway run, or compromised mission. Active kill switches are scoped per organization.
Layout
The page has two sections:
- Active kill switches — table of currently-killed targets with target type, target ID, reason, killed-at timestamp, and a per-row Revive button.
- Emergency Kill dialog — opens from the page header. Pick a target type (
agent, run, or mission), enter the target ID, and supply a short reason (≤2,000 chars).
The header shows a live count: “3 Active Kill Switches”.
Killing a target
- Click Emergency Kill in the page header.
- Select target type from the dropdown.
- Paste the
agent_id, run_id, or mission_id.
- Add a reason. The reason is shown in interventions and audit logs.
- Click Kill to commit.
Once killed, the SDK’s GET /api/v1/kill-switch/check returns is_killed: true and the next @guarded_action call raises a PolicyViolationError. The blocked attempt is recorded as a HARD_BLOCK intervention with the killing user attributed.
Kill is immediate and applies to all SDK clients reading from this org. There is no undo — the only way back is Revive.
Reviving a target
Click Revive on the row. The kill switch is marked inactive and the SDK begins allowing actions again. The original kill record is preserved (with revived_by and revived_at populated) for audit.
When to use
- Agent — a deployed agent is hallucinating, leaking PII, or burning budget. Killing it stops every run currently in flight for that
agent_id.
- Run — a single in-flight run is misbehaving but the agent code is fine; kill the
run_id to stop just that execution.
- Mission — kill all runs that share a mission ID (used for multi-agent or multi-step missions).
API
The page is a thin client over the kill-switch API:
POST /api/v1/kill-switch/killPOST /api/v1/kill-switch/reviveGET /api/v1/kill-switch/activeGET /api/v1/kill-switch/check
Full reference: Platform → Kill Switch API.
See also
