Executive Training on AI Risk: Test It With a Tabletop

Published October 26, 2026

By Charles Givre

CISOAI riskexecutive trainingincident responseLLM security

A good test for executive training on AI risk: a week after the course, can your leadership team run a 90-minute AI incident tabletop without the AI team in the room to translate? If the answer is no, the course taught vocabulary. Vocabulary is cheap. The NIST AI RMF fits on one slide, and nobody has ever contained an incident by naming a framework function.

Below is the scenario I would use, the decisions it forces, and the risk register entry a leader should be able to write when it ends. Use it to grade any course you are considering, including ours.

The scenario: a zero-click leak through your AI assistant

Base it on something that happened. In June 2025, researchers at Aim Security disclosed EchoLeak, tracked as CVE-2025-32711, a critical information disclosure flaw in Microsoft 365 Copilot. An attacker sent an ordinary-looking email containing hidden instructions. The victim never opened it. Later, when the victim asked Copilot an unrelated work question, the retrieval step pulled that email into the model’s context, the model followed the planted instructions, and internal data left the tenant through a crafted link. Microsoft fixed it on the service side.

MITRE ATLAS classifies the core move as AML.T0051.001, indirect prompt injection, and the outcome as AML.T0057, LLM Data Leakage. For the tabletop, rewrite it as your own system: the assistant your company rolled out last year, connected to mail, SharePoint, and the ticketing system.

Run it in four injects, 20 minutes each.

Inject 1 (T+0). A threat intel feed reports a technique against assistants like yours. Your vendor has not commented. Questions: Who owns this system? Is there a kill switch, and who holds it? Often the owner turns out to be “IT, sort of” and the kill switch is a support ticket to the vendor.

Inject 2 (T+20). Your SOC finds outbound requests from the assistant to an unfamiliar domain, carrying URL parameters that look like encoded text. Questions: Do you retain prompts, retrieved documents, and model outputs? For how long? Can you tie a specific output to the document that caused it? Without retrieval logs, you cannot scope this, and “we don’t know what was exposed” becomes the answer to every question that follows.

Inject 3 (T+40). Decoded parameters include fragments of an HR investigation file. Questions: Is this a reportable breach under your obligations (state breach laws, GDPR Article 33’s 72-hour clock, sector regulators)? Who decides? Counsel will ask whether “the model chose to send it” changes anything. It does not. The data left your environment through a system you deployed.

Inject 4 (T+60). The vendor ships a fix and says no customer action is required. Questions: Do you turn the assistant back on? What evidence would you need first? “The vendor says it is fixed” is a claim. A rerun of the attack with a measured result is evidence.

Leave the last 30 minutes for the debrief, and write down every question nobody could answer. That list is your real AI risk backlog.

Why the scenario matters more than the framework

My Black Hat 2025 talk was called “Input Is All You Need,” and the argument is the reason this tabletop works. A language model treats anything that reaches its context as potential instructions. An email, a ticket comment, a PDF in SharePoint. So the security questions for any AI system are always the same two: what untrusted text can reach the model, and what can the model do once it reads it?

A leader who learned a list of “top AI risks” instead will stall when the next incident does not match the list.

The precedent on accountability is already set. In Moffatt v. Air Canada, 2024 BCCRT 149, the airline argued its chatbot was responsible for its own wrong answer about bereavement fares. The tribunal rejected that and held the company liable for what its chatbot told a customer. Expect the same reasoning when an assistant leaks data instead of giving bad advice.

The artifact a trained leader should be able to write

At the end of the tabletop, each AI system should have a risk register entry that someone outside the AI team can audit. Here is a minimal one for the scenario above:

system: corp-assistant (M365 Copilot, mail + SharePoint + ServiceNow connectors)
owner: VP IT Operations            # a named person, not a team
untrusted_inputs:
  - inbound email (any external sender)
  - SharePoint docs editable by contractors
  - ticket comments from customer portal
capabilities_after_read:
  - render links and images in responses   # exfil path
  - search all mail the user can access
threats:
  - AML.T0051.001   # indirect prompt injection
  - AML.T0057       # LLM data leakage
controls:
  - external-sender mail excluded from retrieval    # status: not deployed
  - response links restricted to allowlisted domains # status: vendor-dependent
  - prompt, retrieval, and output logs retained 90 days # status: 30 days today
evidence_required_to_reenable:
  - red team rerun: injection success rate over 50+ trials, before and after fix
kill_switch: tenant admin toggle, held by on-call IR lead
nist_ai_600_1_risks: [information security, data privacy]

Nothing in that file requires knowing how a transformer works. The evidence_required_to_reenable line is the one most leaders leave blank, and it is the line that turns “the vendor fixed it” into a decision you can defend. For what that rerun should look like, see our post on counting trials in AI red team findings. The nist_ai_600_1_risks field maps to the 12 generative AI risks in NIST AI 600-1, so auditors get a standard reference.

Grading an executive AI risk course against this

Ask the provider four questions before you buy:

  • Does the course use a real incident as a worked example? EchoLeak, the Air Canada ruling, or the 2024 deepfake video call that cost the engineering firm Arup roughly US$25 million. Hypotheticals are easier to teach and easier to forget.
  • Do participants touch a model? One hour of trying prompt injection on a live system teaches more about why a system prompt is not a control than a day of slides. In our labs, that hour happens in the free AI Training Dojo.
  • Does it cover incident decisions, or only governance? Governance answers “should we deploy this.” Risk training also has to answer “what do we do when it fails.”
  • Do you leave with an artifact? A risk register entry, a tabletop script, a vendor question list. If you leave with only notes, there will be nothing to show your team on Monday.

Where this falls short

A tabletop tests decisions, not controls. Your team can make every call correctly and still be exposed because retrieval logs were never turned on. Pair the exercise with a technical check by your security engineers. And if your organization has not deployed any AI system with access to internal data yet, start with an inventory instead; the proxy log exercise in our CISO post will tell you whether that is actually true.

GTK Cyber’s A Cyber Executive’s Guide for Artificial Intelligence covers AI threats, governance, and vendor evaluation for security leaders, and we run it privately for leadership teams through an executive briefing.

Frequently Asked Questions

What should executive training on AI risk for security leaders cover?
Four things, judged by what the leader can do afterward. Read an AI system's data flows well enough to see where untrusted text reaches the model. Score an AI risk with measured evidence instead of a vendor's adjective. Make the incident calls an AI system forces (disable the feature, notify, preserve prompts and retrieval logs). Tell a real control from an instruction to the model. A course that leaves out the incident part is a governance briefing, not risk training.
Why use a tabletop exercise to judge AI risk training?
Because a tabletop exposes the gaps that slides hide. Leaders who can recite NIST AI RMF still stall on questions like who can switch off the Copilot integration at 2 a.m., whether the prompt history is retained long enough to scope the incident, and whether a model output that leaked customer data counts as a reportable breach. If your team cannot answer those, the training did not stick.
Who should be in the room for an AI incident tabletop?
The CISO, the incident response lead, the owner of the AI system (often an IT or product leader), legal or privacy counsel, and communications. Keep the data science team out of the first run. The point is to find out whether the leadership team can make the calls without the people who built the system translating for them.
Is a tabletop useful if we only use AI through SaaS products?
Yes, and the scenario gets simpler. Most of the decisions move to the vendor contract: how fast the vendor notifies you, what logs they hand over, and whether you can disable the AI feature per tenant without losing the whole product. A tabletop is how you find out those terms are missing before you need them.

Related posts

Want to learn more?

Explore our hands-on AI and cybersecurity training courses.

View Courses