OWASP's Top 10 for LLM Applications lists prompt injection as its top risk category (LLM01) for a reason: it is the one attack that requires no special access, no exploit chain, and no vulnerability in the traditional sense — just a sentence, phrased the right way, in a place the model happens to read. A team can run every conventional security scan available, patch every dependency, and still ship an application that a teenager with a web browser can manipulate in an afternoon, because the vulnerability is not in the code, it is in the fact that the model cannot structurally distinguish an instruction from data, the exact boundary problem the previous lesson named.
Prompt injection comes in two shapes that behave very differently in practice. Direct injection is typed straight into the chat by the user interacting with the system — the attacker is the user. Indirect injection rides inside content the model retrieves or is asked to process — a webpage, a document, an email, a code comment — and the person who eventually triggers the model reading that content may have no idea an attack is embedded in it at all. The distinction matters because the two shapes call for different defenses: direct injection can be addressed at the point of user input, while indirect injection requires scrutinizing every external content source the model touches, often sources the security team never thought to threat-model.
This lesson builds a working understanding of both shapes at the level needed to defend against them: what they look like, why they succeed against an undefended system, and which of the defenses from Lessons 2 and 6-11 close each one. Every example here targets a fictional system built for this course, never a real product, and every payload shown exists to be detected and blocked, not deployed.