Most organisations now run at least one service built on a large language model (LLM), whether a customer-facing chatbot, an internal assistant, or a feature quietly embedded in a larger product. Each of these comes with a set of rules about what the model should and should not do. Jailbreaking is the practice of getting the model to break those rules.
It helps to be clear about where the rules come from, because that decides how easily they give way. Some are trained into the model itself. A well-built model will decline to write malware or explain how to hurt someone even when nothing in its configuration tells it to refuse, because that behaviour was reinforced during training. Other rules are set at deployment time through a system prompt, the instructions an organisation gives the model before any user interacts with it: stay on the subject of our products, never discuss a competitor, do not give financial advice. The trained rules tend to be sturdier than the system-prompt rules, though neither is a hard boundary. Both can be worn down with the right input.
That is the uncomfortable part for anyone running these systems. Unlike a typical software exploit, a jailbreak targets no coding flaw. The input is ordinary language, and following language is exactly what the model was built to do.
What a jailbreak is trying to do
At its simplest, a jailbreak has one aim: get the model to produce something it would otherwise decline. That might be genuinely dangerous content, or it might be a more mundane breach of the deployment rules, such as coaxing a customer-service bot into writing a poem, talking about a rival, or repeating its own system prompt back to the user. The reputational distance between “our AI assistant said something offensive” and “our AI assistant disclosed its internal instructions” is short, and both begin the same way.
The methods attackers use fall into three broad approaches. Knowing them matters less as a catalogue of tricks than as a way to see why the problem is hard to close.
Persuasion: talking the model into a different role
The largest family of jailbreaks works by persuasion. The attacker convinces the model to adopt a frame in which the rules no longer seem to apply.
The best-known example is the “Do Anything Now” prompt, a long passage of text that instructs the model to play an unrestricted alter-ego with no policies and no refusals. The length is deliberate, an attempt to bury the model’s trained caution under the sheer weight of contrary instruction. Related techniques ask the model to role-play a character who would happily share the information, or to treat the whole exchange as fiction. A widely circulated version asks the model to act as a grandparent recounting an old story, with the restricted content tucked inside the reminiscence. Another tells the model it is running in an “opposite” or unrestricted mode, in which its normal answer should be reversed.
These work best against rules set by the system prompt, because those rules are simply more text, and the model has no dependable way to tell the organisation’s instructions apart from the user’s.
Obfuscation: hiding the request in plain sight
The second approach conceals the request so that neither a keyword filter nor the model’s own caution recognises it at first glance. An attacker might break a sensitive word into pieces, spell it backwards, or encode it, then ask the model to reassemble the parts and act on the result.
A more advanced version turns a capable model’s own intelligence against it. The attacker defines a private encoding scheme, then asks the model to read an encoded question and reply only in the same encoding. Because the sensitive exchange never appears in plain language, the usual checks have nothing obvious to catch, and the model performs the decoding and re-encoding itself. This particular technique only succeeds on the more capable models, since a weaker one cannot follow the encoding reliably. That detail is worth pausing on: some attacks become more effective as the underlying model improves, not less.
Completion: exploiting how the model works
The third approach exploits the mechanical fact that an LLM produces text by predicting what should come next. If an attacker writes the opening words of a compliant answer and hands them to the model to continue, the model may carry on from where the sentence was left, stepping past the point at which it would normally have refused.
Researchers have pushed this further by computing suffixes, short strings that read as nonsense to a person, that reliably tip a model into compliance when appended to a request. These are highly specific to a single model and are the least accessible of the techniques, but they make an important point. Jailbreaks are not only a matter of clever wording. Some are the product of systematic, automated search, and those do not depend on any human turn of phrase at all.
Why there is no simple fix
Two things make this hard to manage. The first is that there is no universal defence, and no universal attack either. A prompt that jailbreaks one model may fail against the next, and a model hardened against last quarter’s techniques may fall to this quarter’s. It is a continuing contest rather than a problem solved once. The second is that the boundary between a legitimate instruction and a malicious one is genuinely unclear. The very flexibility that makes these models useful, their readiness to follow instructions written in everyday language, is what makes them possible to talk around.
This is why treating the system prompt as a security control is a common and costly mistake. It is a reasonable way to steer behaviour, but it was never built to withstand a determined user, and it should not be the only thing standing between that user and an unwanted result.
What you should do
No unjailbreakable model exists today, so the realistic goal is a narrower one: lower the chance of a successful jailbreak, and limit what a successful one can reach.
Sensitive behaviour should never rest on the model’s cooperation alone. Where a model can take a consequential action, such as sending a message, querying a record, or changing a setting, that action belongs behind a separate check that does not assume the model has behaved. Inputs and outputs are both worth screening with dedicated filters rather than trusting the model to police itself, and any output that feeds another system should be handled as untrusted, exactly as raw user input would be. Adversarial testing, in which a red team sets out to break the model’s rules on purpose, belongs before launch and as a recurring exercise afterwards, because the techniques keep moving. And the arrangement needs an owner: someone accountable for how the model behaves in production, and for responding when it behaves badly.