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
- Baseline the refusal, then vary framing: roleplay/persona ("you are DAN…"), hypothetical/ fiction, "for research/defensive" framing, or authority impersonation.
- Obfuscate the trigger: encodings (base64/rot13/leetspeak), other languages, token splitting, or asking for the answer in parts.
- Context attacks: long benign context then the ask; many-shot with fake compliant examples; instruction-hierarchy confusion (fake "system" messages).
- Output-channel tricks: ask for the disallowed content inside code/JSON/translation where filters are weaker.
- 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.