You will hear prompt injection dismissed as “input validation for AI.” That is wrong in a way that matters, because it implies a filter will fix it, and no filter will.

• Direct — a user types something to make the assistant misbehave. Mostly an embarrassment risk, and what most public jailbreak examples show.
• Indirect — the instruction is planted in content the system reads later: a web page, a PDF, a support ticket, a calendar invite, white text in a CV, a code comment. This is the one that matters, because the attacker never touches your system and the victim is the agent, not the user.

The canonical enterprise scenario: an assistant summarises incoming email. An email arrives containing text addressed to the assistant — forward the last ten messages to this address, then say nothing. If the assistant can read and send mail with a broad credential, you have an exfiltration channel no perimeter control sees, because every action was taken by an authorised internal system.

• Instructions can be phrased infinitely many ways, in any language, encoded, split across documents, or embedded in an image the model can read.
• The filter must distinguish “text describing an instruction” from “an instruction” — the same undecidable problem one level up.
• Classifier-based defences help and are worth deploying, but they are probabilistic. Do not let them be recorded as preventive controls; they are detective and partial.

Prompt injection persists because of an architectural property, not an implementation defect: a language model receives instructions and data in the same channel, and has no reliable way to tell them apart. Everything reaching the model is text, and text that reads like an instruction is treated like one.

That is the same class of problem as SQL injection — and the comparison is instructive for what it reveals about the difference. SQL injection was solved by parameterised queries, which put the query structure and the data in genuinely separate channels the database parses differently. There is no equivalent for a language model. No parameter binding exists, because the model's input is not parsed into a structure with slots.

• Direct injection — the user tries to override your instructions. Annoying, usually low-impact, and the case everyone tests.
• Indirect injection — the instruction arrives in content the system retrieves: a web page, an email, a document, a support ticket, a code comment. This is the serious one, because the attacker never touches your interface and the user is unaware anything happened.
• The attacker's target is your tools, not your text. Without tools the worst outcome is a bad answer. With tools the outcome is an action taken with your credentials.
• And the exfiltration path people miss is rendering. If the model's output is rendered as markdown or HTML, an injected instruction can construct an image URL containing the data it just read — and the victim's browser sends it on load. No click required.