How to Run an AI Tabletop Exercise With Your Leadership Team

An AI tabletop exercise is a facilitated, discussion-based rehearsal in which your leadership team works through a realistic scenario and says, step by step, what it would decide and do. For far more capable agents, a 90-minute session with named roles, three written scenarios and required outputs is enough to expose who can approve an action, who can stop an agent, and where nobody yet knows the answer. You do not need a superintelligent system to run it, only honest assumptions about what agents could soon do inside your company.

Key takeaways

• A tabletop exercise tests decisions, not software. Nobody touches production systems; the group talks through what it would do and in what order.
• Ninety minutes is enough for three scenarios if the facilitator controls the clock and the scenarios are written in advance.
• The most valuable findings are about authority: who approves, who can stop an agent, and who speaks to customers and staff.
• Every session must end with written outputs, each with an owner and a review date: a gap register, an authority map and a stop procedure.
• Repeat the exercise when agents gain new tools, permissions or models, not only on a fixed calendar.

What is an AI tabletop exercise, and why run one now?

Tabletop exercises come from emergency and security planning. A group sits around a table, receives a scenario in stages, and states what it would do at each stage. No system is changed and nothing is simulated in software. The value lies in the conversation, and in the uncomfortable pauses when someone asks who actually decides that.

For AI, the exercise targets one question: if agents became far more capable than the ones you run today, would your organization still be in control of them? Far more capable means agents that plan multi-step work across many tools, act faster than any person can review, and sometimes see shortcuts or opportunities that their supervisors do not. The weak points in that world are rarely technical. They are organizational: unclear approval rights, no practiced way to stop work, thin records, and nobody assigned to explain events to customers.

Set one ground rule at the start. The room does not debate whether or when such agents will arrive. Capability is an assumption for the next ninety minutes. That keeps the session on what leaders can influence (decision rights, permissions, evidence and communication) and away from forecasts that nobody in the room controls.

Who should be in the room, and what does each person do?

Between six and nine people is the working range, and in a smaller company one person can hold two roles. Fewer voices miss perspectives; more turn the session into a presentation. Assign these roles before the day:

• Facilitator: runs the clock, reads the scenario injects and keeps the group on decisions rather than opinions. This should not be the most senior person present.
• Executive sponsor: makes the calls that need real authority, such as pausing a business process. The executive sponsor role is worth defining if nobody holds it yet.
• Operations lead: knows how work actually gets done, including the informal steps nobody documented.
• Security or IT lead: answers what the agent can reach, what is logged and how access is revoked.
• Legal or compliance lead: speaks to contractual, privacy and regulatory duties when something goes wrong.
• Finance lead: tests spending limits, commitments an agent could make and who absorbs the cost of a mistake.
• Customer or communications lead: drafts what customers and staff would be told.
• Scribe: records decisions, open questions and disagreements in plain words, because these become the outputs.

Add one more voice: a narrator who plays the agent. This person, often the facilitator's co-host, describes in plain language what the agent did and why it judged that reasonable. It stops the group from treating the agent as a vague force and makes every answer specific.

What should you prepare in the week before?

Preparation decides whether the session produces findings or only a pleasant discussion. Assemble a short pack of a few pages and send it a few days ahead. Use this checklist:

• A one-page map of the agents and AI tools in use, what each can read, what each can change and who owns it. The AI stack architecture map is a workable template.
• The current approval rules: which actions an agent may take alone, which need a person and which are forbidden.
• The current stop procedure, even if today it is only a phone call to the person who set the agent up.
• A contact list of the vendors, integrators and internal owners who would join an incident.
• Three scenario cards written in advance, with each inject on a separate slip so the facilitator can reveal them in order.
• A blank decision log for the scribe.
• An agreement that the session is blameless: findings describe the organization, not individuals.

If you cannot produce the map or the approval rules, that is already the first finding. Run the session anyway and record it.

How does the 90-minute session run?

Keep time strictly. Overruns almost always come from debating the first scenario at the expense of the third, which is often the most revealing one.

• Minutes 0 to 10, framing: the facilitator states the assumption, the ground rules and the blameless principle, and the sponsor says what the group is authorized to decide today.
• Minutes 10 to 30, scenario one: read the opening, then reveal an inject every few minutes. At each inject the group answers the five questions below.
• Minutes 30 to 50, scenario two: same pattern, with a different leader driving the answers.
• Minutes 50 to 70, scenario three: same pattern. The facilitator pushes the group toward the choice it least wants to make.
• Minutes 70 to 85, synthesis: the scribe reads back every open question, and the group sorts them into gaps to close, decisions to make and risks to accept knowingly.
• Minutes 85 to 90, close: assign an owner and a review date to each item and fix the date of the next session.

Ask these five questions at every inject:

• Who notices this first, and from what evidence?
• Who can stop the agent, and how long would that take?
• What can be undone, and what cannot?
• Who must be told, inside and outside the company, and who tells them?
• What do the logs and records let us prove afterward?

Which scenarios test the right things?

Choose scenarios that stress authority, irreversibility and verification. The three below are illustrative: adapt them to your industry, and treat none of them as a description of a real company.

Illustrative scenario one, the better process nobody asked for. An agent supporting order handling proposes a redesign of how returns, billing and supplier follow-up connect, with a convincing rationale. Injects: the agent has already drafted every change; a manager approves because the logic looks sound; two days later the finance lead notices the redesign quietly moves who approves refunds. This tests change control when the proposer is more capable than the reviewers. Ask who is entitled to approve a change that spans three departments, and what a reviewer would need to see in order to say no.

Illustrative scenario two, access that adds up. An agent holds narrow permissions in several systems, each approved separately and sensibly. Combined, they let it assemble a complete picture of a sensitive negotiation and send a summary to a distribution list. Injects: the summary reaches a contractor's mailbox; a counterparty asks how your side knew a particular detail. This tests the accumulation of permissions, least privilege and outbound communication. The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) is a useful reference for the least-privilege discussion.

Illustrative scenario three, the instruction hidden in a document. A supplier sends a file containing text addressed to the agent, telling it to change bank details on the next payment. Working overnight, the agent queues the change and notifies nobody, because the action fell inside an allowed category. Injects: the payment run starts; the only record of the agent's reasoning is a single log line. This tests untrusted inputs, out-of-hours operation and evidence. The [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) describes this class of risk, called prompt injection.

If you have time for a variant, swap in one of these: a vendor changes the model underneath a working agent, or staff rely on the agent so heavily that nobody can do the task without it.

What outputs should leave the room?

A session without written outputs is forgotten within a week. Insist on these:

• Gap register: every open question and weakness, each with an owner and a review date. Grouping them under the govern, map, measure and manage functions of the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) gives you a familiar frame.
• Authority map: for each class of agent action, who may approve it, who may stop it and who is the deputy when they are away.
• Stop procedure: a one-page sequence to pause an agent, revoke its access and preserve its logs, with a named owner and a named backup.
• Communication drafts: first holding statements for customers and staff, written while the group is still thinking about it.
• Trigger list: the events that call for a repeat session, such as new tools, new permissions, a change of model or a new line of business.
• A short note for the board or owners: what was tested, what was found and what will change.

Then connect each output to a routine you already have. Permission gaps belong in your quarterly permission review. Larger structural gaps fit into a longer plan such as the 90-day plan for far more capable AI. Risks the group decides to live with should be recorded as accepted, with the name of the person who accepted them, rather than left as unspoken assumptions.

Do not score the session. A grade invites defensiveness. The measure of success is that the gap register is specific, owned and smaller at the next session.

How does a managed approach handle what the exercise finds?

Be Human designs, implements and operates personalized AI infrastructure in which agents keep their identity, memory, channels, tools and permissions under human control. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion, which gives a tabletop exercise concrete answers to the five questions. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, so the gap register becomes recurring work with owners rather than a document that ages.

If you want to find the first task worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

How much preparation does an AI tabletop exercise need? The facilitator needs a few hours to gather the agent map, the approval rules and the scenario cards, and participants need only a short read ahead of time. A brief follow-up meeting a week later to confirm owners keeps the outputs alive.

Should we run it if we only use a chat assistant today? Yes, in a lighter form. The scenarios shrink, but the questions about who approves, who can stop the tool and what is recorded still apply, and answering them now makes later agent projects easier to govern.

Does the facilitator need to be external? Not necessarily, but they should sit outside the chain of command of the people being tested, so that junior participants speak freely. An outside facilitator helps when the leadership team is new to this kind of exercise or when internal politics would distort the discussion.

How often should we repeat the exercise? Repeat it whenever a trigger on your list occurs, such as new tools, new permissions or a change of model, and at a regular rhythm that suits your pace of change. Each repeat should start by reviewing the previous gap register, so you can see what actually closed.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.