AI Tabletop Exercise: Turn the CISA Scenario Into a Control Test

An AI tabletop exercise should make the incident team prove how it detects a model-related failure and who can contain it. It should also show what evidence survives and which external parties receive useful information. A conversation about hypothetical risk is not enough. The exercise needs observable decisions against an escalating sequence.

The CISA JCDC AI exercise series provides a practical base. Its linked TLP:CLEAR scenario document moves from phishing and an AI-enabled email filter to a poisoned dataset and a malicious model. It then covers data exfiltration, continuity decisions, and public information sharing. The enterprise version should turn those events into tests rather than copy the script word for word.

TL;DR

• Build the exercise around one escalating service and assign a named owner to detection and containment decisions, communication and continuity decisions, and the restart decision.
• Give players incomplete evidence in timed injects, then grade whether they can reconstruct the affected AI routes and preserve a defensible timeline.
• Test model traffic controls alongside endpoint and supply-chain controls. Test credential and crisis-management controls separately without pretending one product covers all of them.
• End with failed-control evidence and corrective owners. Assign due dates and a retest. A discussion summary alone does not show readiness.

An AI tabletop exercise needs a measurable objective

CISA defines the exercise around incidents that actually or imminently jeopardize the confidentiality or integrity of an AI system, a system enabled or created by it, or information stored on those systems, with enough disruption to require intervention. Its four objectives focus on information sharing and multistage response, plus plan improvement and operational collaboration among government, industry, and international participants.

An enterprise should narrow that scope to a service it can trace. Choose an AI-enabled support assistant or coding workflow, a fraud detector, or a defensive agent. Record the approved model endpoints and identities; the data classes and suppliers; and the queues, tools, and shutdown authorities before the session. That baseline lets the facilitator ask whether the team noticed a real deviation.

My strong view is that a tabletop which ends in a slide deck is theater. It should leave behind a scored control record. The useful outcome states what the team observed and which authority made each decision. It also records how long the action took, what evidence was missing, and when the failed step will be tested again.

Use three escalating modules rather than one dramatic breach

CISA's first module establishes normal information sources and AI risk posture. It then introduces phishing and a recently updated autonomous email defense agent, followed by social reporting and an unexpected open-source model release. The second module reveals that malicious emails are reaching inboxes and asks how investigation and root-cause analysis change as internal updates and external sharing change with the accumulating evidence.

The third module identifies a poisoned training dataset and later a malicious model that silently exfiltrates queries and responses. It then moves into shutdown and continuity decisions, lessons learned, restricted information sharing, and public disclosure decisions. This order prevents players from jumping directly to a clean root cause that responders would not possess on day one.

Place a printed inject card face down at every seat. Put a timestamp in the upper corner and include only the evidence available at that moment. The small physical constraint exposes a common weakness: teams often rely on facts that arrived later when explaining an earlier decision.

A practical enterprise sequence can follow the same logic:

1. Establish the expected service and route, then name the owner and evidence sources.
2. Introduce a signal that could be conventional phishing or an AI-component failure.
3. Reveal a route or model deviation, or a dataset or supplier deviation, and require containment.
4. Force a continuity and restart decision before every fact is settled.
5. Ask what can be shared internally and what can be shared with partners or the public.

Grade control performance at each inject

Every inject should have an expected action and evidence source, plus a decision owner and time limit. Detection is not a pass when the team cannot identify the affected service. Containment is not a pass when one model route stops but queued jobs remain active through local tools or alternative credentials. The AI incident response playbook provides the wider containment and recovery sequence, while the AI agent kill switch explains why intake and workers, tools and credentials, and model routes need separate stop tests.

For routed model traffic, ask the team to retrieve a request record showing the authenticated principal and destination, the data classification and policy version, and the outcome. Then test whether a new request is denied under the containment policy. For the wider scenario, retrieve endpoint detections and software provenance, queue state and credential revocations, and supplier notices and communications approvals from their owning systems.

The score should distinguish absence from delay. A record found after 40 minutes may exist, but it did not support the five-minute containment decision. Give partial credit only where the control worked within the agreed operating target.

Convert lessons into owned corrective work

The hotwash should produce more than observations. For every failed or delayed action, record the affected service and control owner, the corrective action and due date, and the acceptance test and retest date. Link the item to the evidence that caused the failure, not to a vague theme such as "improve monitoring."

Use the lifecycle release record described in CISA AI guidance when the correction changes an AI component or route, a data source, or an operating assumption. The restart decision should cite the completed corrective tests and any residual risk accepted by the named authority.

CISA says lessons from its exercise would inform an AI Security Incident Collaboration Playbook and that a later exercise would test and validate that playbook. Enterprises should adopt the same loop: exercise and revise, then retest. A control that has never faced the revised scenario remains a design claim.

DeepInspect

DeepInspect can support the part of this exercise that crosses deliberately routed, authenticated HTTP traffic to AI endpoints. It can evaluate those requests against identity and destination, plus data classification and policy, then preserve the resulting decision record. It does not inspect bypass traffic or terminate local processes. It also does not validate training datasets, revoke tool credentials, or make legal and communications decisions. Those controls need their own owners and evidence in the exercise.

Book a demo today.