AI Agent Kill Switch: Incident Response Runbook
Design and rehearse an AI agent kill switch that revokes authority, blocks execution paths, preserves evidence, reconciles in-flight actions and supports safe recovery.
An AI agent kill switch should revoke new authority, block enforced execution paths and preserve evidence without erasing in-flight state. Stopping one process is not enough when credentials, queued jobs, child agents and direct service routes remain active.
Agent Trust describes the standing governance controls. This runbook is for the moment those controls may have failed and responders need to stop execution without destroying the evidence they need next.
Define containment levels
| Level | Action | Use when |
|---|---|---|
| pause planning | stop new tasks | suspected output-quality problem |
| deny material actions | gateway policy denies write classes | uncertain authority or control failure |
| revoke agent | invalidate grants and service identity | suspected compromise |
| isolate tenant or server | block route and credentials | cross-tenant or supply-chain incident |
| platform emergency stop | deny all nonessential agent actions | systemic enforcement failure |
Pre-authorize who may invoke each level. The emergency control itself needs strong authentication, separation of duties and an audit record.
Run the sequence
detect -> classify -> freeze new authority -> revoke active grants
-> block credentials and routes -> preserve queues and evidence
-> identify in-flight actions -> reconcile external outcomes
-> eradicate cause -> test controls -> approve bounded recovery
Do not delete queues or overwrite receipts during containment. A payment may have reached the provider before the stop. Mark it uncertain, query the provider using the original transaction key, and append the outcome.
incident_action:
agent_id: ap-worker-3
containment: revoke_agent
grants_revoked_at: 2026-08-23T11:42:08Z
service_identity_disabled_at: 2026-08-23T11:42:12Z
gateway_rule_active_at: 2026-08-23T11:42:13Z
in_flight_transactions: [txn-184, txn-185]
evidence_hold: IR-492
Test propagation and bypass
Measure time from incident decision to denial at every gateway and protected service. Test cached grants, long-lived sessions, queued work, delegated child authority and an internal direct route. A dashboard showing "agent disabled" is not proof that execution stopped.
Recovery requires a new policy or credential version, passing negative tests, reconciliation of in-flight work and an accountable approval. Do not simply flip the old record back to active.
Define evidence to collect
Containment should capture the active agent and model versions, tool registry digest, authority objects, policy bundles, identity events, gateway decisions, queued work, provider references and recent configuration changes. Preserve source clocks and acquisition times. A model transcript can assist interpretation but should not displace the request that reached the enforcement point.
Record failed containment attempts. If one regional gateway continued accepting a cached grant for four minutes, that fact is part of the incident and the recovery decision. Do not rewrite the timeline after the cache expires.
For delegated agents, traverse child grants and service credentials. Revoking only the parent process may leave a child runtime able to act. Confirm denial at protected services, not only in the control-plane UI.
Recovery should be narrower than the previous deployment. Restore a small action set or one tenant, watch denial and evidence signals, then widen after acceptance tests pass. Define how to stop again without repeating the entire approval process.
NIST publishes an incident response project and guidance that teams can connect to their existing process. Agent-specific response adds authority graphs, model and tool versions, prompts, external context and action evidence.
Use the agent inventory schema to find dependencies and the incident reconstruction guide to build the timeline. The live platform overview describes the relevant Intelliger enforcement layer.
This runbook is a design template, not proof of a tested production capability. Intelliger's public components remain in developer preview and require deployment-specific rehearsal.
Kill-switch questions
Should there be one global switch?
A global emergency stop can be useful for systemic failure, but normal containment needs narrower controls by agent, tenant, action, server and risk class. One switch creates a large availability blast radius and may encourage teams to avoid using it. Test both targeted and platform-level containment.
Who may activate it?
Use named incident roles with strong authentication and separation for the highest-impact control. Pre-authorize emergency action so responders do not wait for an unavailable executive. Record initiator, scope, reason and timestamps. Agents and ordinary workflow credentials must not access the switch.
What happens to queued work?
Freeze new dispatch, preserve queue contents and mark their authority state. Do not delete tasks or let another worker silently pick them up. During recovery, revalidate identity, grant, policy, approval and current business state before any queued action continues.
How are child agents stopped?
Traverse delegation, orchestration and credential relationships from the parent. Revoke child grants and service identities or block them at the shared gateway. Test a child that continues after the parent process exits. Inventory gaps should become an incident finding.
How is containment verified?
Send a controlled request through every active region and route, inspect the protected-service denial and check that no domain operation occurred. Measure propagation and cache age. A control-plane status of revoked is only the intended state, not proof of enforcement.
When can service resume?
Resume after cause removal, credential and policy versioning, in-flight reconciliation, negative regression tests and accountable approval. Restore a restricted scope first and watch evidence. Preserve the incident-era objects so later receipts and investigations remain interpretable.
Run the exercise with an awkward state, not a clean idle system. Put one request in the queue, one at policy evaluation, one submitted to an upstream and one delegated to a child agent. Activate containment, then account for all four. This exposes whether the switch only changes a registry flag or whether it reaches credentials, queues, replicas and protected services. The result should include elapsed containment time, unresolved work and the exact evidence kept for recovery.
Include communications in the runbook. Business and operations owners need to know which actions stopped, which may still complete and when manual processing is safe. Avoid saying the agent is "off" while accepted provider work or delegated children remain unresolved. Use the state list from the containment record.
Give support teams a stable incident reference and an approved status vocabulary. That prevents improvised explanations from contradicting the evidence responders are still reconciling.