AI security: injection
Prompt injection happens because a language model receives instructions and data as one stream of tokens, with no structural boundary between them. This course explains that broken trust boundary and the confused deputy problem. It then maps the attack surface, from user messages to retrieved documents, tool results and stored examples. It covers what attackers want, why text-based defenses such as filters and delimiters fall short, and which architectural controls hold. It also treats model output as untrusted input and ends with a threat model review.
What you'll learn
- ✓Why a language model has no separate channel for instructions and data
- ✓How to map every input the model reads and who can write it
- ✓The four attacker objectives and how connected tools set their severity
- ✓Architectural controls: least privilege, authorization in code, human gates, egress control and isolation
- ✓How to handle model output safely when it is rendered, parsed or stored
- ✓How to test injection defenses by asserting that nothing happened
The broken trust boundary
Every security model you have ever used depends on one distinction: this part is instructions, and that part is data. SQL has a query and its parameters. HTML has markup and text content. A function has code and arguments.
Read the full lesson free →Curriculum
7 lessonsThe broken trust boundary
Explains why models mix instructions and data in one token stream, the confused deputy, and indirect injection.
The attack surface
Maps every source the model reads, asks who can write each one, and shows how injected text hides.
What an attacker wants
Covers exfiltration, unauthorized action, output manipulation and denial of wallet, and how connected tools set severity.
Defenses that do not work
Explains why instructions, input filters, model-based detectors and delimiters fail as main defenses, and what to keep.
Defenses that work
Presents least privilege on tools, authorization in code, human gates, egress control and isolation by trust level.
The second-order problem
Treats model output as untrusted input, covering markdown exfiltration, cross-site scripting and downstream systems like SQL.
A threat model you can act on
Turns the analysis into a six-step review, a checklist, injection tests and preparation for incidents.