anoman
Sign InGet API Key
Documentation home

Jailbreak & indirect injection

Catch attempts to break your system prompt, and malicious instructions smuggled in through tool results and retrieved content.

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.

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.

Why default to monitor? Real traffic contains benign phrasing that looks adversarial. Watching the would-fire rate on your own traffic first lets you escalate to block with confidence instead of surprising legitimate users.

off / monitor / block

Both guardrails share the same three modes, defaulting to monitor. Set them independently per policy group.

ModeBehavior
offNo detection. The guardrail is skipped.
monitor (Default)Detect and LOG only — never blocks. Attempts are recorded to Security Activity so you can measure the rate before enforcing. This is the default.
blockReturn HTTP 403 on a detected attempt. The request is never routed to the provider.

Config

// Policy group config (PUT /anoman/v1/policy-groups/{id})
{
  "jailbreak_detection_mode": "block",  // off | monitor | block
  "indirect_injection_mode": "monitor"  // off | monitor | block
}

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.

On this page