General incident response is built around availability and integrity failures with crisp detection signals. AI incidents often present as none of that: every health check green, latency normal, and the harm is in the content. The playbook structure below is recommended practice to adapt — same skeleton as your IT runbooks (detect, contain, investigate, remediate, review), with scenario-specific content for four failure modes that generic runbooks miss.
Scenario 1: harmful or off-policy output reached a user
Detect: mostly human channels — user reports, support tickets, employee escalations — supplemented by output-filter hits and refusal telemetry. Make the report path one click from wherever outputs appear.
Contain: your options, in escalating order: tighten the output filter rule that missed; disable the affected feature via its feature flag; suspend the workload's credentials. On the Claude API, the Admin API can set an API key's status to inactive, and archiving a workspace immediately revokes all API keys in it (irreversibly — reserve that for genuine emergencies). On the cloud platforms, the equivalent lever is IAM: revoke the role or service account the integration runs as.
Investigate: pull the full interaction from your prompt and response logs — you need the exact prompt, system prompt version, model ID, and output. This scenario is why content logging with sensible retention exists.
Remediate and review: fix the layer that failed (system prompt, filter, upstream data), add the case to your evaluation set so regressions get caught pre-deployment, and record the incident in your decision audit trail.
Scenario 2: prompt-extraction or jailbreak attempts
Someone is probing your application to extract its system prompt or bypass its rules. Two useful facts: first, treat your system prompt as configuration that will eventually be seen, not as a secret vault — never put credentials or sensitive data in it, and extraction becomes an annoyance rather than a breach. Second, instrument the signals the platform gives you: Anthropic documents that Claude Fable 5 returns stop_reason: "refusal" with a stop_details.category field — documented categories include "reasoning_extraction" alongside "cyber" and "bio". A spike in refusals from one account or session is your detection signal. Containment is rate limiting and account-level action in your application; investigation means reconstructing the probing session from logs. Defensive posture only: your playbook responds to attacks on your systems, it does not counter-attack.
Scenario 3: data leakage signals
Sensitive data appears where it should not — in a prompt (an input-control miss), in an output shown to the wrong audience (often a retrieval-permission bug), or in your own logs. The AI-specific step is scoping: identify every copy along the chain — your application logs, any stateful platform features in use (Files API files persist until explicitly deleted; Managed Agents transcripts persist until you delete them), and downstream systems that consumed the output. Then delete what you control and confirm platform-side handling against the documented retention policy for your platform. If the leak crosses a legal threshold, your privacy and legal teams own notification decisions — the playbook's job is to get them accurate scope fast.
Scenario 4: model-version regression
Behavior degrades after a model or prompt change: formats drift, refusal rates jump, quality drops on a workload that used to be solid. Two platform facts make this playbook tractable. Claude model IDs are pinned snapshots — including the newer dateless IDs — so behavior does not change under a pinned ID, and "roll back to the previous model ID" is a real containment action, not a hope. And your deployment process should treat model swaps as releases: run your evaluation suite before cutover, keep the old ID configured for instant rollback, and use canary traffic for the switch (see managing changes to production AI models and blue/green model deployment). Detection is your evaluation and monitoring stack; if you have neither, this scenario is undetectable until users complain.
Run the drills
A playbook nobody has rehearsed is a document, not a capability. Tabletop each scenario twice a year with the people actually on call, verify the kill switches work in staging, and confirm the logs the playbook assumes actually exist at the retention the playbook assumes. Most first drills fail on exactly that last check.
Where to go next
See general incident response for Claude workloads, usage anomaly detection for the monitoring side, and red-teaming 101 for finding these failures before attackers do.