Willison and OWASP disagree about where jailbreaking belongs. Willison, who coined the term, treats prompt injection and jailbreaking as separate attacks. His test is simple: if trusted and untrusted strings were never concatenated, it is not injection. Prompt injection needs that concatenation step instead: untrusted input glued into a developer’s trusted prompt. In contrast, jailbreaking needs none; a user just pushes against the model’s own safety filters. OWASP, though, draws the line differently. It nests jailbreaking under direct prompt injection instead, one of two sub-classes alongside indirect injection. So the same clever chatbot prompt earns two different names, depending on which taxonomy you follow.
Two security terms often get treated as one, though the habit costs teams real defences. Prompt injection and jailbreaking sound alike, but they attack different layers of an LLM system. This guide leans on two named authorities. Simon Willison coined the term prompt injection. OWASP’s LLM01 entry sets the taxonomy most security teams now follow.
Willison published this distinction on 5 March 2024, in a post titled Prompt injection and jailbreaking are not the same thing. This piece works through his definitions, then OWASP’s, then the point where the two disagree. That disagreement, not the definitions alone, is the part worth remembering.
Two Attacks That Keep Getting Merged
Most write-ups treat prompt injection and jailbreaking as one attack. That habit blurs a real boundary. Teams then build the wrong defence for the threat they actually face. A jailbreak is a conversation problem. Prompt injection, by contrast, is an architecture problem.
Two named authorities still disagree about where the exact boundary sits, a disagreement this guide covers in full. Both still agree on one point: the two attacks are not the same thing. So mixing them up leads to the wrong defence, every time.
What Prompt Injection Actually Is
Willison defines prompt injection as “a class of attacks against applications built on top of Large Language Models (LLMs)”. Such attacks “work by concatenating untrusted user input with a trusted prompt constructed by the application’s developer.” Concatenation is the operative word here, rather than persuasion.
Willison explains the name directly: “That’s why I called it prompt injection in the first place”. The pattern, in his words, is “analogous to SQL injection”. SQL injection concatenates untrusted input with trusted code. That same shape is covered in our SSL vs TLS guide.
The stakes differ sharply, per Willison. Jailbreaking risks embarrassment, or worse, helping someone commit a crime. Prompt injection, by contrast, threatens applications that hold confidential data and tools. He proposes a Dual LLM pattern as one defence, but he does not call the problem solved. Prompt injection still stays an open problem, by his own account.
What Jailbreaking Actually Is
Willison defines jailbreaking as “the class of attacks that attempt to subvert safety filters built into the LLMs themselves”. In fact, those filters live inside the model itself. Our BERT vs GPT guide introduces that same model from the ground up. No concatenation step is required here, only persistence against a filter.
A user can jailbreak a model with nothing more than a clever chat message. Also, no untrusted document, no external tool, no second party is needed. So that single-turn simplicity is exactly why Willison keeps jailbreaking in its own category, separate from injection.
Prompt Injection vs Jailbreaking: Comparison Table
The table below lines up prompt injection against jailbreaking, field by field. Every value traces back to Willison or OWASP, not to outside claims.
| Aspect | Prompt Injection | Jailbreaking |
|---|---|---|
| What is attacked | The application layer around the model | The model’s own safety filters |
| Where the vulnerability lives | In how untrusted input meets a trusted prompt | Inside the model’s alignment training |
| Concatenation required | Yes, the defining trait | No concatenation needed |
| Who supplies the malicious text | Untrusted data: a user, a file, a web page | The user, directly, in the chat turn |
| Needs the victim’s session | Not always; indirect injection needs no session access | Yes, the attacker interacts with the model directly |
| Classic analogy | SQL injection: untrusted input concatenated with trusted code | No stated analogy; the goal is subverting a filter |
| Where defences live | In application architecture | Inside the model itself |
| Who owns the fix | The application developer | The model provider’s safety team |
| Typical worst case | Data exfiltration or unwanted tool actions | Embarrassing or policy-violating output |
| What is at risk | Confidential data and any tools the app can call | The model’s safe-use guarantees |
| Relation to safety training | Better training does not fix it | Safety training is the direct defence |
| Relation to tool access | Risk scales with the tools and credentials granted | Not inherently tied to tool access |
| Direct vs indirect split | Splits into direct and indirect sub-classes | OWASP nests it under the direct sub-class only |
| Result under the concatenation test | Passes: trusted and untrusted strings were concatenated | Fails: no concatenation occurred |
| How the two authorities classify it | Both call it prompt injection | Willison excludes it; OWASP nests it under direct injection |
One row is worth a second look: whether concatenation is required at all. That single fact decides which category an attack falls into, no matter how the attack feels from the outside.
The Concatenation Test
Willison states the discriminator plainly: “Crucially: if there’s no concatenation of trusted and untrusted strings, it’s not prompt injection.” One question decides everything: were a trusted prompt and untrusted input ever glued together?
Apply it to any attack you are analysing. If nothing untrusted was concatenated into a developer’s prompt, the attack is not injection, whatever else it might be. That single test cuts through most of the confusion, since it settles the question directly.
Direct and Indirect Injection
OWASP splits prompt injection into two sub-classes, direct and indirect. That split became explicit in its 2025 edition. Direct injection covers an attacker typing adversarial instructions straight into the user-facing input. OWASP has linked jailbreaking to that direct category, which is the crux of the disagreement covered next.
Indirect injection works differently, since the attacker never touches the victim’s session at all. OWASP puts it plainly. “Indirect Prompt Injection occurs when malicious instructions are hidden in external content that an LLM or agent later ingests.” That line comes straight from OWASP’s LLM01 entry.
The payload can sit inside a web page, a document, or a file the model reads later. Our MCP vs A2A guide covers exactly this kind of case, where agents pull in outside content. So nothing about the victim’s own chat session needs to be compromised at all. The content just has to be something the model will eventually read.
Where the Definitions Disagree
The two most-cited authorities do not agree on where jailbreaking belongs, though neither one is simply wrong. Willison treats prompt injection and jailbreaking as separate classes, then gives a test that excludes jailbreaking entirely. OWASP instead organises jailbreaking under the direct prompt-injection heading. It treats jailbreaking as one sub-case, not a separate class.
Consider a user who types, straight into a chatbot, something like ignore your rules. Under Willison’s definition, that is jailbreaking, not injection, because nothing untrusted was concatenated into a developer’s prompt. Under OWASP’s definition, the very same message counts as direct prompt injection.
Neither authority is careless here; they are simply drawing the boundary in different places. Willison’s boundary is mechanical: concatenation happened, or it did not. OWASP’s boundary is categorical: jailbreaking sits inside direct injection, one sub-class among several. Most competing articles pick one framing and present it as settled, which this guide deliberately avoids.
Why the Defences Are Not Interchangeable
Jailbreaking targets the model’s own safety training. So the defence has to live there too. Alignment training, refusal behaviour, and output filtering all sit inside the model. That is the same territory our RLHF vs DPO guide covers directly. Better safety training can reduce jailbreaks. It does nothing for prompt injection, because injection is not a model-training problem at all.
Prompt injection targets the application built around the model, so its defences live in architecture, not alignment. Separating trusted instructions from untrusted data is the first line of defence. Limiting what tools the model may call is the second, covered in depth in our MCP vs Function Calling guide. Never trusting model output that untrusted input could have influenced is the third.
A jailbroken model embarrasses you, and the damage mostly stops there. An injected application can exfiltrate data or take unwanted actions, because it holds real tools and real credentials. So that gap in consequences is the entire reason the two defences cannot swap places.
Which One You Are Actually Facing
Ask one question first: did untrusted input ever get concatenated into a trusted prompt? If yes, you are looking at prompt injection, direct or indirect depending on where that untrusted text came from. If no, and someone is simply pushing the model’s own filters in conversation, you are looking at jailbreaking.
The same question also tells you who owns the fix. A jailbreak, then, points back at the model provider’s safety training. An injection points back at your own application’s architecture, since nobody else controls how your app concatenates its prompts. Answer that one question honestly, and the rest of the response follows.
Interview Questions
Frequently Asked Questions
Wrapping Up
One test settles most of the confusion: did untrusted input get concatenated into a trusted prompt? If it did, you are dealing with prompt injection, and the fix belongs in your application’s architecture. If it did not, you are dealing with jailbreaking, and the fix belongs inside the model’s own safety training.
Willison and OWASP still disagree about where jailbreaking sits in the wider taxonomy. That disagreement is worth remembering, rather than smoothing over. Treat the two attacks as what they are: related, but not the same, with defences that do not swap places.
Related reading on DiffStudy:
