Also published on Medium on 2026-10-27.
In conversations about LLM security, “jailbreak” and “prompt injection” get used almost interchangeably. Both involve tricking a model with clever text, so it’s easy to see why. But they’re different problems, with different attackers, different victims and, most importantly, different owners.
If you build applications on top of language models, getting this distinction right tells you which risks are yours to manage.
Jailbreaks: getting the model to break its own rules
A jailbreak is an attempt to get a model to produce something its developer or provider doesn’t want it to produce: harmful instructions, prohibited content, or behaviour outside its safety guidelines.
The key features:
- The attacker is usually the person talking to the model.
- The target is the model’s own policies.
- The harm is mostly in the content generated.
Jailbreaks matter, and model providers invest heavily in resisting them. For most application builders, though, jailbreak resistance is largely inherited from the model and the provider’s safety systems, supplemented by your own content policies.
Prompt injection: hijacking the model to act against someone
Prompt injection is an attempt to make a model follow instructions that didn’t come from the application or the legitimate user. Those instructions can arrive directly in a message, or indirectly through documents, web pages, emails, retrieved chunks or tool outputs the model reads.
The key features:
- The attacker may not be in the conversation at all. They can plant instructions somewhere the app will read later.
- The target is your application and your user.
- The harm is in what the model does: leaking data, calling tools, changing records, misleading the user.
Why the difference matters
Here’s the part that surprises people. A model can be extremely resistant to jailbreaks and still be completely vulnerable to prompt injection.
Imagine an assistant that would never write malware or produce harmful content, no matter how cleverly you asked. Now give it access to a user’s inbox and the ability to send email. Then have it summarise an email that contains instructions to forward certain messages elsewhere.
From the model’s perspective, forwarding an email isn’t harmful content. It’s a normal action the assistant is allowed to take. Nothing in its safety training necessarily flags it. The model isn’t being asked to break its rules. It’s being asked to do its job, for the wrong person.
That’s why prompt injection is fundamentally an application security problem. The provider built the model. You connected it to data, tools and users. The risk comes from those connections, so managing it is your responsibility.
Who owns what
A rough way to split responsibilities:
Mostly the model provider’s problem:
- Refusing clearly harmful requests
- Baseline safety behaviour
- Resistance to generic jailbreak techniques
Mostly your problem:
- What data the model can see
- What tools it can call, and with what permissions
- Whether untrusted content is inspected before it reaches the model
- Whether outputs are validated before they’re acted on
- Whether actions are logged and reviewable
Content filters, the tools most teams add first, mostly address the first list. They do much less for the second.
What to do about it
If you’re building with LLMs, especially agents, put prompt injection explicitly in your threat model:
- Map every input the model reads, not just the user’s message.
- Inspect untrusted content before it reaches the model, including retrieved documents and tool results. At Koreshield, our gateway inspects the full request, not just the latest user turn, for exactly this reason.
- Apply least privilege to tools. Every tool should do the minimum necessary, with the narrowest credentials possible.
- Require confirmation for consequential actions, such as sending messages, moving money or deleting data.
- Validate outputs before rendering or executing them.
- Log everything so you can reconstruct what happened.
The short version
Jailbreaks are about what a model is willing to say. Prompt injection is about whose instructions a model ends up following.
The first is mostly a model problem. The second is mostly an application problem. If you’ve wired a model to your data and tools, the second one is yours.