RLM-JB: Recursive LM Jailbreak Detector

• The paper presents an end-to-end framework that uses recursive language models to normalize, de-obfuscate, and segment inputs for local jailbreak detection.
• It employs a staged analysis where worker models screen individual segments and aggregate evidence into an auditable final decision with high recall and precision.
• The evaluation shows a sensitivity-specificity trade-off, achieving up to 98% recall while highlighting challenges like increased processing time and adaptation to evolving threats.

RLM-JB is an end-to-end jailbreak detection framework built on Recursive LLMs for tool-augmented agents. It treats jailbreak detection as a bounded analysis program rather than a one-shot classification problem: a root model normalizes and de-obfuscates the input, partitions it into covered segments, invokes worker models for local screening, and aggregates the resulting evidence into a final auditable decision. The framework is motivated by agentic settings in which long, untrusted, stateful inputs such as emails, retrieved documents, collaboration messages, and tool outputs can contain long-context hiding, semantic camouflage, lightweight obfuscations, or split-payload prompt injections. On AutoDAN-style adversarial inputs, the reported recall or attack success rate ranges from 92.5% to 98.0% across three screening backends, with precision from 98.99% to 100% and false positive rates from 0.0% to 2.0% (Shavit, 18 Feb 2026).

1. Definition, scope, and threat model

RLM-JB is defined as a procedural jailbreak detector for LLM agents in the Recursive LLM paradigm. Its target is not generic text moderation in isolation, but prompt-injection and jailbreak detection in tool-augmented agents that operate over untrusted text and may execute tools in stateful environments. In this setting, a detection failure can propagate beyond response generation to unauthorized tool use, unsafe execution, or policy-violating actions (Shavit, 18 Feb 2026).

The threat model emphasized for RLM-JB includes long-context hiding, semantic camouflage, lightweight obfuscation, split-payload attacks, and AutoDAN-style adversarial inputs. Long-context hiding refers to malicious instructions buried within large inputs, including placements in the middle of the context where salience is reduced. Semantic camouflage refers to attacks phrased as apparently benign material such as role-play, reporting, policy discussion, or scenario wrapping. Lightweight obfuscation includes simple encodings and surface perturbations; in the implementation described in the paper, Base64 is the concrete supported case. Split-payload attacks distribute the hijacking phrase and actionable payload across different segments so that no single local span is fully self-contained (Shavit, 18 Feb 2026).

This framing distinguishes RLM-JB from one-pass guardrails. The central claim is that jailbreak detection in agentic systems should be treated as a staged security procedure over transformed inputs and intermediate state, rather than as a single global judgment over the raw text.

2. Procedural architecture and analysis workflow

The architecture is organized around a root/worker decomposition. The root model does not merely classify the entire input. It orchestrates a bounded procedure: it canonicalizes the text, optionally de-obfuscates it, segments it for coverage, dispatches local analyses, and merges local outputs into a final verdict. The worker model is a narrower classifier over a single chunk, returning a structured local decision, a confidence score, extracted attack vectors, and an explanation string (Shavit, 18 Feb 2026).

Two implementation variants are described. In the “segment-code” variant, the root LM may generate Python code once, cache it by text key, and execute that code over segments inside a constrained sandbox. In the “RLM per-segment” variant, the root LM is invoked per segment and produces a REPL code block that calls the worker model. In both variants, the detector remains a bounded analysis program with constrained execution and fixed detector-side policies (Shavit, 18 Feb 2026).

The workflow is explicitly staged:

1. raw untrusted text is ingested;
2. formatting is canonicalized;
3. Base64-like content is decoded when possible;
4. the normalized text is partitioned into segments;
5. each segment is screened independently, with optional parallelism;
6. responses are parsed into structured tuples;
7. segment-level evidence is aggregated conservatively;
8. rule-based overrides are applied at the full-text level;
9. the detector emits a structured final decision with confidence, attack vectors, and supporting evidence.

The paper defines “auditable decision” operationally. The detector exposes intermediate artifacts, including decoded text, chunk boundaries, segment-level judgments, extracted attack vectors, explanations, and the final aggregation rationale. This makes the detector inspectable by downstream systems and by human operators (Shavit, 18 Feb 2026).

3. Formal model and decision rules

The formalization in the appendix specifies the input space as the space of text strings, the final verdict space as

$$\mathcal{Y}=\{\text{MALICIOUS},\text{SAFE},\text{ERROR}\},$$

and the chunk-level verdict space as

$\mathcal{V}=\{\text{MALICIOUS},\text{SAFE}\}.$

Each segment analysis returns a tuple

$v_i=(y_i,\gamma_i,A_i,e_i),$

where $y_i$ is the chunk verdict, $\gamma_i\in[0,100]$ is confidence, $A_i$ is a set of attack-vector categories, and $e_i$ is an explanation string (Shavit, 18 Feb 2026).

The initial aggregation rule is intentionally conservative. If

$m=\sum_{i=1}^k \mathbb{1}_{y_i=\text{MALICIOUS}},$

then the pre-override global decision is

$$V^{(0)}= \begin{cases} \text{MALICIOUS}, & m>0,\ \text{SAFE}, & \text{otherwise}. \end{cases}$$

The appendix states the corresponding monotonicity guarantee: $$\exists i:\ y_i=\text{MALICIOUS}\ \implies\ V^{(0)}=\text{MALICIOUS}.$$ This guarantee is the formal basis for the claim that local detections are not diluted away by later averaging or majority voting (Shavit, 18 Feb 2026).

After the initial aggregation, the detector applies full-text overrides. Three rule classes are described. First, indirect weapon signals can escalate a SAFE result to MALICIOUS, with confidence at least 85 and the addition of the attack vectors indirectweaponinstructions and contentpolicy. Second, reporting context can downgrade a MALICIOUS result to SAFE, cap confidence at 30, and clear attack vectors when the text appears to be discussing harmful content rather than instructing action and there are no indirect weapon signals. Third, Base64 escalation can convert a SAFE verdict into MALICIOUS if decoded text contains jailbreak keywords or if decoded text has low readability, adding base64obfuscation together with either contentpolicy or suspiciousencoding (Shavit, 18 Feb 2026).

The detector also formalizes coverage and complexity. Chunking is defined so that the union of all chunks equals the normalized text, and the runtime decomposition isolates linear-time preprocessing and aggregation from segment-analysis cost. The paper gives

$\mathcal{V}=\{\text{MALICIOUS},\text{SAFE}\}.$0

where $\mathcal{V}=\{\text{MALICIOUS},\text{SAFE}\}.$1 is text length, $\mathcal{V}=\{\text{MALICIOUS},\text{SAFE}\}.$2 is the number of chunks, and $\mathcal{V}=\{\text{MALICIOUS},\text{SAFE}\}.$3 is the number of available segment workers (Shavit, 18 Feb 2026).

4. Normalization, de-obfuscation, and chunk coverage

Normalization is described as lightweight canonicalization, including normalization of whitespace and separators so that superficial formatting changes do not unduly affect later heuristics. De-obfuscation is more specific. The implementation captured in the appendix supports Base64 detection and decoding; if a string is Base64-like and decodable, the detector uses the decoded form and records an obfuscation flag of base64, otherwise the flag is none (Shavit, 18 Feb 2026).

Chunking is designed to mitigate context dilution and guarantee coverage. The main text characterizes the segments as overlapping and motivated by long-context hiding and “lost in the middle” effects, while the appendix’s detector-side formulation specifies paragraph-based splitting with fallback to fixed-size contiguous chunks. In the “true RLM” implementation described there, chunking is fixed rather than generated by the master, with “paragraphs / 1200, single if $\mathcal{V}=\{\text{MALICIOUS},\text{SAFE}\}.$4” (Shavit, 18 Feb 2026).

The operational rationale is twofold. Smaller segments improve local salience for the worker model, making it less likely that local jailbreak cues are missed within a long context. Complete segmentation ensures that no text region remains unexamined. This suggests that RLM-JB’s robustness arises not merely from the choice of screening model, but from detector-side control over coverage, normalization, and structured evidence composition.

The parsing stage is also part of the security design. Worker outputs are parsed as JSON when possible, then as a dictionary representation, and otherwise replaced by a safe default. The default tuple is

$\mathcal{V}=\{\text{MALICIOUS},\text{SAFE}\}.$5

with explanation normalization to hide parse-failure phrases (Shavit, 18 Feb 2026). This detail matters because RLM-JB is implemented as a bounded procedure over structured intermediate state rather than as unconstrained free-form reasoning.

5. Empirical results and backend trade-offs

The experimental evaluation is centered on AutoDAN-style attacks, newer prompt-injection payloads from the InjectPrompt corpus, and common permutations of each payload. The main benchmark uses 400 adversarial test cases per screening backend and interleaves 200 benign prompts to estimate over-blocking. The backends compared in the principal quantitative table are DeepSeek-V3.2, GPT-4o, and GPT-5.2 (Shavit, 18 Feb 2026).

Backend	Recall / FPR	Precision / F1
DeepSeek-V3.2	92.50% / 0.00%	100.00% / 96.10%
GPT-4o	97.00% / 0.50%	99.74% / 98.35%
GPT-5.2	98.00% / 2.00%	98.99% / 98.49%

The paper interprets these results as a sensitivity-specificity trade-off controlled by the screening backend. GPT-5.2 gives the highest recall but also the highest false positive rate among the three reported configurations. GPT-4o is presented as a practical balance point (Shavit, 18 Feb 2026).

A particularly important internal comparison uses the same backend with and without the RLM-JB procedure. Direct use of GPT-5.2 without RLM-JB yields recall 59.57%, false positive rate 1.67%, precision 100.00%, and F1 69.71%. With RLM-JB, the same backend reaches recall 98.00%, false positive rate 2.00%, precision 98.99%, and F1 98.49%. The paper treats this within-backend comparison as the strongest evidence that chunk coverage, normalization or de-obfuscation, and cross-chunk aggregation contribute more to robustness than a simple swap to a stronger base model (Shavit, 18 Feb 2026).

On the additional InjectPrompt evaluation, the paper states that RLM-JB detected all attacks with 100% accuracy and zero false positives on the tested payloads and common permutations. The discussion, however, also notes that broader standardized evaluation would strengthen this claim (Shavit, 18 Feb 2026).

6. Limitations, deployment considerations, and nomenclature

The paper identifies three principal limitations. First, evaluation remains limited relative to fully adaptive adversaries that optimize directly against the detector. Second, RLM-JB incurs extra cost and latency because it performs normalization, chunking, and multiple worker calls; the reported figure is that “RLM-JB with GPT-5 incurred up to ~3× the processing time compared to the baseline GPT-5.2 pipeline.” Third, generalization may vary with chunking policies, thresholds, prompt templates, and the choice of screening model (Shavit, 18 Feb 2026).

Several deployment constraints are concrete. The full pipeline requires code-execution support, which excludes some candidate backends from quantitative comparison. The implementation described in the appendix supports Base64 de-obfuscation but not a broader family of encodings. Throughput improvements come from chunk-level parallelism rather than a single batched worker call over all chunks (Shavit, 18 Feb 2026).

The future directions listed by the authors are correspondingly procedural and adversarial: broader evaluation against adaptive red-teaming, extension to multi-turn and more explicitly agentic threat models, attention to indirect prompt injection and tool-output manipulation, calibrated risk scoring for downstream policy thresholds, and engineering work to reduce overhead while preserving high recall and low false positive rate (Shavit, 18 Feb 2026).

In nomenclature, the supplied literature shows that “RLM-JB” is specific to recursive language-model jailbreak detection, and should not be conflated with unrelated uses of “RLM” or “JB” elsewhere on arXiv. “RLM” also denotes a Riemannian Levenberg–Marquardt method on manifolds (Adachi et al., 2022) and relaxed Lagrange multiplier schemes for phase-field models (Jing et al., 1 Jul 2026), while “JB” and “JB$\mathcal{V}=\{\text{MALICIOUS},\text{SAFE}\}.$6-triples” belong to a separate Jordan-operator-theoretic literature on conorms, $\mathcal{V}=\{\text{MALICIOUS},\text{SAFE}\}.$7-ideals, and related structures (Jamjoom et al., 2015, Blecher et al., 2024). This indicates that RLM-JB is not a generic composite acronym spanning those traditions, but the specific name of a jailbreak-detection framework in the Recursive LLM paradigm.