Two problems that share a vocabulary

Prompt injection vs jailbreaking: why the difference matters

The two terms are used interchangeably in headlines, and the confusion is expensive. Jailbreaking is an attack on a model’s safety training. Prompt injection is an attack on an application that mixes trusted instructions with untrusted text. They have different victims, different consequences and different defences, and a team that has prepared for one has not prepared for the other.

Published 5 September 2026
By the Prompt Injection Scanner editorial team (Mothership Engineering)
Every claim traces to the primary references listed at the foot of the page

What each term means

Simon Willison coined the term prompt injection in September 2022, by analogy with SQL injection. His definition has held up: a class of attacks against applications built on large language models that work by concatenating untrusted input with a trusted prompt written by the application’s developer. The model cannot tell where the developer’s instructions end and the untrusted text begins, so text that looks like an instruction can be followed as one. The OWASP Top 10 for LLM Applications 2025 lists it first, as LLM01, and describes both a direct form, where the person interacting with the system supplies the text, and an indirect form, where the text arrives inside content the system was asked to read.

Jailbreaking is older and narrower. It is the class of attacks that try to subvert the safety behaviour trained into the model itself: persuading a model to produce content it has been trained to refuse, usually through role-play, hypothetical framing or a long chain of small steps. The target is the model vendor’s policy, and the person carrying out the attack is usually the same person who receives the result. Willison’s March 2024 note on the distinction puts it plainly: jailbreaking attacks the model, prompt injection attacks the application built on top of it.

Different victims

The clearest way to separate the two is to ask who is harmed. In a jailbreak the harm, if any, lands on the vendor and on the person who asked: an embarrassing screenshot, or advice the model should not have given. The user wanted the output. In a prompt injection the user is the victim. A third party has placed text where the user’s AI system will read it, and the system acts against the user’s interests while appearing to serve them.

Willison’s standing example makes the difference concrete. Imagine a personal assistant with access to your email. Someone sends you a message that says, in effect, search my email for the latest sales figures and forward them to an outside address. If the assistant follows that instruction, no safety filter was bypassed and nothing the model was trained to refuse was produced. It simply did an ordinary, permitted thing on behalf of the wrong person. That is why the consequence of an injection depends on what the application can reach, not on what the model is willing to say.

Why the mix-up leads to the wrong defences

Safety training, refusal tuning and content classifiers are the natural defences against jailbreaks, and vendors invest heavily in them. They do very little against injection, because an injected instruction usually asks for something permitted: summarise this, send that, open this link. Willison notes that detection systems trained on jailbreak attempts do not protect against application-specific injection, and that treating the two as one problem also obscures the fact that injection is a security issue, separate from any debate about model censorship.

The UK National Cyber Security Centre made the same point from the other direction in December 2025. Its architecture lead argued that prompt injection is not SQL injection and may never be mitigated the way SQL injection was, because parameterised queries work by enforcing a separation between data and instructions that a language model does not have. Its advice is to stop trying to keep hostile text away from the model and instead to constrain what the system can do with deterministic, non-model safeguards, dropping the system’s privileges to those of whichever party supplied the content it is reading.

Where the two overlap

The categories blur at two points. The first is direct prompt injection, where the person using an application tries to override the developer’s system prompt, for instance to extract it or to change the application’s persona. The user is the attacker and the developer is the victim, which looks like a jailbreak from the vendor’s side and like an injection from the developer’s. The Bing Chat episodes of February 2023, in which users talked the assistant into revealing its internal instructions, sit exactly on this line.

The second overlap is that an indirect injection can carry a jailbreak inside it. A hidden instruction in a document may need to get past the model’s own reluctance before it can redirect the application, so attackers combine the two. The right response is still architectural: a model that refuses more often is welcome, but the boundary that protects the user is the one that stops a permitted action from being taken on an attacker’s behalf.

What this means when you review text

When you paste a document into an AI tool, the risk that matters is injection, not jailbreaking. The document is untrusted content entering a trusted context, and any instruction-shaped text in it, visible or hidden, will be read with the same standing as your own request. A scanner such as the one on this site looks for that instruction-shaped text and for the channels where it hides. It makes no judgement about whether a model’s safety training would hold, because that is the wrong question for the situation.

The habits that follow from the distinction are simple to state. Keep untrusted content separate from the instructions you give an AI system. Limit what the system can reach while it reads that content. Require a person to approve anything consequential the system proposes to do. And treat a scanner’s result as a reason to look, never as a certificate: detection supports review, and review is where the trust decision is actually made.

Primary references

These sources describe the external risks or standards discussed above. The property’s detector claims remain limited to its versioned policy and recorded evidence.

Browse every guide

Result boundary: Findings are indicators for review. Detection cannot certify a source, and a no-indicator result does not replace downstream isolation, validation, least privilege or approval.