Skip to content

Jailbreaks: A Taxonomy of the Attack Classes

4 min read · updated August 3, 2026

This page names the families and stops there. It does not list prompts that work today, because that list is stale within a model release and a defender does not need it — what a defender needs is the shape of the class, so their control does not depend on recognising one member of it.

Jailbreak is not prompt injection

They are constantly conflated and they have different victims, which means they have different controls.

TermDescription
jailbreakGetting the model to violate its own training-time policy. The adversary is usually the user; the party harmed is the vendor or the deploying company. A content-safety problem.
prompt injectionGetting the model to follow instructions from content, in violation of the deploying application's intent. The adversary is a third party; the party harmed is the user. An access-control problem.

The practical consequence: a better-aligned model meaningfully reduces jailbreaking and does comparatively little for injection, because injection does not require the model to do anything it considers wrong. Buying “a safer model” is a real jailbreak control and a weak injection control.

The families

Almost every technique in circulation is a member of one of these, and each family exists because of a structural property of how the models are trained and served — which is why new members keep appearing.

  • Framing and role reassignment. Recasting the request as fiction, as a hypothetical, as a translation, as a persona, or as a role that supposedly has different rules. Exists because refusal is context-sensitive and the model has to be able to discuss things it will not do.
  • Obfuscation and encoding. Expressing the request in a form the safety training saw less of — another language, an encoding, a cipher, character substitution, low-resource scripts. Exists because alignment coverage is uneven across the input distribution while capability generalises further than alignment did.
  • Decomposition. Splitting a refused request into steps that are individually unobjectionable and assembling the result outside the model. Exists because policy is evaluated per-turn and the model cannot see the composition.
  • Context saturation and many-shot. Filling a long context with material that makes the target behaviour look like the established pattern. Anthropic published this class as “many-shot jailbreaking” in April 2024, with the finding that effectiveness scaled with the number of in-context examples — an emergent cost of long context windows.
  • Automated adversarial search. Optimising a suffix or a paraphrase against a model until the refusal stops. Zou and colleagues demonstrated gradient-based transferable suffixes in 2023 (“Universal and Transferable Adversarial Attacks on Aligned Language Models”). This family matters most for defenders because it removes the human from the loop: your filter faces a search process, not a person.
  • Multi-turn erosion. Establishing a frame over several benign turns and only then making the request. Exists because training emphasises single-turn refusal and the conversation is re-read as one sequence.
  • Cross-modal delivery. Carrying the request in an image, audio, or a document that the model reads. Exists because safety training and input pre-processing are not equally mature across modalities.

Why patching individual prompts does not converge

The instinctive response is to collect the prompts that work and block them. It does not converge, for three reasons worth stating plainly.

The space is unbounded. Each family is a semantic equivalence class with infinite members. Blocking a string blocks a string. Blocking a paraphrase family requires a semantic classifier, which is a model with a false-negative rate, which the attacker can probe.

The attacker’s loop is faster than yours. Automated search generates candidates continuously and cheaply. A human-curated denylist updates weekly at best.

Tightening has a cost you will notice before they do. Every increase in strictness raises false positives on legitimate traffic — medical questions, security research, fiction, translation. Past a point, the refusals your own users hit exceed the harm prevented, and nobody measures that trade unless they set it up deliberately.

The posture that follows

  • Decide what you are actually protecting. If your application never needed to refuse a topic, a jailbreak of the underlying model may cost you nothing. Scope the control to real harm — output that reaches other users, output that triggers an action, output that carries your brand.
  • Filter output, not just input. The output is where the harm is. It is a smaller, more concrete space than “every way someone might ask”, and it catches every family at once.
  • Keep policy out of the model where you can. If a capability must never be used for something, remove the capability for that path rather than relying on refusal.
  • Instrument for repeated probing. A single unusual request is noise. Forty variants from one key in ten minutes is a search process, and that pattern is detectable even when no individual request is.
  • Have a response path. Rate limit, then step up friction, then suspend. A jailbreak with no consequence for the account attempting it is an invitation to iterate.

Measuring your own exposure

Published jailbreak rates tell you about somebody else’s system on somebody else’s model version. If you need a number, generate it against your own stack: assemble a small labelled set of prompts representing the harms you actually care about, run it on every model and prompt change, and track the trend rather than the absolute. Public benchmark suites exist for this and are a reasonable starting corpus; the value is the regression signal, not the score.

Do that and the question “did our prompt change make us less safe?” becomes answerable, which is more than any taxonomy can give you. The mechanics of building that harness are in the content safety layer page.

Jailbreaks: A Taxonomy of the Attack Classes · Multigrid