Why the terms are confusing
This article assumes the basics from What Is Prompt Injection? and answers a narrower question: how the two terms relate, and how to name a concrete case without false certainty.
Neither term has one globally standardized definition. Vendors, researchers and guidance documents draw the boundary differently: some treat jailbreaking as a subset of prompt injection, others use the words almost interchangeably, and others keep them apart by what is being subverted. Blog posts and product pages add further variation.
Prompt-Injection.net therefore states explicit working definitions and uses them consistently. When a source uses a different meaning, we describe that meaning rather than silently merging it into ours.
Working definitions used on this site
| Term | Emphasis on this site | Typical initiator |
|---|---|---|
| Jailbreaking | Attempts to make a model violate or bypass the safety or usage-policy behavior set by the model provider or deployer | Commonly, but not necessarily, the interacting user |
| Prompt injection | Content that subverts the application's intended instructions or task control | Any source of model-visible content; especially important when mixed-trust content enters context |
How published sources differ
The OWASP LLM01:2026 Prompt Injection entry describes the two concepts as related, notes that they are often used interchangeably, and describes jailbreaking as a form of prompt injection aimed at making the model disregard its safety protocols. That is a documented framing from one guidance source, and it is compatible with the working definitions above when jailbreaking is read as a particular target of subversion.
NIST AI 100-2e2025 and the NIST glossary provide prompt-injection terminology, including the distinction between direct and indirect delivery. There is no single standard, cross-vendor definition that separates jailbreaking from prompt injection; the working definitions above are this site's.
Provider documentation may use its own terms for safety policy, misuse or instruction authority. Treat such terms as specific to that provider and product surface.
Classify along separate axes
"Jailbreak or prompt injection?" compresses several independent questions into one binary label. For security work, record each axis separately:
| Axis | Question | Possible values |
|---|---|---|
| Source or origin | Who authored the influencing content? | Interacting user, third party, unknown |
| Delivery | How did it reach model context? | Direct input, indirect via processed content (document, web page, email, tool output, retrieval) |
| Target of subversion | Which boundary was challenged? | Model or provider safety behavior, application task or instructions, both |
| Application capability | What could the surrounding system do? | Text only, private data access, tools or side effects |
| Resulting effect | What actually happened? | None, odd or off-task response, policy-violating output, unauthorized disclosure or action |
| Persistence | Does the influence recur? | Single turn, stored in memory or content, not applicable |
Two cases with the same label can differ on every other axis. Two cases with different labels can have the same security effect. The axes, not the label, drive triage.
Direct and indirect describe delivery
Direct versus indirect describes how content reaches the model: typed by the interacting user, or carried in content the application chose to process. It is a delivery axis. It is not a synonym for jailbreak versus prompt injection.
A jailbreak attempt is often direct, but safety-policy challenges can also arrive through processed content. Prompt injection can be direct, as in Direct Prompt Injection, or indirect, as in Indirect Prompt Injection. Avoid writing "jailbreak" when you mean "direct prompt injection", and the reverse.
Overlap cases
The following synthetic cases use neutral placeholders in square brackets instead of any instruction-like attack text.
A text-only chat assistant with no tools and no private data.
The user sends [a request designed to get content the provider's usage policy disallows].
Direct, user-originated; target is model safety behavior; commonly called a jailbreak attempt. No application capability beyond text.
A support assistant instructed to answer only questions about a fictional product.
The user sends [a request to ignore the product-only task and do something unrelated].
Direct, user-originated; target is application task control; prompt injection under this site's definition, even though no safety policy is involved.
An assistant summarizing a fictional supplier document for an employee.
The document contains [a sentence addressed to the assistant asking it to recommend a different supplier].
Indirect, third-party-originated; target is application task control; indirect prompt injection. In this scenario the document was supplied directly to the workflow rather than selected by a retrieval step, so it is a document-delivery example. If a retrieval pipeline selected the same content from a corpus or index, it could also be a RAG prompt-injection case.
An agent with a fictional ticketing tool.
One input contains [a request to disregard both the provider's content rules and the ticket-only task, and to call the tool for an unrelated purpose].
Target is both safety behavior and application instructions. The label is contested; the triage record is not: source, delivery path, both challenged boundaries, and whether authorization blocked the proposed tool call.
Security impact is a separate question
Classification does not determine severity. As the earlier Learn articles explain, model output is variable data or a proposal, and application controls decide consequential effects. A text-only policy bypass and an agent action affecting records or tools can have very different security consequences, whatever they are called.
| Observation | What it shows | What it does not show |
|---|---|---|
| Model produced policy-violating text in a text-only product | Model safety behavior was bypassed | Unauthorized data access or action |
| Model proposed a tool call; authorization blocked it | Model behavior was influenced | A consequential effect |
| Model proposed a tool call; it executed with excess permissions | An application control gap | That the label alone explains the severity |
Triage and reporting guidance
Minimum triage record
- Source and delivery path: who authored the content, and how it entered model context.
- Challenged boundary: provider safety behavior, application instructions, or both.
- Model behavior: whether the model changed behavior, and how that was observed.
- Application effect: whether controls allowed any data disclosure, action, destination or state change.
- Controls involved: which detection, authorization or validation step acted, and its result.
- Wording: use precise descriptive language where the label is disputed.
Preferred reporting language describes rather than labels, for example:
- "Direct user-originated instruction-control bypass with no consequential application effect."
- "Indirect third-party content influenced the model; deterministic authorization blocked the proposed action."
- "Direct user attempt to bypass provider safety behavior in a text-only product; policy-violating text returned; no data or tool access available."
If your organization requires a single category, add it alongside the description and name the definition you applied. Prompt Injection Detection signals can support the "model behavior" field but do not replace the effect analysis.
Common misconceptions
Statements that do not hold
- Every jailbreak is automatically a security incident.
- Prompt injection only happens through indirect content.
- Indirect prompt injection means RAG.
- A successful model-policy bypass grants application authorization.
- Because the terms are disputed, source, path and effect need not be documented.
Retrieval is one indirect path among many; see RAG Prompt Injection for that specific case.
Relationship to system prompts
Both jailbreak attempts and prompt injection often compete with system or developer instructions. Those instructions can influence precedence, as described in Instructions and Instruction Hierarchies, but they are neither secrets nor deterministic security boundaries. System Prompt Extraction covers why hidden instructions can be disclosed. The next Learn topic, System Prompts, covers what these instructions can and cannot do.
Practice
The Direct vs Indirect Prompt Injection lab trains the delivery axis with synthetic cases. The Direct Prompt Injection Basics lab separates model influence from the authorization decision. For the architecture behind both, revisit Trust Boundaries and Model Context.
Standards and sources
How this article uses sources
- OWASP
- LLM01:2026 Prompt Injection - one documented framing that relates jailbreaking to prompt injection
- NIST
- AI 100-2e2025 and glossary entries - prompt-injection terminology and direct versus indirect delivery
- Microsoft
- Indirect prompt-injection guidance - third-party content as a delivery path and layered mitigations
Frequently asked questions
Is every jailbreak prompt injection?
Is every prompt injection a jailbreak?
Is indirect prompt injection always more severe?
Which term should an incident report use?
Can a model be jailbroken without any application vulnerability?
Can prompt injection matter if provider safety policy is never bypassed?
Does direct mean jailbreak and indirect mean prompt injection?
References
- LLM01:2026 Prompt InjectionOWASP GenAI Security Project · GuidanceReviewed 2026-09-26
- OWASP GenAI LLM Top 10 2026OWASP GenAI Security Project · GuidanceReviewed 2026-09-26
- Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2e2025NIST · Standard · 2025-03Reviewed 2026-09-26
- prompt injectionNIST Glossary · Technical documentationReviewed 2026-09-26
- indirect prompt injectionNIST Glossary · Technical documentationReviewed 2026-09-26
- Defend against indirect prompt injection attacksMicrosoft Learn · GuidanceReviewed 2026-09-26