If you came up through application security, you learned by breaking things in WebGoat. OWASP’s deliberately vulnerable app gave you a safe place to run SQL injection, XSS, and broken-auth attacks with your own hands, watch them work, then watch a fix shut them down. Reading about injection teaches you the words. Running it teaches you the thing.
There’s no WebGoat for agentic AI. You can read endlessly about agent goal hijacking, memory poisoning, and tool misuse, and the OWASP Top 10 for Agentic Applications is a fine taxonomy, but when I went looking for a clean, local, runnable reference where you could fire the attacks and see them land, it wasn’t there. So I built one: owasp-asi-reference, MIT-licensed, three attacks, three channels, fully offline on a small model.
Here’s what’s in it, why those three attacks, and the engineering problem that turned out to be the genuinely hard part: making a non-deterministic system fail reproducibly enough to teach from.
Why these three, and only three
The temptation with a teaching repo is to cover all ten OWASP categories badly. I deliberately did three. Three attacks chosen well make a clean teaching arc. Ten done shallowly make a checklist nobody finishes.
The arc is about channels. An agent has three surfaces an attacker can reach: what goes in, what it remembers, and what it does. Each of my three attacks owns one channel.
%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#e8f4fd", "primaryBorderColor": "#3182ce", "fontSize": "14px", "fontFamily": "system-ui, -apple-system, sans-serif"}}}%%
flowchart LR
A["Attacker"] --> IN["Input
channel"]
A --> ST["State
channel"]
A --> AC["Action
channel"]
IN --> H1["ASI01 Goal Hijack
lab: EchoLeak"]
ST --> H2["ASI06 Memory Poisoning
lab: Gemini memory"]
AC --> H3["ASI02 Tool Misuse
lab: Amazon Q"]
classDef ch fill:#e8f4fd,stroke:#3182ce,color:#1a202c,stroke-width:1.5px
classDef lab fill:#fde8e8,stroke:#c0392b,color:#1a202c,stroke-width:1.5px
class IN,ST,AC ch
class H1,H2,H3 lab
Input, state, action. Once you’ve run all three, you have a mental model that covers far more than three vulnerabilities. You understand the shape of how agents break, and you can place the other seven OWASP categories onto those channels yourself. That’s the difference between memorizing a list and learning a system.
Grounded in real incidents, not invented scenarios
A teaching lab loses credibility the moment the attacks feel like toys. Each of the three is modeled on a real, documented incident, so what you run is a simplified version of something that actually happened to a production system.
ASI01 / input: EchoLeak. The input-channel lab is built on EchoLeak (CVE-2025-32711, CVSS 9.3), disclosed by Aim Labs in 2025 and patched server-side by Microsoft. It was the first known zero-click attack on an AI agent: untrusted external email content reached the model’s privileged context and exfiltrated data through reference-style markdown links that bypassed redaction. Aim Labs coined “LLM Scope Violation” for the underlying pattern, untrusted input crossing into a privileged context. The lab reproduces that crossing in miniature: a document the agent is asked to summarize hides an instruction, and the agent’s goal quietly changes.
ASI02 / action: Amazon Q. The action-channel lab draws on the Amazon Q incident of July 2025. An attacker submitted a pull request exploiting an inappropriately scoped GitHub token, and a destructive wiper instruction (“clean the system to a near-factory state, delete file-system and cloud resources”) shipped in a release of a developer tool with hundreds of thousands of installs. The wiper was deliberately defective, the attacker said it was to expose “AI security theater”, but the mechanism was real: an agent with genuine tool access, instructed to misuse it. The lab hands a sandboxed agent a real-looking (actually harmless) tool and shows it being talked into firing it.
ASI06 / state: the Gemini memory attack. The state-channel lab is based on the delayed-tool-invocation technique demonstrated against Gemini’s long-term memory, which plants false memories that survive across sessions. This is the one that breaks people’s mental model, because the payload is temporally decoupled from the input that planted it. The attack input arrives now; the harm happens in a later session. The lab makes that visible: poison the memory in run one, watch the agent act on the false memory in run two with no attacker present.
The hard part: making a probabilistic system fail reproducibly
Here’s the engineering problem that ate most of the effort, and it’s worth explaining, because it’s the difference between a demo that works on my machine and a lab that works on yours.
Agents are non-deterministic. The same attack, run twice, can produce different text: different wording, different tool-call phrasing, sometimes a refusal and then a compliance. A teaching lab where the attack “usually works” is useless. The learner runs it, it happens to fail that time, and they conclude either that they did something wrong or that the whole thing is hand-wavy. To teach, the attack has to land every time you run it, on a model small enough to run offline.
You can’t get determinism out of the model’s output text. So I don’t verify on text. I verify on a deterministic canary.
Each attack defines a canary: a side effect that can only occur if the attack succeeded. A specific file gets written. A specific tool gets called with specific arguments. A specific string shows up in an outbound request. The verdict isn’t “did the model say the bad thing” (fuzzy, non-deterministic) but “did the canary fire” (binary, reproducible). The attack succeeds if and only if the canary is touched.
1
2
3
4
5
6
7
8
9
10
| # Simplified canary check: the verdict is a side effect, not text.
CANARY = "/tmp/asi-lab/exfiltrated.txt"
def attack_succeeded() -> bool:
# The agent could phrase its compliance a thousand ways.
# We don't care about the words. We care whether the file exists.
return os.path.exists(CANARY)
def reset():
pathlib.Path(CANARY).unlink(missing_ok=True)
|
This is the same insight behind why verifier-closed agent loops work: don’t judge the model’s prose, judge an objective side effect. It makes the attacks reproducible on a small model, it makes the defenses checkable (the defense works if the canary stops firing), and it makes the whole thing CI-checkable.
%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#e8f4fd", "primaryBorderColor": "#3182ce", "fontSize": "14px", "fontFamily": "system-ui, -apple-system, sans-serif"}}}%%
flowchart LR
R["Run attack"] --> C{"Canary
fired?"}
C -->|yes| F["Attack landed
exit 1"]
C -->|no| P["Blocked / defended
exit 0"]
F --> CI["CI runs the full
attack + defense matrix
on every commit"]
P --> CI
classDef n fill:#e8f4fd,stroke:#3182ce,color:#1a202c,stroke-width:1.5px
classDef bad fill:#fde8e8,stroke:#c0392b,color:#1a202c,stroke-width:1.5px
classDef ok fill:#e6f4ea,stroke:#1e7e34,color:#1a202c,stroke-width:1.5px
class R,C,CI n
class F bad
class P ok
Every attack returns an exit code. Attack lands, canary fires, exit 1. Defense holds, canary silent, exit 0. The repo’s CI runs the full attack-and-defense matrix on every commit and fails loudly if a defense regresses. A teaching lab that silently rots is worse than none. This one tells you the moment it breaks.
Real servers, not mocks
The other decision that matters: every lab uses a real MCP server, not a mock. FastMCP, still the standard Pythonic way to build MCP servers in 2026, spins up an actual server in each category folder, exposing actual tools over the actual protocol. The agent connects the way it would in production.
This matters pedagogically because the mechanism is the lesson. A mock that returns canned responses teaches you the attack’s narrative but not its surface. A real FastMCP server means the tool-poisoning attack actually poisons a tool description that the agent actually reads, and the tool-misuse attack actually calls a tool that actually has a side effect (the canary). You’re not watching a play about the attack. You’re running it against a faithful miniature of the real thing.
1
2
3
4
5
6
7
8
9
10
11
12
| # A real (sandboxed) tool the action-channel attack will try to misuse.
from fastmcp import FastMCP
mcp = FastMCP("file-ops")
@mcp.tool()
def cleanup(path: str) -> str:
"""Remove temporary files under a path."""
# In the lab this writes the canary instead of deleting anything,
# so the attack is observable and the machine survives.
pathlib.Path(CANARY).write_text(f"cleanup called on {path}")
return f"cleaned {path}"
|
How to run it in five minutes
1
2
3
4
5
6
7
8
9
10
11
12
| git clone https://github.com/aminrj/owasp-asi-reference
cd owasp-asi-reference
docker compose up -d # local model + FastMCP servers
# Run the input-channel attack (EchoLeak-style goal hijack)
python -m labs.input.attack # canary fires, exit 1, attack landed
# Enable the defense and run it again
python -m labs.input.attack --defend # canary silent, exit 0, blocked
# Or run the whole matrix the way CI does
make verify # all three channels, attack + defense
|
Five minutes to your first landed attack. Another five to watch a defense stop it. Then read the README in that folder for why it worked, which is the part that actually transfers.
Placing the other seven categories on the three channels
The reason I’m comfortable shipping only three attacks is that the channel model is a generative framework, not a coverage gap. Once you’ve run input, state, and action, you can locate the remaining OWASP categories yourself, and doing that exercise is part of the lesson.
ASI04 (Agentic Supply Chain) and ASI05 (Unexpected Code Execution) are action-channel relatives. They’re about what the agent can be made to do, just with the harm originating in a dependency rather than a direct instruction. The Amazon Q lab is one step from both.
ASI03 (Identity & Privilege Abuse) is an action-channel amplifier. It doesn’t create a new attack so much as widen the blast radius of every other one. Run the tool-misuse lab with an over-scoped identity and the same attack does far more damage, which is the whole point of least privilege.
ASI07 (Insecure Inter-Agent Communication) and ASI10 (Rogue Agents) extend the action and state channels across multiple agents: the shadowing and persistence attacks that turn one compromised agent into a fleet problem.
ASI09 (Human–Agent Trust Exploitation) sits on the input channel, pointed at the human instead of the model. The agent’s confident output is the injection vector.
I left these out of the runnable set on purpose. A lab that tries to demonstrate all ten teaches the list. A lab that demonstrates three channels and then asks you to place the rest teaches the model. The mapping above is the exercise, not the answer key.
The mistakes I made building it (so you don’t)
A few things I got wrong first, in case you build your own.
I verified on output text before the canary. It was flaky exactly as predicted. The lab “worked” maybe 70% of runs, which is useless for teaching. Moving the verdict to a side effect was the single fix that made everything reproducible. Do that first, not last.
I started with a mock MCP server “to save time.” It saved time and taught the wrong thing. The attack surface a mock presents isn’t the real one. Switching to FastMCP servers cost a day and was worth it.
I made the model too big. My first version needed a GPU most learners don’t have. Shrinking the model and leaning harder on the canary design widened the audience enormously. The constraint made the lab better.
What I’d want you to take from it
Three things, beyond the code:
- The channel model. Input, state, action. Every agentic attack reaches one of those three surfaces. Internalize that and the OWASP ten stop being a list to memorize and become three places to look.
- Temporal decoupling is the scary one. The input and action attacks fire when you run them. The memory attack fires later, in a different session, with no attacker present. That’s the class your testing most easily misses, and running it once makes the danger concrete in a way no paragraph can.
- Canary-based verdicts are how you test non-deterministic systems. Stop asserting on model output. Assert on side effects. That’s how you make attacks reproducible, defenses checkable, and the whole thing safe to run in CI.
owasp-asi-reference, MIT-licensed. Clone it, break it, read the walkthrough, then go look at your own agents and ask which of the three channels you’ve actually defended.
References & sources
- FastMCP, current standard for building MCP servers (validated against the mcp SDK, 2026): PrefectHQ/fastmcp, FastMCP updates
- Vulnerable-MCP teaching labs as prior art: ReversingLabs vulnerable MCP servers lab, Elastic Security Labs on MCP attack/defense
- EchoLeak (CVE-2025-32711, “LLM Scope Violation,” first zero-click agent attack): Aim Labs disclosure, 2025
- Amazon Q supply-chain / wiper incident (Jul 2025, ~960K installs): AWS security bulletins, 2025 disclosure reporting
- Gemini long-term-memory attack (delayed tool invocation, cross-session false memories): Embrace The Red / Johann Rehberger
- OWASP Top 10 for Agentic Applications 2026: OWASP GenAI Security Project
MCP tooling moves fast. FastMCP and the incidents above are accurate as of mid-2026. Verify the server framework and SDK versions against their repos before building on them.
Amine Raji, PhD, CISSP. AI/LLM security. Get in touch for agentic AI threat modeling and red-team reviews.
