Jailbreak and prompt injection are not the same problem

A security lead at a mid-market SaaS company told me their AI feature had passed a red-team pass. The tester had thrown a pile of jailbreak prompts at it, the kind meant to make a model say something it should not, and the feature held. Everyone felt good. A few weeks later a customer file with a hidden instruction walked the assistant into sending data it should never have touched. The red team had tested one threat and left another wide open.

The confusion is common and it costs teams. Jailbreak and injection sound like the same word. They are two different attacks with two different fixes, and defending against one does little for the other.

Two threats that look alike

A jailbreak targets the model’s own guardrails. The user tries to get the model to produce content it was trained to refuse, or to step outside the persona you gave it. The attacker and the target are the same conversation. The goal is to make the model misbehave for the person typing.

Prompt injection targets your application. Someone plants an instruction in content your AI will read, often content a different person supplied, and the model follows that instruction as if it came from you. The goal is usually to make the model act against the user or the company. The dangerous version is indirect, riding in through a document, a web page, or a synced record, so the person harmed and the person attacking are not the same.

Here is why the distinction matters. Hardening a model against rude or unsafe requests does very little to stop an instruction buried in a contract from redirecting a tool call. And building strong data boundaries does not stop a user from coaxing the model into an off-limits answer. You need to know which threat you are actually facing, because the defenses barely overlap.

Defend each one on its own terms

The teams that get this right stop treating “AI security” as a single checkbox and split it.

For jailbreaks, the questions are about content and behavior. What is the model allowed to say and do, and what happens when a user pushes it toward the edges. Provider-level safety helps here, and so does deciding early what an off-limits answer even is for your product.

For injection, the questions are about trust and capability. Where does untrusted text enter the prompt, and what can the model reach once it is there. The strongest defenses are structural. Separate data from instructions, limit what actions the model can take, and check outputs before they act. A jailbreak filter will not catch a poisoned document, because the document is not trying to make the model rude. It is trying to make it useful to the wrong person.

A short way to keep them straight:

Jailbreak is the user versus the model’s guardrails.
Injection is planted text versus your application’s boundaries.
A red team that only tries jailbreaks has tested half the surface.

Naming the two correctly is most of the work. Once a team sees that they are separate, they stop expecting one fix to cover both, and they start testing for each.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement, we map both threats separately. We look at what the model could be talked into saying, and we look at where outside content could plant an instruction and what that instruction could reach. Teams often walk in confident about one and blind to the other.

If your last security check only tried to make the model say something bad, you tested for jailbreaks. The injection is still waiting in the next file someone uploads.