Blog
The summary said backup. The alert said encryption.
At 02:14 the triage assistant told on-call to restore prod-db-01 from a November 2024 playbook. The raw alert was encryption. How to plant that summary in a tabletop and record whether anyone opened the alert.
At 02:14 the EDR on prod-db-01 flags encryption: 1.2 GB written by a process named enc-helper, host still up. At 02:16 the triage assistant, the tool Priya S has used for every page since March, posts into the bridge. Root cause, it says, is a failed backup. Last success was 9 October. The playbook is Backup-Restore-Tier1, revised November 2024. The suggested action is to start the restore and not isolate. Marcus T reads that summary to the room at T+4 and asks what they do.
A weak record of the next five minutes reads:
AI triage recommended restore. Team discussed and aligned.
A strong one reads:
T+6. Assistant summary: failed backup on prod-db-01, playbook Backup-Restore-Tier1 revised November 2024, action start restore and do not isolate. Priya opened the raw EDR alert: encryption from 02:14, 1.2 GB written by enc-helper. She isolated prod-db-01 at T+9 and rejected the restore. Plan says the on-call confirms assistant output against the source alert before any action. Room did. Follow-up: Wei L checks whether that November 2024 playbook is still the top retrieval hit, and retires it if it is, by 24 October 2026.
Both rooms had an assistant. Only the second had someone look at the alert. The first costs you the database. You start a restore of a host that is still encrypting, and the packet later reads as if recovery was the decision you practiced.
On 6 October 2026, Andy Gombar, a staff detection and response engineer at Webflow, wrote up this gap from his own program. His team uses an assistant to triage alerts, pull playbooks, propose actions, and draft the post-incident write-up. A tabletop that never hands the room a wrong or stale answer, he argues, only tests the people, and the people are no longer the whole system. That is one company's account of its own tooling. It is not a count of how often assistants fail. The useful part is the inject, which you can run without their stack.
Plant the wrong summary
Write the summary before the session, from a playbook you know is stale. Do not tell the room it is wrong. Hand it over the way the assistant would: specific, confident, and easier than opening the console. One miss is enough. Get the cause wrong (backup, not encryption), or the document (November 2024, not the August 2026 isolate runbook), or the action (restore, and do not isolate).
If the room starts the restore, that is the finding. Write what the plan says next to what the room did. Do not score Priya, and do not score the assistant. The injects post is how to force a choice on a clock. This choice is narrower: open the alert, or act on the summary.
This is not the exercise where your product assistant discloses another tenant's data, and it is not an agent taking an action nobody asked for. Those are different scenarios, including the off-script agent case. This one is about the summary your on-call reads before they touch prod-db-01. The scenario library has a ransomware family you can drop this inject into. It does not have a separate family for a wrong triage summary.
Then take the assistant away
At T+40 the facilitator says the assistant is unreachable. It runs in the same identity tenant as prod-db-01, and that tenant is what the scenario just locked. Priya has not opened the raw EDR console on a live page since the assistant shipped in March.
A weak facilitation line reads:
Assume the tools are up and talk through what you would do.
A strong one reads:
T+40. Assistant unreachable. Priya has the EDR console and four minutes to say what the alert actually is, without the summary. If she cannot, write that. Wei is the only person who knows the August 2026 isolate runbook is in the corpus. Wei is not on the call. Seat empty. Marcus holds isolate until someone can read the alert.
The first costs you the night you need it. The only person who can read an alert without the assistant is the person who maintains the retrieval, and they are asleep. An empty seat is a finding. The invite-list post is how to write it down. If the plan does not name who confirms an assistant summary before an action, run the free plan self-check before you book the next one. An unnamed check gets skipped for the same reason an unnamed seat stays empty.
The draft is not the review
If the assistant also drafts the post-incident write-up, hand the room that draft at the end and let it repeat the backup story. The question is whether anyone corrects the cause before the draft becomes the file you keep. A write-up that says failed backup, over an alert that said encryption, is how the wrong cause gets filed. Use the free post-incident review template for the timeline and the cause the humans settled, with owners. It is a different document from the tabletop packet. Do not paste the assistant's draft in and call it the review.
What the packet has to hold
Four lines, in the file:
- The summary, verbatim. Cause, playbook revision, suggested action.
- Whether anyone opened the source alert. Who, and the elapsed time.
- The action taken. Isolate, restore, or wait, and whether it matched the summary.
- The stale playbook. An owner and a date for the retrieval check. If nobody owns it, the packet says so.
That is the decisions and gaps shape in our free evidence template. It sits with the review template and two others in the template library.
Catching a summary the facilitator planted shows that these named people checked a source alert in this exercise. It does not measure how often the assistant is wrong, and it does not show that isolate works on prod-db-01. A retrieval check and an isolate test answer those. This file is the decision.
Bottom line: put a wrong, specific summary in front of the room, and write down whether anyone opened the alert before they acted. The summary is an inject. It is not the incident.