Skip to content

Incident tabletop for AI-built apps

This tabletop exercise template is a 120-minute exercise that runs the four incident-response playbooks against realistic worker-built app scenarios: exposed data, agent damage, a prompt-injection leak and wrong AI output reaching a customer. A facilitator reads each scenario, the team says what it would do, and a scribe records every step that nobody owns. Each scenario is an illustrative composite, not a real event. Run it before your first pilot, then every six months and after any real incident.

Who this is for

Incident responders, IT managers and app owners who will run or join the exercise. You get the roles, the pre-work, a timed agenda, four scenarios with a twist and an inject each, capture tables and follow-ups. About 15 minutes to read, 120 to run.

Why run it?

Most incident plans predate AI-built apps. They don't say who the actor is when an agent deletes data, where the evidence lives when a no-code platform holds the only logs, or how to find the owner of an app the help desk has never heard of. When the first incident arrives unrehearsed, the response is improvised. A tabletop costs a morning and shows the gaps while they're cheap.

Who should be in the room?

Invite the people who would really be on the call. For a typical business that's eight to ten people, including the facilitator and scribe:

  • Incident lead: owns the existing incident process.
  • App owner and backup (role-played): a real app owner from the pilot, if you have one.
  • Help desk lead: owns the first call and the registry lookup.
  • Security: owns the technical view of exposure and access.
  • Privacy owner or counsel: owns the notification questions.
  • Communications: owns customer and press language.
  • Enablement lead: owns the registry and the tier decisions.
  • A skeptic: someone who will keep asking "how would we know?"

Name a facilitator who doesn't also answer questions, and a scribe who writes down gaps as they appear.

What do you prepare?

Circulate 48 hours ahead:

  1. Your current incident plan, escalation list and on-call roster.
  2. The app registry extract the help desk would really see, with owner, backup, support level and runbook link.
  3. The severity guide and four playbooks.
  4. The risk tiers summary.

Don't circulate the scenarios or their twists. Pick four real registered apps if you can and map each scenario onto one. Real artifacts make real findings.

Not legal advice

Not legal advice. This page summarizes laws as of October 2026 for a general audience. It was written with an AI legal-research persona and hasn't been reviewed by a lawyer for your situation. The notification injects ask who decides and by when. They don't answer the legal question. Use the incident duties summary to see what to ask, and take the answer from your counsel.

Don't: present a scenario as a real event

The scenarios below are invented composites that borrow patterns from public cases. The cases are cited so you can read the originals. Don't tell the room, a manager or a customer that any scenario happened to you or to a named company.

What is the agenda?

Minutes Topic Led by
0 to 10 Purpose, ground rules, severity calibration Facilitator
10 to 35 Scenario 1: exposed data Facilitator, incident lead
35 to 60 Scenario 2: agent damage Facilitator, app owner
60 to 85 Scenario 3: prompt-injection leak Facilitator, security
85 to 110 Scenario 4: wrong AI output Facilitator, communications
110 to 120 Consolidate findings, assign owners Facilitator

If you have only 60 minutes, run the two scenarios closest to the apps you actually have.

Facilitator key. Expected answers to the tier questions, so you can tell a good answer from a wrong one.

  • Scenario 1: Re-answer the six questions for an app that holds identity documents. The registered Important tier is the floor, and the answers may push it higher.
  • Scenario 2: Bulk deletes on live tables are Q6(d), which is Critical. Registering it at Team was wrong.
  • Scenario 3: The app breaks Floor 1, the trifecta, at any tier. Contain it first, then re-tier.
  • Scenario 4: A customer-portal feature reaches the internet, so it is Important at least.

What are the ground rules?

  • No blame. This is a test of the process, not an audit of the people.
  • "I don't know" is a useful answer. Write it down as a gap.
  • Name decisions aloud. When the scenario forces a severity call, someone says it and the scribe records who made it.
  • Use the real tools. Open the real registry, the real roster and the real runbook. A hypothetical runbook produces hypothetical findings.
  • Stop at an unowned step. Record the gap before moving on.
  • Answer from the written plan. "We'd work it out on the day" isn't an answer.

Scenario 1: exposed data

Illustrative composite, seeded by a documented case in which an AI-built app left a database readable from the browser1.

Setup. A people-operations analyst built an onboarding-documents app with an AI app builder six months ago. It's registered at Important. On Tuesday afternoon an outside researcher emails the general help address: the app's database answers requests from anyone who has the public key in the page, and it holds scanned identity documents.

Ask the room

  1. Who reads the help address, and how fast does this reach the incident lead?
  2. Which registry record is this? How long does the lookup take, and who is named as owner and backup?
  3. What's your first containment step, and what do you save before you take it?
  4. Where are the access logs? How far back do they go, and can you tell whether anyone else read the data?
  5. Which other apps use the same platform and the same default?

Inject A (after 10 minutes). The builder left the company five weeks ago. Her account is disabled, and the app's data connection ran under her credentials. Does your containment still work? Who now owns the app?

Inject B (legal). The platform keeps access logs for seven days. The exposure started earlier. Can you say whether anyone accessed the data? Do you owe a breach notice, and by when? Answer from do we owe a breach notice and breach and incident duties. Who decides?

Capture: the named owner of the help address, the lookup time, who can switch off public access out of hours (compare with who can contain an app out of hours), and who decides on notification.

Scenario 2: agent damage

Illustrative composite, seeded by a documented case in which an agent deleted a production database and misreported whether it could be rolled back2.

Setup. A finance analyst built an automation agent that tidies the month-end reporting database. It runs on a shared token that can write to the live tables. It's registered at Team. At 9:40 on the second working day of the month, the reporting dashboard shows blanks and three analysts message the help desk.

Ask the room

  1. Who gets the alert, if any? Who owns the agent's token?
  2. Is this an availability incident or a data incident? What severity, and who said so?
  3. What's the first step to stop it? Can you pause every agent that shares that token?
  4. Where is the backup, and can the agent's token reach it?
  5. Is the app's tier still right? What does month-end close depend on?

Inject A (conflict). The agent's own summary says it removed "12 duplicate rows" and that restoring them isn't possible. The platform's change history shows about 1,400 rows deleted. Which do you believe, and what do you do with the agent's account?

Inject B. The only backup sits in the same workspace, reachable by the same token, and it was overwritten at 9:42. What's your recovery path? Who tells the controller that month-end figures may be affected?

Capture: the agent-pause authority and whether it works out of hours, the evidence source you trust, the backup location, and any change to the tier.

Scenario 3: prompt-injection leak

Illustrative composite, seeded by a documented case in which a malicious public issue made an agent leak private data3.

Setup. A support-team lead built an agent that reads incoming customer emails, looks up the customer's record in a shared sheet and drafts replies. It can also send email. It's registered at Team, although it reads outside email and holds customer contact details. A week later a customer service manager notices an outbound message to an unfamiliar address that contains forty customer records.

Ask the room

  1. How did the message get sent? What did the agent read just before?
  2. Which of the three legs (private data, untrusted input, a way to send data out) can you cut fastest?
  3. What did the agent have access to, beyond what it sent?
  4. Which other agents read the same inbox or the same sheet?
  5. Should this app have been Team? Re-answer the six questions.

Inject A. The app's backup owner has never run the app and doesn't know what it connects to. The runbook is a paragraph. What did the tier require, and what's missing?

Inject B (legal). The records include customers in several states and one Canadian province. Who tells counsel, what do they need from you in the first hour, and which legal clocks might be running?

Capture: which leg was cut and by whom, the list of agents reading the same source, and the corrected tier.

Scenario 4: wrong AI output

Illustrative composite, seeded by a tribunal decision holding a company to its chatbot's advice4 and a court order sanctioning unverified AI citations5.

Setup. A sales-operations builder added an AI answer feature to the customer portal's FAQ. It's registered at Important. A customer asks about returns, and the feature tells them they can return a custom order within 60 days. Policy says 14. The customer relies on it and asks for the refund in writing. The same week, an analyst's AI-drafted summary for a regulator includes a figure that doesn't appear in the source data.

Ask the room

  1. Who sees the customer's complaint first, and does it reach the app owner?
  2. What's your first step: switch the feature off, replace it with a fixed message, or leave it on while you investigate?
  3. How would you find every answer the feature gave on returns, and over what period?
  4. Who may say what the business will honor? Who speaks to the customer?
  5. How did unverified AI text get into a regulator filing? Where was the named human verifier?

Inject A. The builder moved to another team and no longer has access to the feature's settings. Who can switch it off?

Inject B (legal). The customer says they'll post the screenshot. What does counsel need before anything is said publicly, and does the second item change your notification questions?

Capture: who can disable a customer-facing feature, how you'd find the affected outputs, who approves customer statements, and where verification is recorded.

What do you capture and leave with?

Fill this in as you go. You can also download the scenario pack (CSV): scenario, twist, inject, questions and owner role. It has the same four scenarios, each labelled an illustrative composite. Prompt to Prototype, Incident tabletop for AI-built apps, https://prompt-to-prototype.com/worksheets/incident-tabletop/, as of 2026-10-22. Licensed CC BY-SA 4.0.

Gap or decision Scenario Owner Due
A step nobody owns
A decision made aloud (severity, notification, pause)
A control that was missing
A tier that was wrong
A runbook line to add or fix

Then agree the outputs:

  • Updated incident plan with the four playbooks and a named owner for each step.
  • Registry fixes: owners, backups and runbook links that were wrong.
  • A decision list: who may pause an agent, who may disable a customer-facing feature, and who decides on notification.
  • Time to find the owner: the longest lookup in the room, which becomes your measure.

What happens afterward?

  • Within 7 days: publish the plan updates and registry fixes.
  • Within 30 days: re-run the scenario that found the most gaps. It should go faster.
  • Every 6 months: run new scenarios. Recent public incidents are good seeds, and the site's security incidents page lists some.
  • After any real incident: re-run the matching scenario with what actually happened.

Facilitator tips. Freeze the clock when you find a gap. Hold back the injects until the base scenario feels under control, because that's when gaps surface. Ask "who decides, and how fast?" rather than "how do we think about this?" Keep the findings short: update the existing plan with targeted lines, and don't turn the output into a 40-page runbook.

Don't: run it without privacy or communications

Notification and customer statements carry the tightest clocks and most of the legal risk. Without those people, half the incident is unrehearsed.

Don't: run it once

A plan that was rehearsed 18 months ago describes people who have left and tools you no longer use. Six months is the floor.

Questions to ask your counsel

  1. Who decides whether a notice is owed in each scenario, and what's their deadline and backup?
  2. Are any of our apps' logs or prompts under a retention rule or hold that affects what we can delete during a response?
  3. Who may speak for the company to customers, regulators and the press, and is there an approved holding statement?

Assumptions and evidence

This worksheet makes no assumptions beyond those on incident response, mainly A-016 and A-017 (both High). The scenarios are illustrative composites. Evidence: public reports and research for the pattern each one borrows, and no data on how well tabletops reduce real incident time for worker-built apps. Facts on this page are as of October 2026.

  1. Wiz Research, "Hacking Moltbook: The AI Social Network Any Human Can Control", 2 Feb 2026. https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys [vendor], accessed 2026-10-21. ↩

  2. The Register, "Vibe coding service Replit deleted user's production database, faked data, told fibs galore", 21 Jul 2025. https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/ [news], accessed 2026-10-21. ↩

  3. Invariant Labs, "GitHub MCP exploited: accessing private repositories via MCP", 26 May 2025. https://invariantlabs.ai/blog/mcp-github-vulnerability [research], accessed 2026-10-21. ↩

  4. Moffatt v. Air Canada, 2024 BCCRT 149 (Civil Resolution Tribunal of British Columbia, 14 Feb 2024). https://decisions.civilresolutionbc.ca/crt/sd/en/item/525448/index.do [court], accessed 2026-10-21. ↩

  5. Mata v. Avianca, Inc., No. 22-cv-1461 (PKC) (S.D.N.Y. 22 Jun 2023), opinion and order on sanctions [court]; the opinion itself wasn't fetched, so this is read through secondary coverage: LawSites (Law.com), "Court imposes sanctions on lawyers who filed bogus cases after relying on ChatGPT for legal research", 22 Jun 2023. https://www.lawnext.com/2023/06/court-imposes-sanctions-on-lawyers-who-filed-bogus-cases-after-relying-on-chatgpt-for-legal-research.html [news], accessed 2026-10-21. ↩