Where each attack enters
The simplest way to tell them apart is the entry point. A prompt injection arrives through untrusted input your app processes — a user message, a retrieved document, an API payload. It hijacks the running app's context to make it do something unintended.
A jailbreak is a crafted prompt aimed at the model's safety behavior — "you are now DAN," "ignore your content policy," role-play a restricted character. The goal is to make the model produce output it was tuned to refuse. The jailbreak often comes from the user directly, but its target is the model, not your app's logic.
Injection vs jailbreak, side by side
| Prompt injection | Jailbreak | |
|---|---|---|
| Target | Your app's instructions/context | The model's safety behavior |
| Entry | Untrusted input the app processes | A crafted prompt to the model |
| Goal | Make the app act against intent | Make the model bypass its policy |
| Common in | Any app with user/retrieved input + tools | Chat/completion interfaces |
| Defense focus | Input validation, context separation, tool guards | Model-level safety, output filtering |
They overlap — a jailbreak prompt delivered through your app's input is also an injection — but the framing changes where you defend.
Why both matter for your app
If your app exposes a chat surface, jailbreak attempts will land in your input stream. If your app acts on that input (tools, retrieval, external calls), an injection can turn a jailbreak into an action. For a customer-facing LLM, you are defending both doors at once.
Ignoring one invites the other. A team that hardens only the model's safety but passes raw user text to tools is still injectable; a team that gates tools but never filters jailbreak prompts may still leak unsafe output. Defense has to cover the app and the model boundary.
How PromptShield treats both
PromptShield scans your app's real sample input for injection patterns — override, exfiltration, tool abuse, delimiter confusion, indirect injection. It also flags jailbreak signals (role-play escapes, policy-bypass framing) that appear in that input, because in a deployed app the jailbreak arrives as input too.
The report separates the two so you can route the fix: injection findings drive app-level hardening (input validation, tool guards); jailbreak signals inform model/output handling. Both feed the same hardening checklist.
What neither a scanner nor a jailbreak test can guarantee
No scanner, and no jailbreak test, makes an app safe. PromptShield flags known patterns; novel jailbreaks and obfuscated injections still slip through. Treat the report as one control — pair it with model-level safety settings, output filtering, and a real security review.
PromptShield is a decision-support scanner, not a guarantee. A clean scan means "no known patterns matched this sample," not "unhackable."
Authoritative references
- OWASP Top 10 for Large Language Model Applications (2025): https://owasp.org/www-project-top-10-for-large-language-model-applications/
- Prompt Injection paper (arXiv 2306.05499): https://arxiv.org/abs/2306.05499
- OWASP (general application security): https://owasp.org/