What Is an LLM Jailbreak?
A jailbreak is input written to make a deployed system produce output its operator's rules would otherwise withhold. It targets the behaviour that declines rather than the software that serves: nothing is exploited in the ordinary sense, no boundary is crossed at the protocol level, and the request that succeeds arrives on the same endpoint, in the same format, as the one that is refused.
What a jailbreak is aimed at, and how that differs from injection
Two things are worth separating immediately, because they are constantly merged. The refusal behaviour a jailbreak attacks lives in two places: in the training that gave a system a disposition to decline certain requests, and in the instructions an operator supplied at the head of the context. Neither is a gate. Both are dispositions expressed in the same medium as the request itself, which is exactly why they can be argued with. A filter placed in front of or behind the generating step is a third thing entirely — a separate classifier, succeeding or failing on its own terms and for its own reasons.
The distinction from prompt injection is about who is writing and what they want. A jailbreak is generally written by the person talking to the system, and its objective is output the operator's policy forbids. An injection is written by a third party, planted in material the system will later read, and its objective is an action or an answer the operator never asked for — an injection can succeed with no policy in play at all. The two overlap in the obvious way: injected text can carry a jailbreak, and then a third party is arguing with the policy on somebody else's session.
The reason this is structural rather than a defect awaiting a patch is that a declining disposition has to generalise. It was learned from examples and it covers a space of phrasings; an adversary is free to move around inside that space, and the space is as large as the language. No parser stands between a permitted request and a forbidden one, because permission is not a property of a request's form. The same mechanism that follows a helpful instruction follows this one, and it reads both as text.
| Shape | What it relies on |
|---|---|
| Persona assignment | Answering as a character defined as having no restrictions, so that a refusal is attributed to a role rather than to the deployment. |
| Fictional framing | Placing the request inside a story, script or hypothetical, where the output is presented as depiction rather than as instruction. |
| Gradual escalation | Establishing an innocuous subject across several turns and narrowing it, so that no single turn is the one that asks. |
| Surface obfuscation | Changing the form of the request — another language, an encoding, split fragments — so that what a filter matches on is not what is being asked. |
| Role-boundary spoofing | Supplying text shaped like an operator instruction or a tool result, relying on the separation between roles being a convention inside one serialised prompt. |
| Context dilution | Burying the request in a large volume of surrounding material, so that the instruction it conflicts with is distant and thinly attended. |
These are categories rather than recipes, and the list is descriptive: what defenders publish about, what red-team exercises enumerate, and what an operator reading their own logs will recognise. Not one of them is a vulnerability with a fix, which is why the response to all six is measured in cost and in consequence rather than in closure.
The defences, and an honest account of what each one buys
The measures in general use fall into three groups. Detection sits beside the generating step — a separate classifier over the input, the output, or both, which does not share the generating step's disposition and therefore does not share its argument. Policy is moved out of the prompt: a rule expressed as an instruction can be reasoned against, so the rules that matter are enforced by code around the call rather than by sentences inside it. And capability is bounded: a deployment that cannot take an action cannot be talked into taking it, which is the only measure here that does not depend on classifying anything correctly.
What none of them buys is closure, and the honest form of the claim is about cost. A classifier is pattern recognition facing an adversary who can rephrase, and it brings error in both directions — the refusals it adds to legitimate traffic are a real cost, usually discovered after deployment rather than before it. Training a stronger disposition to decline raises the effort a jailbreak takes without bounding it. Bounding capability is the measure that holds up, and it holds up precisely because it stops asking what the input meant.
The last point decides how much of the above is worth buying. Where a deployment only produces text for the person who asked, a successful jailbreak yields that person output they could probably have obtained elsewhere, and the loss is largely reputational. Where the same deployment holds credentials, sends messages, moves money or writes to a repository, the identical success becomes an action performed under the operator's own standing permissions. The wording of the attack is the same in both cases and the consequence is not, which is why the measure that scales is the one attached to permissions rather than the one attached to text.
How the Registry classifies an inbound request review task
Reviewing a set of inbound requests for phrasing designed to bypass a runtime's standing instructions is filed as data processing in this registry's classification. The requests already exist and the task does not answer them: it examines each one and produces a judgement about it, which is a derived output rather than a new artefact.
The Registry's canonical brief for this entry is filed as:
Review a set of inbound requests for phrasing designed to bypass a runtime’s standing instructions.
Submitted for assessment it is
classified as Data processing, and its wording is hashed once — to
fd2602f43ffbecfa…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/analysis.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about jailbreak
This page names no technique in a form that could be applied, evaluates no product, and states no rate at which anything succeeds or is caught. What it describes is a class of input, and what the people defending against it do about it. This registry operates no filter, tests no deployment's refusal behaviour, and has run no exercise of any kind against a live system.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about jailbreak
- What is an LLM jailbreak?
- A jailbreak is input crafted to make a deployed system produce output its operator’s rules would otherwise withhold. It targets a trained disposition and a set of instructions rather than a software defect, and it arrives through the ordinary interface in the ordinary format.
- Is jailbreaking the same as prompt injection?
- Related and not identical. A jailbreak is usually written by the person interacting with the system and aims at the policy. An injection is written by a third party, planted in material the system will read later, and aims at making it follow an instruction its operator never issued. An injection can carry a jailbreak inside it, which is where the two get confused.
- Why can a jailbreak not simply be blocked?
- Because the refusal is a disposition expressed in the same medium as the request. It generalises over phrasings instead of matching them, so an adversary can move within the space it covers, and no parser separates a permitted request from a forbidden one — permission is not a property of a sentence’s form.
- What actually reduces the risk?
- Classifiers over input and output that do not share the generating step’s disposition; enforcing consequential rules in the code around the call rather than in the prompt; and above all bounding what the deployment is able to do, since a capability that is absent cannot be argued for.
- Does a jailbreak matter if the deployment only writes text?
- It matters less, and the difference is the whole point. Text produced for the person who asked is mostly a reputational loss. The same success against a deployment holding credentials, a mailbox or a payment method is an action performed under the operator’s own standing permissions, which is why the measures worth paying for attach to permissions rather than to wording.
Related entries
Order an assessment for data processing tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.