LLM jailbreaking / guardrail bypass

When it applies

The target enforces content/safety policy on an LLM and you're assessing whether it holds (product safety testing, or a bounty where policy bypass is in scope). Distinct from ai-prompt-injection (which is about overriding instructions/trust boundaries, often for data/tool impact); jailbreak targets the safety layer.

Why it works

Guardrails are probabilistic and layered onto a model that will comply given the right framing. Roleplay, obfuscation, context-flooding, and instruction-hierarchy confusion move the request into a region where the safety training doesn't fire.

Method

1. Baseline the refusal, then vary framing: roleplay/persona ("you are DAN…"), hypothetical/ fiction, "for research/defensive" framing, or authority impersonation.
2. Obfuscate the trigger: encodings (base64/rot13/leetspeak), other languages, token splitting, or asking for the answer in parts.
3. Context attacks: long benign context then the ask; many-shot with fake compliant examples; instruction-hierarchy confusion (fake "system" messages).
4. Output-channel tricks: ask for the disallowed content inside code/JSON/translation where filters are weaker.
5. Record what worked for the report/eval; measure reliability (does it repeat?).

Gotchas

• Tie findings to the product's actual policy/impact — a single edgy output may be low; reliable policy bypass with real-world harm is the report.
• Guardrails are stochastic; repeat to show reliability, not a one-off.
• Keep test content within legal/ethical bounds and program scope; don't generate genuinely harmful artifacts.

Verify success

The model reliably produces output its stated policy forbids, with the reproducible prompt(s).

References

OWASP LLM Top 10 (2025); published jailbreak taxonomies; the product's usage policy.