Jailbreak & indirect injection
Catch attempts to break your system prompt, and malicious instructions smuggled in through tool results and retrieved content.
Overview
Two context-aware guardrails
Beyond the mandatory input-injection check on the user's message, Anoman ships two related guardrails that watch for more subtle attacks. Each is a per-policy-group mode.
jailbreak_detection_mode— detects jailbreak and DAN-style attempts to override the system prompt or policy ("ignore all previous instructions", roleplay escapes, prompt-leak probes).indirect_injection_mode— detects INDIRECT prompt injection: malicious instructions that arrive not from the user's direct message but via tool results, retrieved documents, or other untrusted content the model reads mid-task.
How this differs
Distinct from mandatory input injection
These are NOT the same as the always-on input-injection guardrail. That guardrail (a DeBERTa classifier on the user's prompt) is mandatory, cannot be disabled per key, and returns 403 on a detected direct injection — see the guardrails overview. Jailbreak and indirect-injection detection are separate, configurable layers that default to monitor so you observe attempts before you enforce.
Modes
off / monitor / block
Both guardrails share the same three modes, defaulting to monitor. Set them independently per policy group.
| Mode | Behavior |
|---|---|
| off | No detection. The guardrail is skipped. |
| monitorDefault | Detect and LOG only — never blocks. Attempts are recorded to Security Activity so you can measure the rate before enforcing. This is the default. |
| block | Return HTTP 403 on a detected attempt. The request is never routed to the provider. |
// Policy group config (PATCH /anoman/v1/policy-groups/{id})
{
"jailbreak_detection_mode": "block", // off | monitor | block
"indirect_injection_mode": "monitor" // off | monitor | block
}Findings
Where attempts are recorded
Configure both modes per policy group at /dashboard/guardrails. Detections — including monitored ones that didn't block — appear on the Security Activity dashboard at /dashboard/security-activity, so you can review real attempts before flipping a guardrail to block.
Related: output DLP for scanning responses, and policy groups for how per-group config and per-key overrides interact.
Watch for jailbreaks
Both detectors are already monitoring — escalate to block when the signal is clean.