Learn AI security by breaking it.
A free series that teaches LLM and AI application security the way you actually test it: short concept material, then a live in-browser lab where you run the loop — Attack → Defend → Verify. You exploit a real target, implement the fix, and prove the fix holds. No setup, no API keys, no Docker.
Some labs are free with an account; the rest are on a paid plan.
- No setup
- No API keys
- No Docker
Who is this for?
- Penetration testers and AppSec engineers who already know web application security and need to add AI/LLM components to their testing scope. Applications are shipping with LLM features now, and clients are starting to ask for AI testing.
- Security engineers and developers defending AI systems — the defensive track of every part walks you through implementing the fix and checking it holds.
What do I need to start?
- Familiarity with web application security concepts (injection, access control, SSRF-style trust boundaries) is enough.
- No ML knowledge required. LLMs are treated as components in an application — the security testing mindset transfers directly.
You already know the shape of these bugs
LLM vulnerabilities are the trust-boundary bugs you already hunt, on a new surface. The exploitation instinct transfers — but the defenses don’t, and that’s the part worth learning.
The one-sentence versionPrompt injection is to LLM apps what SQLi was to web apps in 2002 — the canonical first bug — except the industry hasn’t found its parameterized queries yet, and may not. That’s why the defensive track here isn’t “use prepared statements”; it’s layered controls you verify under attack.
Ten years ago I published a free Android application security series at manifestsecurity.com. At the time, Android security had almost no free material to learn from — web security had plenty. That gap is why I wrote it. It still gets traffic today, and people still message me saying it’s how they learned Android pentesting.
AI security has that same gap right now. So I’m rebuilding it — this time for AI.
The curriculum
Six paths are live now, and a new part ships every week — each mapped to the OWASP LLM Top 10 (2026), the Agentic AI Top 10, and the MCP Top 10, so you can cite a recognized framework in your reports.
AI Security Foundations
Build the map before you specialise. The trust-model shift that makes LLM security different, just enough of how a model works, the attack surface where every OWASP LLM risk lives, and how it all maps to the AppSec you already know.
- 1Why LLM security is different
- 2How LLMs work, just enough
- 3Why models follow instructions, refuse, and make things up
- 4Anatomy of an LLM app: the attack-surface map
- 5Prompts: engineering vs injection
- 6The LLM threat model, mapped to AppSec
- 7Orientation: OWASP, the two tracks, and scope
- 8The lab toolkit: how this platform works
Prompt Injection
The attack every other LLM exploit rides on. Work the full technique tree — direct, jailbreaks, encoding, smuggling, context, indirect, and tool- and agent-mediated — then the controls that actually hold, each with a live target to try it on.
Sensitive Information Disclosure
Anything the model can see, it can be talked into repeating. Work the ways an assistant gives up secrets, internal documents, personal data and other tenants' records — then the controls that keep sensitive data out of its reach, with live targets to try them on.
Hidden Context Exposure
The system prompt is not a secret store. Work the ways an assistant gives up its hidden instructions, its tool definitions and anything planted in them: asked for directly, carried out through a translation or an encoding, completed from a primed sentence, released to a claimed debug mode or audit, and pulled out by a document it retrieved. Then the fix that holds, with live targets to try it on.
Vector & Embedding Weaknesses
A vector index ranks by similarity and checks nothing else. Work the ways a RAG pipeline hands over what it should not: another tenant's chunk, a wider net than the question needed, a planted document that steers the answer, a contributed page that outranks the official one, content everyone believes was deleted, and the second retrieval paths a scope filter never covered. Then the controls that hold, with live targets to try them on.
Improper Output Handling
Whatever the model writes is attacker-influenced input to whatever reads it next. Work the sinks where that goes wrong: a markdown renderer that fetches images, an HTML view, a generated SQL query, a template engine or eval call on the server, a spreadsheet export, a URL fetcher or XML parser, and a backend that acts on the model's JSON. Then the controls that hold, with live targets to try them on.
Every path dated below is already in the app on the paid plan, and every path has a defensive track there too. Subscribe and work them today instead of waiting for the weekly drop.
Turn an agent's tools against it: over-scoped actions and the confused-deputy chain that makes a prompt trigger a privileged call.
Compromise what the app trusts before runtime — poisoned models, tampered dependencies, and unvetted third-party components.
Corrupt what the model learns or retrieves — poisoned training data, fine-tunes, and RAG sources that steer it.
The agent-specific risks: goal manipulation, unsafe tool use, memory poisoning, and multi-agent trust failures.
Model Context Protocol risks: malicious tool descriptions, over-permissioned connectors, and consent/onboarding injection.
If you find this series useful, share it — same as the Android series, it only grows by people passing it around.
Suggestions, problems, or a topic you want covered: [email protected]
© 2026 GenAI Security Lab. All rights reserved. You may read, quote, and link to this material with attribution. Copying, republishing, redistribution, resale, or use to train models or build competing products is prohibited without prior written permission.