Prompt Injection vs Jailbreaking: Different Attacks, Different Owners

Jailbreaking and prompt injection are used interchangeably, and they are not the same attack. They cross different boundaries, they have different attackers and victims, they are owned by different people, and they are fixed by different things. Conflating them is not a vocabulary quibble. It is how a team ends up buying a guardrail subscription when the actual fix was narrowing one tool’s permissions.

Here is the distinction in one line each:

• Jailbreaking targets the model’s policy boundary - getting the model to produce output its provider trained it to refuse.
• Prompt injection targets your application’s instruction boundary - getting the model to follow instructions that did not come from you.

Everything else follows from that.

The one-question test

When you are staring at an incident and cannot decide which you are looking at, ask:

Would this attack still make sense if there were no application around the model?

If someone could reproduce it by typing into a raw chat window with no system prompt, no retrieval and no tools, it is a jailbreak. The target is the model’s trained behaviour.

If it only works because there is something to subvert - a system prompt to override, a retrieved document to poison, a tool to misuse - it is prompt injection. The target is your architecture.

That question resolves most cases in a few seconds, and it resolves them in a way that points at the fix rather than just the label.

Why the distinction changes what you do

This is the part that matters operationally.

Read down the “who owns the fix” row, because it is the practical crux. Jailbreak resistance is something you largely buy. You pick a model, you evaluate its refusal behaviour, you add output filtering, and beyond that you are relying on the provider’s alignment work. There is not much architecture available to you.

Injection resistance is something you build, and nobody can sell it to you, because it exploits decisions you made: how your system prompt is structured, which sources can reach the context window, what your tools are permitted to do, whether retrieved content carries any trust label. A vendor cannot narrow your tool’s scope for you.

This asymmetry is why the misdiagnosis is expensive in one specific direction. A team reads an injection incident as a jailbreak, concludes the model was too easily fooled, and goes shopping for a stronger guardrail. The guardrail lowers the rate a bit and the underlying exposure - an agent holding a permission it did not need - is untouched. The next payload that gets through does exactly the same damage.

Severity works differently too

For jailbreaking, severity is roughly a function of what the model said and who saw it. A support bot induced to produce something offensive is a bad day, a screenshot, possibly a regulatory question. The ceiling is usually reputational, and it is bounded by the fact that output is just text.

For prompt injection, severity is a function of what the model can do next, which means it has no natural ceiling. With no tools, the impact resembles the jailbreak case: manipulated output. With tools, as covered in prompt injection in AI agents, the same successful attack becomes an action taken with your credentials and your user’s authority.

So the two need different severity rubrics. Scoring an injection finding on “how bad is the text” will systematically under-rate it, because the text was never the point.

Where they overlap, and why that is fine

The honest complication: they compose, and the composition is the common real-world shape.

An attacker plants a document that your retrieval pipeline will fetch. That delivery is injection - see indirect prompt injection for how that surface works. The instruction inside the document is phrased to defeat the model’s refusal behaviour so that it will actually comply. That phrasing is a jailbreak.

One incident, two layers, two different mitigations. The delivery is fixed by scanning the retrieval path and carrying provenance; the payload’s effectiveness is influenced by model choice and output filtering.

Which is why the right move is not to force one label onto an incident. Ask the two questions separately:

1. How did this instruction reach the model? That answers the injection question, and it points at your architecture.
2. What was it trying to make the model do, and why did that work? That answers the jailbreak question, and it points at the model and your filters.

You will often have findings on both, owned by different people, and that is a more useful outcome than a single argued-over label.

A note on the OWASP mapping

The OWASP LLM Top 10 lists prompt injection as LLM01 and treats jailbreaking as a technique within that entry rather than as a separate item. Our OWASP LLM Top 10 walkthrough covers the full list.

That grouping is reasonable for a checklist - both involve adversarial text, both belong near the top of any list - and it is also part of why teams conflate them in practice. A compliance checklist can tick them off in the same row. A threat model should not, because the attacker, the victim, the owner and the fix all differ. Use the standard for coverage and completeness; use the distinction above for deciding what to build and who to escalate to.

Testing them is not the same exercise either

Jailbreak testing looks like a content-policy suite: a corpus of prohibited request categories, run against the model, measuring refusal rates and how those degrade under rephrasing, role-play framing and encoding. The output is a rate, and it mostly informs model selection and output-filter tuning.

Injection testing looks like path and permission work. Which sources can reach the context window, which tools can be reached from there, and which pairs actually connect. The output is a map, and it informs architecture. That method is set out in the two companion guides, and it is deliberately not a payload library, because a payload library measures whether one string beat one model on one day.

Both belong in a serious programme - see our guide to AI red teaming for how they fit together. Just do not let a good jailbreak score convince anyone that the injection question has been answered. They are different questions, and the second one is the one that reaches your systems.

If you want both run properly against your own stack - the model’s policy boundary probed, and your application’s instruction boundary attacked through retrieval and tools - that is what our LLM red teaming engagement covers. Talk to us about what you have deployed.