Jailbreak & Injection Guards

JailbreakGuard denies when three blended layers reach 0.75

The guard, named jailbreak, runs a heuristic layer, a statistical layer, and a small linear model over the canonicalized text, then weights them 0.70, 0.10, and 0.20.

let h_div = weights.heuristic_divisor.max(f32::EPSILON);
let h_clamped = (heuristic_score / h_div).clamp(0.0, 1.0);
let s_clamped = statistical_score.clamp(0.0, 1.0);
let score = (h_clamped * weights.heuristic
    + s_clamped * weights.statistical
    + ml_score * weights.ml)
    .clamp(0.0, 1.0);

The heuristic layer carries most of the weight because each of its six phrase patterns is specific. A single pattern at weight 0.95 contributes 0.665 on its own, so the linear model must add the remaining 0.085, which takes a model score of at least 0.425. The policy-override test string shows the margin: 0.630 from jb_ignore_policy plus 0.124 from the model is 0.754. A lone role phrase scores 0.566 and the call proceeds to the next guard.

The statistical layer adds a fixed 0.2 for each structural signal it raises: a high punctuation ratio, high character entropy, a long symbol run, repeated character shingles, or zero-width characters in the original input. Five signals fill the layer, and its 0.10 weight keeps structure alone from crossing the threshold.

PromptInjectionGuard adds six pattern weights against 0.8

The guard, named prompt-injection, matches six patterns over the canonicalized input and denies when the weights of the patterns that fire sum to 0.8 or more.

• instruction_override, weight 0.9. An “ignore previous instructions” override clears the threshold by itself.
• exfiltration_framing, 0.5, and role_injection, 0.4. URLs, email, or POST language near data, and a forced role, reach 0.9 together.
• delimiter_injection, output_hijack, tool_chain_hijack, 0.3 each. Smuggled system delimiters, forced output, and instructions to call another tool count only alongside stronger signals.

The narrower pattern set aims at attacks on your tool wiring, an override followed by exfiltration. JailbreakGuard covers the broader role-play and policy-override framing aimed at the model.

Both guards score every string the call carries

The two guards share one extraction routine, which turns a classified action into a list of candidate strings:

1. Action text. The code body of a CodeExecution, the query of a DatabaseQuery, or the endpoint of an ExternalApiCall.
2. Arguments. Every string leaf of the call's arguments JSON, found by recursion.
3. Filter. Empty and whitespace-only strings are dropped.

Each candidate is canonicalized: ASCII is lowercased, zero-width characters are stripped, homoglyphs are folded, and separator runs collapse to one space. A scan reads at most 64 KiB of each string. The candidate then passes through the guard's fingerprint cache and its detector, and the first deny ends the loop for the whole call.

The guards see tool-action text and argument strings, and a match is evidence about that input, never a guarantee about model behavior. A model prompt or response is in scope when the host routes it through a governed call or its own detector integration, so measure false positives on the content you route. To send the same text to a cloud content-safety service, use External Guards.

A broken guard refuses the call, and empty text passes

Either guard returns Verdict::Deny when its internal mutex is poisoned, so the call ends before dispatch; JailbreakGuard returns it directly from evaluate_text. Three other inputs have fixed outcomes:

• Empty input. Empty or whitespace-only text is allowed by both guards.
• A pattern that fails to compile. JailbreakGuard logs it with tracing::error! and drops that signal from the table for the life of the process; detection continues with the remaining patterns.
• An unrecognized ToolAction variant. PromptInjectionGuard allows it, because the guard applies only to the variants it extracts text from.

Signal IDs such as jb_ignore_policy are stable, so log analysis keyed on them keeps working. Thresholds, layer weights, and the heuristic divisor live on the detector configuration, so you can retune sensitivity against your own traffic without recompiling the guard.

Each deployment adds the guards it accepts

GuardPipeline::default_pipeline() leaves both guards out. Regex and feature extraction cost time on every cache miss, pattern detectors raise false positives on ordinary prose, and attacker phrasing shifts, so you add them where those tradeoffs fit the workload.

use chio_guards::{JailbreakGuard, PromptInjectionGuard};

let mut pipeline = chio_guards::GuardPipeline::default_pipeline();

// Narrow pattern detector first.
pipeline.add(Box::new(PromptInjectionGuard::default()));

// Heavier multi-layer detector second.
pipeline.add(Box::new(JailbreakGuard::default()));

// Install on the existing mutable kernel.
kernel.add_guard(Box::new(pipeline));

A single guard registers the same way, with kernel.add_guard(Box::new(JailbreakGuard::default())). Both guards share the canonicalization pass and the fingerprint shape, the first 8 bytes of SHA-256, so back-to-back runs on one input use the same cache-key layout while each guard keeps its own LRU cache. For code a call submits, Shell & Code Guards add structural checks to this textual scan.

Next: choose the guards for your pipeline