A taxonomy of ten LLM jailbreak classes, organized by the attack surface each one uses. The class taxonomy is the durable part: individual prompts die with the next model release, the surfaces do not. Each entry below describes the mechanism, the control that addresses it, and where to find a benchmark for it.
This page deliberately carries no per-model status. Which class lands against which model family is a dated question, kept apart from this taxonomy: the Still Works? tracker archives a directional Q2 2026 snapshot of it, with the class-level source named on every cell. For the mechanism behind the classes, see how LLM jailbreaks work.
We do not publish working strings for active jailbreaks. We describe the technique class, link to academic disclosures or maintained corpora where available, and say how to measure the class against your own deployment.
1. Persona-redefinition
The classic. Tell the model to adopt a persona that doesn’t have its alignment constraints. “DAN” (Do Anything Now), “Developer Mode,” “Evil Confidant.” Variants pivot on which persona properties are redefined. The lineage of the best-documented example is traced in DAN prompt jailbreak explained.
How to evaluate it: the named templates are the cheapest possible baseline, because they are public and fingerprintable. Shen et al. (arXiv:2308.03825) released the 1,405 in-the-wild jailbreak prompts they collected, persona templates among them; run those and treat a hit as a signal that no template matching is in place at all. JailbreakBench is the complement for scoring: it supplies a standard behavior set, published attack artifacts and a judge, not a persona corpus. Paraphrased and novel personas are the part a corpus cannot cover.
Mitigation: refusal training carries most of the load here, which means an application owner inherits whatever the base model does. Output-side classification is the part you control.
2. Encoding-class smuggling
Wrap the harmful request in base64, ROT13, hex, leetspeak, Pig Latin, or unicode confusables. The model decodes inline and processes the unwrapped intent.
How to evaluate it: send the same restricted request in plain text and in each encoding, and compare refusals. A model that refuses the plain form and answers the encoded one is doing surface-level matching. Stacked encodings (base64 of leetspeak of the instruction) are the variant a single decode pass misses.
Mitigation: normalize-then-classify on inputs, not just classify the literal string, and chain the decode step so a decoded payload that still looks encoded goes around again. The full family — fragmentation, ciphers, low-resource translation, automated decomposition — is broken out in payload splitting and encoding jailbreaks.
3. Multimodal injection
Embed the jailbreak instruction in an image, audio file, EXIF metadata, PDF metadata, or any non-primary input channel. The model sees both modalities; the typical guard sees one.
How to evaluate it: take a request the text channel refuses, render it into the image or audio channel, and resend. A difference in outcome between channels is the finding. That channel gets its own writeup, with the primary research, in multimodal jailbreaks.
Mitigation: per-modality classification. A safety pass tuned on text does not transfer to pixels or audio, and adding one is a deliberate engineering decision rather than a default.
4. Indirect injection via retrieval / browsing
Plant the jailbreak in a public document the model retrieves via RAG, or a webpage the agent browses. The user never types anything malicious; the model encounters the payload via tool output.
How to evaluate it: this one cannot be tested against a model endpoint at all. Plant a marked instruction in a document the application will retrieve, then run a normal user task and watch whether the marker reaches the output or a tool call. The class is a function of the application’s data flow, not the model’s prompt format, and it maps to OWASP LLM01.
Mitigation: separate “data” from “instructions” architecturally. Retrieved content should not be treated as user-equivalent input. Hard-coded sentinels around retrieved content help; perfect mitigation requires capability-scoping at tools.
5. Multi-turn manipulation
Across a conversation, gradually redefine terms, build false context, or escalate from benign to restricted. Each individual turn is safe; the cumulative trajectory is not.
How to evaluate it: a single-turn probe set cannot measure this class by construction. You need a trajectory harness that scores the session, not the turn. The escalation patterns and the primary research are in multi-turn role-play attacks.
Mitigation: server-side session state tracking, periodic re-anchoring of the system prompt mid-conversation, output-side classification on cumulative outputs.
6. Role-play with redirect
Frame the request as fictional. “Write a story where a character explains how to…” The model produces the harmful content within the fictional frame.
How to evaluate it: the tell is whether refusal survives the frame. Ask directly, then ask inside a fictional wrapper, and compare. A model that refuses the first and answers the second is scoring the frame rather than the content.
Variant: the “translation” framing, where “translate this Spanish text to English” hides a jailbreak in the source text, and low-resource languages are the harder case.
7. Adversarial-suffix attacks (GCG-class)
Optimization-based: find a suffix string that triggers the model. Output looks like garbled tokens; works reliably.
How to evaluate it: this class needs a white-box proxy model to optimise against, which makes it the most expensive entry here to run and the least representative of a typical attacker. The GCG primer covers the mechanics; the trade-off against query-cheap black-box optimizers is in PAIR vs GCG vs TAP.
Mitigation: perplexity-based input filtering (catches obvious cases), output-side classification, capability scoping. None individually sufficient.
8. Tool-call abuse
For agents with tools: instruct the model to use a tool with attacker-controlled arguments, chain benign tool calls into a malicious composite, or exploit the model’s ability to interpret tool outputs as instructions.
How to evaluate it: enumerate every tool the model can call, then ask what a malicious argument to each one would do. The finding is a tool whose arguments are trusted because the model produced them. This is the highest-consequence class for agent applications, since a hit is a state change rather than a bad paragraph.
Mitigation: capability scoping at tools, server-side validation of tool args, separation of plan-and-act phases. The containment patterns that actually hold at this layer are covered in the lethal trifecta and CaMeL, and the developer-tooling variant in prompt injection in IDE coding agents.
9. Output-channel exfiltration
Even when the model refuses to PRODUCE the harmful content, it may LEAK information through its reasoning trace, error messages, or refusal explanations. The system-prompt case is covered in system prompt extraction techniques. “I cannot help with X because [explanation that includes most of X].”
How to evaluate it: score the refusal text, not just the compliance text. Any pipeline that stops checking once the model says “I cannot” is blind to this class, and visible reasoning traces widen it.
Mitigation: output-side classification on the full response including refusal text, and suppressing reasoning visibility for sensitive topics.
10. Length-exhaustion attacks
Burn the model’s context with a long preamble that exhausts its ability to maintain alignment, then issue the request. Variant: extremely long single-turn prompts that overflow attention to safety-relevant tokens.
How to evaluate it: hold the request constant and vary the preamble length. A refusal that degrades as the context fills is the signal. Long-context deployments make the delivery cheap, which is why the class outlived the context limits that created it.
What defenders should track
For each class:
- A specific test corpus you can run against your deployment — see the jailbreak benchmarks reference for which public dataset fits which question
- A baseline measurement of resistance
- A tracking metric in production (how often does this class appear in real traffic?)
- A mitigation owner and a planned-remediation date
Without these, “we have AI security” is unverifiable. With them, you have an operational program.
Where this taxonomy sits in the network
This is the offensive cluster’s taxonomy. The defensive cluster (sentryml.com, guardml.io) publishes mitigation playbooks per class. The engineering cluster (llmops.report) covers production observability.
The taxonomy is stable. Within-class effectiveness against any particular model is not, which is why the Still Works? tracker keeps it apart, as a dated directional snapshot with a class-level source on every cell.
What we don’t publish
Working strings for active classes. The ethics line is consistent: we describe the technique enough for defenders to test against, we don’t hand attackers ready-to-use payloads.
For more context, AI attack techniques covers related topics in depth.
