Rehearse scenarios where an agent is steered by untrusted content, uses a credential it should not hold, takes a destructive action, leaks data through a tool, relies on a changed MCP server, or cannot be stopped quickly. Each tests a different part of your approvals, identity, logging and response.
How to run one
Keep it to sixty or ninety minutes. Give participants a short scenario, add injects every ten minutes, and ask for decisions, not essays. Include an engineer, the agent's sponsor, a security responder, someone from privacy or legal and a communications lead. Note gaps as you go and assign owners at the end.
Six scenarios
| Scenario | Inject | What it tests |
|---|---|---|
| 1. Poisoned document | A support agent reads a document containing hidden instructions and sends a customer list to an external address | Egress limits, approval for outbound data, detection |
| 2. Borrowed credential | An agent is found using a developer's personal token | Identity per agent, revocation, inventory |
| 3. Destructive command | An agent deletes a staging database that shares credentials with production | Environment separation, two approver rules |
| 4. Changed tool server | An approved MCP server adds a new tool overnight and the agent starts calling it | Allowlist drift, tool list monitoring |
| 5. Silent logs | The agent misbehaved but tool arguments were never logged | Audit trail quality, evidence gaps |
| 6. Cannot stop it | The sponsor is unreachable and nobody knows how to disable the agent | Kill switch, ownership, on call |
OWASP's guidance on excessive agency supplies useful discussion prompts for several of these: could the extension be narrower, could the permissions be smaller, was approval enforced downstream and not left to the model?
Questions for every scenario
- How did we find out, and how long did that take?
- Who has authority to stop the agent, and how do they do it right now?
- What was the agent's registered scope, and did it exceed it?
- What evidence do we have, and where is it?
- Is personal data involved? If so, who decides, and what clock may apply? The GDPR text sets a 72 hour limit from awareness for notifying a supervisory authority when a breach is likely to risk people's rights, so involve privacy early.
- What do we tell customers, staff and partners, and who approves it?
- What control would have prevented or limited this?
What good looks like
A strong response stops the agent within minutes by disabling its identity, preserves logs before cleanup, states what is known and unknown, avoids guessing about cause in public, and ends with specific fixes with owners and dates. A weak one debates blame, edits evidence or relies on the agent's own account of what it did.
After the exercise
Write a one page summary: scenario, timeline, gaps, actions, owners, due dates. Track the actions to closure, and rerun the same scenario in a few months to see whether the fix worked. Rotate scenarios so that different people practice different roles.
Keep it honest
Avoid scenarios that are so contrived that nobody learns anything, and avoid ones that make a single person the villain. The purpose is to find gaps in process and tooling, not to assign fault.
Try it yourself
Click through it at your own pace, or open it full screen. Use it as a prompt: how would your team learn about a new issue, and who would act first?
Safeguard offers agent identity, MCP Guardrail and compliance and evidence automation that you can bring into these exercises. A free scan is at https://gold.safeguard.sh/scan.
Quick check
How many scenarios should we run at once?
One per session. Depth beats coverage, and you can rotate through the list over a year.
Who should facilitate?
Someone who is not responsible for the agents being tested, so they can ask uncomfortable questions.
Sources
Last reviewed: 19 October 2026.
