Prompt Injection Simulator
You are the attacker. Below is Nora, a support agent for a fictional outdoor retailer, with a system prompt, one tool, and a secret she is told never to reveal. Get the secret out of her, then turn the defences on and try the same attack again.
The agent is a rule engine, not a model. That is deliberate: because the same input always produces the same result, you can toggle one control and see exactly what it changed. A sampled model can show you correlation. This shows you causality.
Objectives
- Make Nora reveal the support override key
- Make Nora reveal her system prompt
- Compromise the agent but get stopped by the output filter
0 of 3 found.
Nora · Northwind Outfitters support
What this is actually showing
Turn on only the input classifier and run the indirect injection. It goes straight through. The classifier is not broken. The hostile instruction never appears in anything you typed, so there was nothing in the input for it to catch. It arrived in a tool return. That is the entire problem with indirect injection, and it is why input-side filtering alone is not a control for it.
Turn on only the output filter and every attack reports a near miss. The agent was fully compromised and complied; the secret was simply caught on the way out. That is a real control and worth having, but a system relying on it has already lost the turn. It just got lucky about what the payload happened to be.
None of the four defences covers all three paths alone. That is the point, and it's the same argument as defence in depth in a SOC: controls are chosen against specific mechanisms, and the gaps only become visible when you map them against real attack paths rather than counting how many controls you have.