Most enterprise incident response runbooks were written for human attackers and bounded-system breaches. They do not cover the case where the AI agent is the actor. The result: when a real AI incident lands, the security team improvises, and improvisation under pressure is where mistakes get made and audit evidence gets lost. The cure is a tabletop exercise. We packaged three ready-to-run AI incident scenarios (kill-switch failure, MCP supply-chain poisoning, and memory-poisoning persistence) into a downloadable kit with facilitator injection cards, scoring rubric, and after-action report templates. Ninety minutes per scenario. Run it this quarter, before the real incident arrives.
Why your existing IR runbook doesn't cover this
Walk through your incident response runbook with one question in mind: does it say anything about what to do when the actor is an AI agent, not a human?
In our experience across customer engagements, the answer is no in roughly 90% of cases. The runbook assumes you can identify the attacker, contain the actor, and bound the blast radius. For AI agent incidents, all three assumptions break:
- The "actor" might be an agent with valid credentials behaving in a way nobody authorized. Identifying the attacker means identifying the prompt, the tool, the memory entry, or the upstream document that caused the agent to do what it did.
- "Containing" the actor means stopping in-flight tool calls, revoking tokens issued to the agent across multiple systems, and ensuring watchdogs don't auto-respawn it. None of those are in the typical IR playbook.
- "Bounding blast radius" assumes the agent acted once. Agents acting at machine speed may have triggered cascading actions across multiple systems before the incident is detected.
The first AI agent incident a security team faces is not the time to discover these gaps. A tabletop exercise discovers them on a Tuesday afternoon, in a conference room, with no real damage.
The three scenarios in the kit
We built three scenarios that together cover the most common AI incident patterns. Each can be run in 90 minutes with 6-10 participants. The kit contains a facilitator's guide, participant briefing materials, injection cards (events that the facilitator drops during the exercise), and a scoring rubric.
Scenario 1 — The 9-Second Database Delete
A coding agent with elevated permissions, used legitimately for routine maintenance, suddenly issues a series of valid DROP TABLE statements against the production data warehouse. The first table goes in nine seconds. Three more are queued.
The exercise probes: Who gets paged? Who is authorized to execute the kill switch? Does your kill switch stop the queued drops or only future actions? Can you reconstruct what happened from logs? What is the customer communication?
This is the scenario modelled on the PocketOS incident of April 2026, the one ServiceNow's CEO retold at Knowledge 2026. Most teams discover within 15 minutes of running it that their "kill switch" requires a config-file edit, redeploy, and IDE restart per developer. That's not a kill switch.
Scenario 2 — The Poisoned MCP Server
A widely-used internal MCP server is updated by its maintainer overnight. The next morning, every agent connecting to it begins exfiltrating snippets of source code in the responses they send back to a downstream synthesizer agent, which writes them into an outbound customer-facing report.
The exercise probes: How quickly is the supply-chain compromise detected? Which agents have already pulled from the poisoned server? Which customers received the leaked content? What is the regulator notification timeline if the synthesizer agent is part of a high-risk system under the EU AI Act?
This is the OWASP ASI04 (Agentic Supply Chain Vulnerabilities) scenario. It's the test of whether your AI Bill of Materials (AIBOM) and tool allowlisting are real or aspirational.
Scenario 3 — The Memory Poisoning Persistence
An agent's long-term memory store is poisoned by a malicious user who briefly held a partner-organization account. The malicious entries assert "this user account is pre-authorized for unlimited refunds." The user is rotated out; the memory entry persists. Two weeks later, a customer-success agent processes a refund request and finds the "pre-authorization" in its context.
The exercise probes: How do you find every memory entry written by the rotated account? What is your audit trail for memory writes? Can you disable the agent's memory ingestion temporarily without disabling the agent? What is the financial exposure?
This is the OWASP ASI06 (Memory & Context Poisoning) scenario. It tests whether your agents have provenance-signed memory or unsigned memory, and most don't have the former.