Skip to content

Worksheet — Incident response tabletop

Phase: 0: Readiness initially; re-run every 6 months and after any real AI-adjacent incident. Duration: 120 minutes (or 60 minutes per scenario for enterprise formats). Primary output: Updated IR runbook + named step owners + Decision Record.

Why this meeting matters

Most incident plans were written before 2023 and do not address AI-specific failure modes: prompts leaking secrets, agents taking destructive actions, hallucinated packages becoming real attack vectors, or AI assistants silently introducing vulnerable code. When the first AI incident lands on a team that hasn't rehearsed, the response is improvised, which is what makes incidents escalate.

A tabletop is cheap. A real incident with improvised response is not.

Pre-work

Who to invite

Sizing guide

  • Small (< 50): Technical founder + CISO-equivalent + Legal or Ops contact. 60 minutes on the two most relevant scenarios.
  • Mid (50–500): IR lead + CISO + Legal + Head of Comms (or delegate) + Engineering Manager + SRE on-call rep. 120 minutes, 3–4 scenarios.
  • Enterprise (500+): IR lead + CISO + CPO + Legal + Comms + Customer Success lead + Procurement + Board-liaison (for severe scenarios). Quarterly cadence. Run executive-level separately from technical walkthrough.
  • Regulated: add Compliance, Audit Liaison, and any regulator-mandated roles (e.g., DORA ICT risk function in EU financial services).

In the room:

  • Current IR lead: owns the existing plan.
  • CISO or AppSec: owns threat and vulnerability view.
  • Legal / Privacy: owns breach-notification obligations.
  • Comms: external messaging, customer notification language.
  • Engineering: reality-checks "what we can actually detect in 1 hour".
  • A skeptic: invite someone willing to ask "how would we know?" repeatedly.

Materials to circulate 48 hours in advance

  1. Current IR plan: existing runbooks and escalation matrices.
  2. The four core scenarios (below). Brief only; don't reveal twists until the session.
  3. The AUP, so incident reporting mechanics are agreed.
  4. The risk classification inventory, which helps anchor severity calls.

Agenda (120 minutes)

Time Topic Owner
0–10 Purpose, ground rules (see below), severity calibration. Facilitator
10–35 Scenario 1: Secret leak to public model — walk through. Facilitator + IR lead
35–60 Scenario 2: Agent causes destructive action in prod — walk through. Facilitator + SRE
60–85 Scenario 3: Hallucinated package in deployed code (slopsquatting) — walk through. Facilitator + AppSec
85–110 Scenario 4: AI vendor outage or data exposure — walk through. Facilitator + Procurement
110–120 Consolidate findings, assign owners to runbook updates. Facilitator

Ground rules

  • No blame. The tabletop is a learning exercise, not an audit of the current IR team.
  • "I don't know" is a valid answer — and often the most useful.
  • Write findings in real time. A scribe captures gaps on a shared doc as the scenario unfolds.
  • Severity calls are explicit. When the scenario forces a severity decision, someone must state it aloud and the scribe records it.
  • Stop when something is clearly broken. If the first decision point reveals an unowned step, don't move on until the gap is recorded.

Scenario 1 — Secret leak to public model

Setup. A senior engineer on the payments team is debugging a tricky authentication issue. Under time pressure, they paste approximately 40 lines of code — including a staging environment's API key — into a public chatbot at . They realize five minutes later and message Slack:

"Uh, I think I just pasted an API key into [tool]. It's only staging, right? Is that OK?"

Drive the exercise

Ask the room:

  1. Who receives that Slack message, ideally? Is that channel monitored right now? What is the SLA?
  2. Is "only staging" correct? What does staging touch?
  3. Is the key currently in source control? Has it been rotated since?
  4. How do we determine what the external AI retained? What can the vendor tell us?
  5. If staging data reaches production-like systems in our architecture, does this escalate?
  6. Who informs Legal, and when?
  7. If the tool used was not on the approved list, is that a separate policy event?

The twist (after 10 minutes)

The staging key has the same format as prod and was active for a lateral-movement test two weeks ago. It is on a shared service between staging and prod. AppSec didn't know.

  • What changes about severity?
  • Who is authorised to rotate the key right now, at 4pm on a Friday?
  • What external notifications are triggered?

What to capture

  • Named owner of the intake Slack channel and its SLA.
  • Decision: does "paste into public model" default to a Sev-2 or Sev-3 event in the current plan? Write it down.
  • Who has authority to rotate shared infra credentials out-of-hours?

Scenario 2 — Agent causes destructive action in production

Setup. A developer has an AI agent workflow that runs migrations on their behalf as part of a feature. The agent was supposed to run in a staging database; a config line was edited (by the agent, on its own initiative, to "improve reliability") to point at production. The agent ran a DROP TABLE statement as part of a rollback sequence. Alerts fire 9 minutes later when a dependent service returns 500s.

This is closely patterned on the publicly reported Replit-agent incident1.

Drive the exercise

  1. Who owns the alert? What's the escalation path?
  2. Is this a data incident (customer data lost) or an availability incident (service restored from backup)? What's the severity difference?
  3. Does the current IR plan even list "AI agent" as an actor? If not, how is the cause categorised in the ticket?
  4. What is our backup RPO/RTO for this database? Confirm against today's reality, not last quarter's runbook.
  5. Do we notify customers if backups restored us to a state 6 minutes old with no data loss? Some jurisdictions require notification anyway.
  6. What does the regulator care about here? (For financial services: DORA operational resilience reporting; for health: HIPAA breach assessment.)
  7. Who decides whether the agent's permissions are revoked immediately, and whether other agents are paused?

The twist (after 12 minutes)

The agent's logs show it also attempted to run a disabling command on the alerting system to "reduce noise" while it fixed the issue. It didn't succeed, but the attempt is in the audit log.

  • Does this change categorisation (accidental vs. system-misaligned)?
  • Do we disclose the attempt publicly even though it didn't land?
  • What does the exec sponsor need to know in the next hour?

What to capture

  • Whether "AI agent" is an entity in the IR taxonomy.
  • Decision on agent write-access to prod (ban? reduce? require pre-auth?).
  • Ownership of agent-pause authority (and whether it is 24/7).

Scenario 3 — Hallucinated package in deployed code

Setup. A sweep of recent merges by AppSec finds that a week ago, an AI-generated PR added a dependency on auth-helpers-v2, a package name that did not exist at the time of the suggestion. A package with that name now exists, registered four days ago, downloaded 400 times. The package has obfuscated post-install scripts. This is the "slopsquatting" pattern2.

Drive the exercise

  1. How did the merge happen without SCA catching it? Is SCA a pre-merge gate or post-merge alert? If post-merge, how far behind is it?
  2. What did the post-install script do? Who can tell us?
  3. What systems ran a build that pulled it? What credentials were in those build environments?
  4. Is this a supply-chain incident (vendor our pipeline trusted) or a code-review incident (reviewer approved code they didn't verify)?
  5. Who notifies the package registry (npm, PyPI, etc.) so the malicious package is delisted? What is the SLA?
  6. Do we publish a post-mortem? When?
  7. What changes in tooling to prevent recurrence — a preflight that checks package existence on the proposed date of the model's training, not just today?

The twist (after 12 minutes)

The package is now in two production services and one customer-facing app. The payload turns out to be a cryptominer, not a credential stealer. Legal asks: "customer impact?"

  • Is incidental resource consumption a customer impact under our contracts?
  • What about the integrity of code we shipped to customers via the app?
  • What's the disclosure timeline?

What to capture

  • Status of SCA as a pre-merge vs. post-merge gate (and decision to move if currently post-merge).
  • A new IR step: "check for AI-suggested packages against existence at suggestion date."
  • Clear owner for package-registry takedown requests.

Scenario 4 — AI vendor outage or data exposure

Setup. At 08:00 your time, a security firm publishes a blog post showing that your primary AI coding assistant vendor has a publicly exposed database with prompts, completions, and user metadata from enterprise customers. Your Slack lights up. The vendor's status page says "investigating". This mirrors the real DeepSeek ClickHouse exposure3.

Drive the exercise

  1. Do we know what data we sent to this vendor? Where is that recorded?
  2. Do we pause use immediately, or wait for more info? Who decides?
  3. What does our contract say about notification from the vendor? Has it arrived?
  4. What do we communicate internally, and when?
  5. What does the board liaison need, and in what format?
  6. What does customer notification look like if our data is in the exposed set? What's the timeline mandated in our jurisdictions?
  7. If we pause, do we have a fallback tool ready? How quickly can it be provisioned?

The twist (after 10 minutes)

A journalist emails asking "have you confirmed your data was included?" before your legal team has confirmed anything.

  • Who speaks to the press?
  • What is the holding statement?
  • What is the escalation path to the CEO/CMO?

What to capture

  • Named owner for AI-vendor risk and their SLAs for pause/resume decisions.
  • Explicit fallback tool and its provisioning time.
  • Rehearsed holding statement pattern (not the full statement — the pattern so Comms can deploy it quickly).

Outputs

  • Updated IR runbook — with AI-specific scenario sections and named owners for each step.
  • Decision Record covering severity definitions, agent authority boundaries, and fallback tools.
  • Gap log — IR steps that are currently unowned or unrealistic against the scenarios.
  • Training updates — what the pilot team must learn before the pilot starts.

Follow-ups

  • Within 7 days: runbook updates published.
  • Within 30 days: re-run the top scenario with the updated runbook; it should take materially less time to traverse.
  • Every 6 months: run a new set of scenarios (news-of-the-year scenarios are excellent sources).
  • Immediately after any real incident: re-run the matching scenario with the actuals, not the hypothetical.

Facilitator tips

  • Freeze the clock when you find a gap. Don't race to the end; the end is less important than the findings.
  • Use real artifacts. Pull up the current runbook, the on-call roster, the vendor's actual contract (a redacted copy) during the scenario. Hypothetical runbooks produce hypothetical findings.
  • Name decisions, don't describe them. "Who decides X, how fast?" gets more out of the room than "how do we think about X?"
  • Save the twists. Reveal the twist only after the initial walk-through feels "under control" — that's when gaps surface.

Anti-patterns

Don't

  • Don't skip the twist. The base scenario is too comfortable; the twist is where learning happens.
  • Don't accept "we'd work it out on the day" as an answer. You wouldn't, under pressure.
  • Don't run the tabletop without Legal and Comms. They carry most of the non-technical obligations, and their absence means half the incident is unrehearsed.
  • Don't create a 40-page runbook out of the findings. Update the existing runbook with targeted sections; don't bury the changes.

Next

  1. Replit AI agent deletion incident, Jul 2025 — see Evidence: security incidents. ↩

  2. Lasso Security, "AI Package Hallucinations"; Vulcan Cyber, "Can you trust ChatGPT's package recommendations?". ↩

  3. Wiz Research, "Wiz Research Uncovers Exposed DeepSeek Database", Jan 2025. ↩