How to Run an AI Security Awareness Session Your Team Remembers

The most memorable AI security awareness sessions have a simple arc: participants try a safe, fictional AI workflow; they watch an ordinary request cross a trust boundary; and they leave with two or three controls they can apply to their own work. A 45-minute format is long enough to create that moment without turning the session into a lecture or a penetration test.

Start with a behavior, not a definition

Do not open with twenty slides of terminology. Open with a question your audience recognizes: “If an assistant reads a support ticket, should the ticket be allowed to change what the assistant is instructed to do?” Give people a minute to vote, then show the workflow they are about to use.

The first explanation can be short. Prompt injection is a failure mode in which untrusted text steers an AI application away from its intended task or authority. The Direct Prompt Injection lesson has the full technical explanation; in the room, you only need enough context for people to notice the boundary they are about to test.

Your opening should also set the safety rules. Use fictional data. Do not paste company secrets, customer records, credentials, internal URLs, or real attack strings into the exercise. Do not probe a public chatbot or a vendor account. The goal is to understand how a design can fail and how to contain it, not to obtain access to another system.

A 45-minute run of show

Minutes 0–5: make the stakes concrete

Describe the fake application in one sentence. “This is PeoplePoint HR Assistant, a fictional self-service portal that helps employees understand benefits and routes requests.” Tell participants that the assistant is protecting a fictional record and that the exercise has a narrow objective.

Ask the room to predict what should happen when a user makes an unusual request. Do not promise that the model will fail. The lesson is stronger when the group has to inspect the result rather than wait for a staged reveal.

Explain the boundary in plain language: the assistant may be allowed to summarize a policy, but a user claim of being an auditor is not proof of authority. That is the bridge to Role-Based Deception, which participants can study after the session.

Minutes 5–10: form small teams

Teams of two or three work well. One person explores the input field, one keeps notes, and one watches the response and any visible workflow state. For a remote session, use a shared chat or a simple table with columns for “text we controlled,” “data the assistant could see,” “response,” and “control that should have helped.”

Make the challenge objective specific. A broad goal such as “break the AI” rewards noise and makes the debrief shallow. A narrow goal such as “determine whether the fictional assistant can disclose the protected HR field” gives the room a shared observation. If you use the embedded challenge below, point participants to the objective key shown by the interface rather than revealing the answer.

Minutes 10–30: let the room investigate

Give teams time to try different approaches. Encourage them to begin with ordinary language and to compare one change at a time. They may explore a claimed role, a story frame, a multi-turn conversation, or a formatting variation, but do not hand out a working payload. The interesting question is why an attempt changed the model’s behavior and what application control was missing.

Circulate with three prompts:

• “Which part of the request is the model treating as authority?”
• “What is the assistant allowed to see or do if it follows that request?”
• “Would the same behavior be dangerous if the record were real?”

If a team succeeds quickly, ask them to reproduce the observation with a harmless fictional value and write down the boundary that failed. If nobody succeeds, that is also useful. A model that resists one approach is not proof of security, but it creates a chance to discuss layered defenses and how to test the application rather than chase a single phrase.

For a technical audience, add a second round that changes the source of the text. Place a fictional instruction in a document or ticket that the assistant is asked to summarize. That shifts the discussion toward Indirect Prompt Injection and External Sources. Keep the source synthetic and the effect observable.

Minutes 30–40: debrief the failure path

Stop the room and reconstruct one successful and one unsuccessful attempt. Draw four boxes on a board:

1. Who supplied the text?
2. What instructions and data were in context?
3. What did the model output or try to do?
4. What should the application have checked independently?

The first two boxes prevent the conversation from becoming “the model was fooled.” The third shows that the output is only part of the event. The fourth turns surprise into an engineering action.

Ask teams to separate model behavior from authorization. A response can sound confident and still be untrusted. A refusal can sound safe while a tool call has already occurred. If a system is connected to payroll, support, email, or deployment controls, inspect side effects and logs, not just the assistant’s wording.

Minutes 40–45: finish with controls

Close with a short control stack. Keep secrets out of model context when the model does not need them. Enforce identity and authorization in application code. Give tools the smallest useful permissions and validate every argument. Treat retrieved documents and user fields as untrusted data. Require confirmation for sending, publishing, changing, or deleting. Log source provenance, retrieval, tool calls, and reviewer decisions.

Invite each participant to choose one workflow at work and write down its equivalent four-box map. A support assistant, document summarizer, or sales copilot can all be reviewed with the same questions. The Exploiting Agent Tool Chains lesson is a useful follow-up for teams whose assistants can take actions.

Pick the right room and challenge

For a general audience, use a familiar workflow with one protected fictional field. HR, support, shipping, and document review are easier to understand than a model-training pipeline. For developers and security engineers, pair the direct exercise with an indirect content source and ask them to record the data-flow boundary.

The challenge should be short enough that participants can understand the application before they start. Keep the interface realistic but the data intentionally fake. A good exercise lets a participant say, “I see why this text looked relevant to the model, but the application should not have treated it as authority.”

Use the competition, but point it at the lesson. A live leaderboard is what turns a quiet room into a loud one, so put it on the big screen and score the objectives, not the most dramatic output. When someone tops the board, ask them to explain which control was missing, not to share their exact wording. Don’t hand out reusable attack strings afterwards: a solve shows a missing control in a sandbox, not a general exploit against a vendor.

Make the debrief stick

People remember a failure when they can explain the mechanism. Ask one person to narrate the user-visible request, another to name the untrusted text, and a third to identify the control that would have stopped the side effect. Then ask what would change if the assistant had read real data or possessed a write tool.

You can also turn the result into a small review task. Give the team a fictional architecture diagram and ask them to mark where they would enforce identity, provenance, tool permissions, output validation, and human approval. Compare the diagram with the NIST AI Risk Management Framework and the OWASP LLM01 guidance, but keep the exercise grounded in the workflow they just experienced.

After the session

Send participants the technique lessons rather than a transcript of the winning attempts. Encourage them to read Crescendo Attack for multi-turn pressure and Sequences / Delimiters for boundary confusion. Ask managers to sponsor one follow-up threat-modeling session for the highest-risk AI workflow in the team.

If you want a ready-to-run version of this format, use the free facilitator kit below. If you want help adapting the exercise to your team’s AI workflow, see the host a PromptInjects event page. The handoff should be simple: a memorable failure opens the conversation, and an application-level control closes it.