Prompt Injection vs Jailbreak: Same Text, Different Owner

The text will not tell you which one you have.

A ticket arrives with a classifier label reading “jailbreak,” attached to an agent that read a document and then queried a table it had never touched. The label is defensible: the retrieved text opened with role-play framing and an override instruction, which is exactly what jailbreak detectors are trained on. It is also the wrong classification for the incident, because the thing that happened afterwards was a data access with a valid service account, and no amount of safety training on the model would have changed it.

The definitions have been settled since 2024. What has not been settled, on most incident desks, is a procedure for applying them when the payload wears one costume and does the other’s work. Two tests decide it. The answer decides who owns the fix.

The Text Will Not Tell You Which One You Have

In the wild, injections borrow jailbreak clothing as a matter of routine.

The empirical study of injections found on live web pages, Indirect Prompt Injection in the Wild, reports that most in-the-wild prompts rely on task override, often reinforced by jailbreak framing or output constraints. The persona assignment, the “you are now unrestricted” preamble, the hypothetical scenario: all of it appears as packaging around instructions whose target is the application rather than the model’s refusals. Attackers reuse templates that work, and jailbreak templates are the most widely published templates there are.

The detection tooling reflects the overlap rather than resolving it. Evaluations of guardrail evasion run the same character-injection and adversarial techniques against both a prompt injection dataset and a jailbreak dataset and report attack success against each, because the guardrails under test are deployed in front of the model to catch both. A classifier trained that way returns one label for one class of text, and the three numbers worth measuring on such a model describe how well it learned the text, and say nothing about which of two events it is looking at.

The standards body did not resolve it either. OWASP’s LLM01 entry states that jailbreaking is a form of prompt injection in which the attacker causes the model to disregard its safety protocols entirely. That grouping is reasonable for a chatbot, where both arrive through the same channel and the earliest examples of both were typed into the same box.

Simon Willison, who named prompt injection, drew the line in a 2024 post: prompt injection is a class of attacks against applications built on LLMs that works by concatenating untrusted input with a trusted prompt; jailbreaking is a class of attacks that subvert the safety filters built into the models themselves. If there is no concatenation of trusted and untrusted strings, it is not prompt injection. That definition is exact, and it is also invisible at the text level, because the concatenation happened inside your application and the classifier only saw the result.

Run Two Tests: Remove the Safety Training, Then Find the Consequence

The first test is a thought experiment. Take the model out of the picture and put in its place one with no safety training at all, a model that will say anything asked of it. Ask whether the attack still needs to exist.

For a jailbreak, it does not. A model with no refusal behaviour produces the bomb recipe, the slur, the competitor’s pricing in a screenshot, without any persona scaffolding or hypothetical framing. The entire technique existed to defeat something the substitute model does not have. The safety training was the target.

For an injection, the attack is unchanged. The unaligned model still has to be given the instruction inside content the application trusts, because it is the application that decides which text gets to act as an instruction. The attacker still needs the retrieved document, the tool result, the email, the pull request. Strip the safety training and the injection is exactly as hard and exactly as necessary as before. The application’s trust boundary was the target.

Apply the test to the ticket. The role-play preamble would be unnecessary against an unaligned model; that part was jailbreak. The instruction to look up eligibility against a customer table would still need to arrive inside a trusted document; that part was injection. The payload was both, and the first test has already separated it.

The second test looks at the consequence. Ask where the harm is: in the text the model produced, or in something the system did with that text.

A jailbreak’s harm is the text. The output is offensive, prohibited, embarrassing, or reveals the system prompt, and the damage is bounded by the audience that reads it. Willison describes the typical risk as screenshot attacks. An injection’s harm is an action: a record read, a message sent, a connection opened, a file written, a configuration changed. The damage is bounded by what the agent was permitted to do, and it completed through permissions that were valid. The UK’s NCSC calls this a confused deputy rather than a sanitisation failure: the model exercised authority on behalf of whoever wrote the text in front of it.

Put the two tests together and every event lands in one of three cells. The attack disappears against an unaligned model and the harm is text: jailbreak. The attack survives and the harm is an action: injection. The attack survives, the harm is an action, and the text also carried jailbreak framing: both, and the framing is a distraction from the incident.

Jailbreak Is the Model Vendor’s Fix, and Injection Is Yours

The reason to run the tests is that the answer assigns ownership, and ownership assigns everything else.

OWASP’s own text makes the split explicit in one sentence: developers can build safeguards into system prompts and input handling to mitigate prompt injection, but effective prevention of jailbreaking requires ongoing updates to the model’s training and safety mechanisms. Training is the vendor’s. Input handling, trust boundaries, tool scope and enforcement are yours.

	Jailbreak	Prompt injection
Target	Model’s safety training	Application’s trust boundary
Owner of the fix	Model vendor	Application owner
Layer that can act	Guardrails and vendor safety training	Architecture, permissions, runtime enforcement
Exposure	Content and reputation; bounded by audience	Data and actions; bounded by the agent’s permissions
Runbook	Log, report to vendor, tune guardrail, review output policy	Scope the agent, check what it reached, enforce on deviation, review data moved
Obligations	None on the data owner	Depend on the data that moved and the jurisdiction
Telemetry that decides it	Prompt and output text	Tool calls, credentials exercised, destinations reached
Weakness ID	None; model property	CWE-1427 as entry, resultant CWE for the consequence

The last row is the formal version of the split. The CWE for prompt injection has an entry, and its own mapping notes say jailbreaking may have a different root cause; no entry exists for it, because a model’s refusal behaviour is a model property rather than a weakness in the product built on it. A finding you cannot file is a finding you do not own.

There is one case where a jailbreak is squarely the application owner’s problem, and it deserves stating. When the model’s output is the product, as it is for a public-facing assistant whose replies carry the brand, prohibited text is a reputational incident for the operator and the vendor’s fix does not arrive on the operator’s timeline. That is real, and it is a content-policy problem with a guardrail answer. It does not touch data, it does not exercise credentials, and it does not need a scope review. The exposure column still holds.

Ownership also explains a pattern in vendor-hosted agents. Shopify published six agentic security principles for Sidekick, and the one that moves during a coercion attack is the one merchants cannot inspect. When the model vendor and the application operator are the same company, the jailbreak and injection fixes sit with the same party and the customer holds neither. When they are different companies, the injection fix is the one you can actually make.

The Same Payload Can Be Both, and It Separates Along the Wrapper

A jailbreak-framed injection is one payload with two owners, and it splits cleanly.

Every payload decomposes into a wrapper and an ask. The wrapper is the framing and evasion that gets the ask into context and past a screen; the ask is the action requested. Jailbreak vocabulary lives in the wrapper. The persona, the hypothetical, the override imperative are all devices for getting a model to comply with something it would otherwise decline, and against an agent that has no reason to decline an authorised action they are surplus. The ask is the injection, and it is the only part the agent acts on.

That is why the technique sort that separates evasion tiers places jailbreak lineage in its own tier: those techniques defeat the refusal boundary, and an agent attack has no refusal to argue with. The tier that reaches production data is a plain sentence with no jailbreak in it at all.

Here is the useful consequence. The part of the payload you own is the enumerable part. Wrappers, including jailbreak wrappers, are an open set that the vendor and the guardrail layer chase. Asks against a specific agent are a closed set defined by its tools, credentials and network reach, and you can write that set down today.

So when a payload carries both, respond to it twice. Send the wrapper to the guardrail layer and the vendor, where the jailbreak fix lives. Send the ask to the ledger, where the injection fix lives. Treating the whole thing as a jailbreak because the wrapper was loud is how an agent’s data access gets closed as a content-policy ticket.

Route Each to the Layer That Can Act on It

Three layers secure an AI system, and each of the two attacks has a home in one of them.

Posture asks what the AI is connected to and whether it is configured safely. Guardrails sit at the door and judge what goes into the conversation and what comes out. Runtime watches what the agent actually does in execution: the files it opens, the code it runs, the connections it makes, the identities it presents.

A jailbreak is a guardrail-layer event. The evidence is in the text, the four categories of prompt-layer signal are the instruments, and the durable fix is on the vendor’s side. Log the input and the output, report the technique to the vendor, tune the output policy, and close the ticket as content safety. If the same session also produced an action, the action is a separate event and gets the second route.

An injection is a runtime-layer event, because its evidence is what the agent did. A tool call with no precedent, a credential exercised against a resource the agent has never touched, a connection to a destination outside its history. Those signals are only legible against the agent’s own baseline, which is why ARMO records each workload’s behaviour from a kernel-level sensor and builds a per-agent profile, Application Profile DNA (APD™), then evaluates deviation against it. Coercion, where every step was authorised and only the sequence was new, is the injection signature at this layer, and the response follows the Audit and Enforce sequence: observe the deviation, review what a policy would have blocked, arm it per agent. The rollout that keeps enforcement from breaking production is the same one that turns a detected injection into a bounded one.

The scoping is worth stating plainly. ARMO is not a jailbreak classifier. It captures prompts and tool calls as telemetry and correlates them with what happened next, but the finding it raises is behavioral: did this agent stop behaving like itself. It has nothing to say about whether the model should have refused, which is a guardrail-layer and vendor question. The behavioral question is silent on jailbreaks by design, and it is the only question a plain-language injection ever leaves evidence for.

Once the incident is classified, the injection side has two follow-ups the jailbreak side never needs. Which of the agent’s consequences are unreachable, which are detected and which are exposed is the scope review. One delivered test per exposed consequence is the verification. Neither has a jailbreak analogue, because a jailbreak’s consequence set is the output channel and nothing else.

ARMO’s runtime security for AI workloads covers the runtime row of the table. Bring one incident ticket with a “jailbreak” label to a working session and the two tests get run against the agent’s actual runtime record.

Call It by Whose Problem It Is

A label is a routing decision.

Write “jailbreak” on a ticket and it goes to whoever tunes the guardrail and talks to the vendor. Write “prompt injection” and it goes to whoever owns the agent’s permissions and its enforcement policy, and it triggers a scope review and a look at what data moved. The same text can deserve both labels, and when it does the ask is the part with the incident attached.

The question to write on the ticket is the second test: what did the system do with the text. If the answer is nothing, it was a jailbreak and it belongs to the vendor. If the answer is anything else, it is yours.

FAQ

Is jailbreaking a type of prompt injection? OWASP’s LLM01 entry says yes, describing jailbreaking as a form of prompt injection where the model disregards its safety protocols. Operationally the two separate by target and owner: a jailbreak defeats the model’s safety training and is fixed by the vendor’s training updates, while an injection defeats the application’s trust boundary and is fixed by the application owner’s architecture, permissions and enforcement.

Is a jailbreak a security incident? Usually a content-safety event rather than a security incident: the harm is text the model should have refused, the exposure is reputational, and no data was accessed or moved. It becomes a security incident the moment an action follows the text, at which point the action is an injection consequence and gets the injection runbook, whatever the classifier called the input.

Can a jailbreak turn into a prompt injection? The same payload can carry both, and in the wild it often does: jailbreak framing wrapped around an instruction aimed at the application. The wrapper and the ask separate cleanly, and against an agent with tool access the wrapper is surplus, because the agent has no refusal to defeat before it fulfils an authorised request.

Which is more dangerous for AI agents, prompt injection or jailbreaking? Prompt injection, because its damage is bounded by the agent’s permissions rather than by an audience. A jailbroken agent produces text it should not; an injected agent reads, writes, sends and connects with a valid identity. The documented agent incidents with data loss on the public record are injections, and most of the jailbreak techniques in a standard catalog do no work against an agent at all.

Who is responsible for fixing prompt injection vs jailbreaking? The model vendor owns jailbreaks, through safety training and the guardrails it ships. The application owner owns prompt injection, through trust boundaries, tool scope, credential isolation and runtime enforcement. The CWE record encodes the same split by having an entry for injection and none for jailbreaking, since a model’s refusal behaviour is not a weakness in the product built on it.