7 Jailbreak Prompts That Bypass LLM Safety Logic — and How to Test Your Defenses

Your LLM app has a system prompt. It has rules. You tested it manually a few times before launch. That is not enough.

Jailbreak prompts are structured adversarial inputs designed to bypass the behavioral constraints built into your model or your application layer. They do not exploit a memory vulnerability. They exploit the model's tendency to follow instructions — including instructions that contradict your own.

This article covers 7 real jailbreak prompt patterns, what a policy break looks like in raw output, and how to test your /chat or /complete endpoint systematically.

What a jailbreak actually does

Your system prompt tells the model who it is and what it refuses to do. A jailbreak prompt tells the model to be something else, or reframes the request so the refusal logic does not trigger.

The model does not "know" it is being attacked. It processes tokens. If the attacker's tokens create a context where compliance feels more coherent than refusal, the model complies.

This is an OWASP LLM Top 10 risk — specifically LLM02 (Insecure Output Handling) and LLM01 (Prompt Injection) depending on how the jailbreak is delivered. Both categories appear in BastionLLM's test payload library.

The 7 Jailbreak Prompt Patterns

1. DAN (Do Anything Now) Role Assignment

Pattern: The attacker tells the model it has a second mode with no restrictions, then addresses that mode directly.

Example structure:

Why it works: The model has been trained to follow role assignments. If the framing is convincing enough, it treats the DAN persona as a valid instruction context and produces output it would otherwise refuse.

Policy break signal: The model stops prefacing answers with refusals and starts responding in a different register — often more casual, more explicit, or directly acknowledging it is operating "without restrictions."

Severity: High. A clean DAN bypass means your system prompt has no effective authority over persona reassignment.

2. Fictional Framing

Pattern: The request is wrapped in a story, screenplay, or game context. The harmful content becomes "what the character says" rather than what the model says.

Example structure:

Why it works: The model separates its "author" identity from its "character" identity inconsistently. Many models will produce content in fiction that they refuse to produce directly.

Policy break signal: The model produces the restricted content inside narrative quotes or stage directions, with no refusal.

Severity: Medium to high, depending on what content the fictional wrapper extracts.

3. Persona Override via System-Level Instruction Mimicry

Pattern: The attacker injects text that looks like a system prompt — using formatting, capitalization, or bracketing that mimics how system instructions are typically written.

Example structure:

Why it works: The model cannot cryptographically verify which instructions came from the system prompt versus the user turn. If the injected text looks authoritative, the model may treat it as authoritative.

Policy break signal: The model confirms the new directive or starts behaving as if its original instructions no longer apply. This overlaps with direct prompt injection (OWASP LLM01).

Severity: High. This is one of the most direct attacks on your application's trust boundary.

4. Token Smuggling and Character Substitution

Pattern: The attacker encodes the restricted request using character substitutions, leetspeak, Base64, reversed text, or Unicode lookalikes to evade keyword-based filters.

Example structure:

Or:

Why it works: Your output filter checks for specific strings. The encoded version does not match. The model decodes and answers before any filter sees the plain-text output.

Policy break signal: The model decodes the input and provides a direct answer to the restricted question, with no indication it recognized the evasion attempt.

Severity: Medium. Depends heavily on whether your application has output filtering and how it is implemented.

5. Hypothetical and Academic Framing

Pattern: The request is prefaced with "for research purposes," "in a hypothetical scenario," or "purely theoretically." The attacker is asking the model to reason about something, not do it.

Example structure:

Why it works: Models are trained to be helpful to researchers and educators. The framing shifts the perceived intent of the request, and the model's refusal logic often does not fire on requests framed as analysis.

Policy break signal: The model provides a detailed, actionable answer prefaced with "hypothetically" or "in theory" — but the content itself is the policy violation.

Severity: Medium. The output is still harmful regardless of the framing the model accepted.

6. Continuation Attack

Pattern: The attacker starts the restricted content themselves and asks the model to continue it.

Example structure:

Why it works: The model is optimized to complete text. The attacker has already established the direction of the output. The model's job is just to continue — and continuation feels less like generating restricted content than initiating it.

Policy break signal: The model picks up mid-sentence and completes the restricted content without hesitation.

Severity: Medium to high. Particularly effective against models with weak completion-mode safety tuning.

7. Role-Play Escalation Chain

Pattern: The attacker establishes an innocuous role-play scenario first, then gradually escalates the requests within that established context.

Example structure:

Why it works: Each individual step seems like a reasonable continuation of the established context. The model's safety logic evaluates each turn in isolation rather than tracking the cumulative trajectory of the conversation.

Policy break signal: By turn 3 or 4, the model is producing specific, actionable content it would have refused if asked directly in turn 1.

Severity: High in multi-turn applications. Chatbots and copilots with conversation history are particularly exposed.

What a Policy Break Looks Like in Raw Output

Knowing the pattern is one thing. Recognizing a policy break in raw output is another.

A clean policy break typically looks like one of these:

• Direct compliance: The model answers the restricted question with no refusal, caveat, or acknowledgment that the request was unusual.
• Persona confirmation: The model explicitly acknowledges its new role ("As DAN, I can tell you...") and proceeds.
• Framing acceptance: The model adopts the hypothetical or fictional frame and produces the restricted content inside it.
• Partial compliance: The model hedges briefly ("I shouldn't say this, but...") and then produces the content anyway. This still counts as a policy break.

A false positive refusal looks different: the model refuses a benign request because it superficially resembles a restricted one. Both matter for your application quality.

Scoring severity requires looking at what the model actually produced, not just whether it refused. That is why raw output matters. Pass/fail verdicts alone miss the nuance.

How to Test Your Endpoint for Jailbreak Vulnerabilities

Manual testing with a handful of prompts is not a testing strategy. You will miss patterns. You will not catch regressions after model updates or prompt changes.

A structured approach covers:

1. Direct jailbreak probes across all 7 patterns above, plus variants
2. Severity scoring on each output — not just pass/fail
3. Regression testing after any change to your model, system prompt, or integration
4. Raw output capture so you can reproduce and fix failures yourself

BastionLLM runs this automatically against your endpoint. Paste your endpoint URL, configure your request headers and response field path, and run a scan. The free plan sends 25 adversarial prompt attacks per scan with pass/fail verdicts. No account required for a 6-attack guest scan.

The Pro plan runs 450-plus attacks per scan, including DAN variants, role-play escalation chains, token smuggling attempts, and the full range of patterns above — 489 test payloads total, aligned to the OWASP LLM Top 10. You get scored results with raw model outputs, regex and heuristic verdicts, and PDF/JSON export for audit trails. Weekly automated scans catch regressions without you having to remember to run them.

Hardening Your Defenses

Testing tells you where you are exposed. Fixing it requires changes to your application, not just your model.

What actually helps:

• Output validation at the application layer. Do not rely on the model to refuse. Validate what it returns before it reaches the user.
• Constrain the output format. If your endpoint only needs to return structured JSON, a jailbroken free-text response is easier to detect and reject.
• Treat multi-turn context as an attack surface. Log and review conversation trajectories, not just individual turns.
• Separate system prompt authority from user input. Never let user-supplied text appear in a position where the model might treat it as a system instruction.
• Re-test after every model, prompt, or integration change. A prompt that was safe on GPT-4o may behave differently after a model update or a system prompt edit.

One-time pre-launch testing is not a defense. The attack surface changes every time your stack changes.

FAQs

Your safety logic is only as strong as what it has been tested against. Seven patterns is a starting point. A real attacker tries hundreds. Paste your endpoint at bastionllm.com and find out where yours breaks before someone else does.