PaperlayerView exact revision on arXiv

Source-linked AI summary

SpecGuard: Detecting Multi-Turn LLM Jailbreaks via Specification-Based Runtime Monitoring

Junle Li, Siqi Chen, Jiakai Li, Bingzhuo Zhong

arXiv:2610.36258v1cs.CR

TL;DR

Message-level guards provide limited coverage of multi-turn behavior, while dialogue safety also lacks explicit, checkable constraints. SpecGuard builds an evidence-backed proposition contract and temporal specifications for monitoring dialogue traces. Across three benchmarks, it reports the highest AUC, F1, and recall, with replayable witnesses for verdicts.

  • Problem

    Existing approaches often lack a formal, checkable account of how process-level dialogue facts and temporal constraints jointly define a multi-turn violation.

    Source: §I · p. 2

  • Method

    SpecGuard derives evidence-backed canonical propositions and typed temporal specifications, then checks dialogue traces with compiled finite automata.

    Source: §I · p. 2

  • Results

    SpecGuard achieves the highest AUC, F1, and recall on all three benchmarks, improving F1 by 0.222 on SafeDialBench-ZH relative to its strongest F1 baseline.

    Source: B. Detection Effectiveness · p. 10

  • Takeaways & Limitations

    SpecGuard provides replayable witnesses connecting verdicts to specifications, dialogue turns, and supporting proposition evidence.

    Source: §I · p. 2, §VI · p. 13

Abstract

from arXiv · show

Multi-turn jailbreaks turn dialogue safety into a trace property: a violation may become identifiable only when user intent and assistant behavior are considered across multiple turns. Existing guard models largely classify individual messages or exchanges and return risk scores or labels, without executable safety semantics or a formally checkable decision trail. We present SpecGuard, a training-free, specification-driven framework for monitoring multi-turn LLM interactions. SpecGuard uses a fixed atomic-proposition contract to map natural-language observations into causally scoped, evidence-backed facts, and expresses forbidden interaction patterns as Linear Temporal Logic specifications. Each specification is compiled into a symbolic finite automaton that incrementally consumes the resulting dialogue trace. The same monitoring mechanism supports buffered runtime checking and retrospective auditing, while accepting runs produce replayable witnesses that identify the triggered specification, supporting facts, and relevant dialogue turns. Experiments on multi-turn safety benchmarks show that SpecGuard consistently outperforms representative open-source guard models while maintaining controlled false-positive rates. These results demonstrate a practical path from heuristic risk classification toward formally specified, verifiable, and auditable LLM safety monitoring, without learned detector parameters or access to the protected model.

I. INTRODUCTION

Multi-turn jailbreaks distribute malicious intent across dialogue turns, while message-level guards often miss temporal behavior and provide little auditability. SpecGuard represents dialogue facts with an evidence-backed atomic-proposition contract, checks temporal specifications, and supports runtime monitoring and retrospective auditing.

A. Multi-Turn Jailbreak Attacks and Existing Defenses

  • Multi-turn attacks can distribute intent across individually innocuous turns, so a violation may require considering the objective, continuation, and assistant assistance together.Existing guards often classify messages or turns without capturing temporal relations or providing a reproducible account of an alarm.Source: §I · p. 1

I. INTRODUCTION

  • SpecGuard organizes 15 canonical atomic propositions as process-level facts with speaker roles, causal inputs, semantic boundaries, and retained evidence provenance.The facts include user objectives and execution requests, assistant content and procedural detail, and effective refusals.Source: §I · p. 2
  • SpecGuard expresses forbidden behavior in ten LTL specifications—four same-turn and six adjacent cross-turn—and requires substantive assistant-side evidence for a violation.A harmful request or attack signal alone cannot trigger a violation.Source: §I · p. 2
  • The specifications compile into symbolic deterministic finite automata that incrementally monitor dialogue traces.This makes declarative safety requirements executable as finite-state monitors.Source: §I · p. 2
  • Runtime monitoring buffers a candidate reply until checks finish, while audit mode replays an existing trace and records accepting transitions and structured witnesses.Witnesses identify the specification, relevant turns, matched propositions, and supporting evidence.Source: §I · p. 2
  • Across languages and attack trajectories, SpecGuard reports stronger detection than representative open-source guards while keeping false positives under control.The paper also reports that alarms can be reproduced from witnesses and runtime and audit paths agree on the same dialogue.Source: §I · p. 2

B. Formal Specification and Runtime Verification for Safety

Prior formal safety methods typically monitor robot, planner, or agent actions, while dialogue safety lacks an established executable rule set. This section frames the threat model and introduces finite-trace temporal logic and automata for checking dialogue behavior.

B. Formal Specification and Runtime Verification for Safety

  • Earlier runtime-verification work targets robot, planner, or agent action layers, not an LLM’s conversational behavior at inference time.Dialogue-safety rules also must be constructed rather than translated from an already existing rule set, balancing broad coverage against penalizing benign sensitive-topic discussion.Source: B. Formal Specification and Runtime… · p. 3

A. Threat Model

  • The threat model gives the adversary control of user messages and the defender the role of an external causal monitor that neither accesses internals nor modifies or retrains the model.The adversary may distribute an objective across innocuous-looking turns and adapt later messages to the dialogue.Source: A. Threat Model · p. 3
  • For each match, the monitor returns a binary verdict and a witness identifying the specification, relevant turns, and propositions.Its dialogue-transcript interface is independent of the target model’s architecture.Source: A. Threat Model · p. 3

B. Preliminaries: Finite Traces and LTLf Monitoring

  • LTL specifies temporal properties over ordered traces using propositions, Boolean operators, next, and eventually.In this setting, each trace position corresponds to an observable dialogue transaction.Source: B. Preliminaries: Finite Traces and… · p. 4
  • LTLf evaluates formulas on finite traces observed so far, without assumptions about future dialogue turns.For example, eventually p followed by next q matches when p and q hold at adjacent positions.Source: B. Preliminaries: Finite Traces and… · p. 4
  • Deterministic finite automata over proposition valuations update state as each dialogue transaction arrives, enabling incremental monitoring.For the forbidden-pattern specifications, accepting states are absorbing and the accepting run identifies witness positions.Source: B. Preliminaries: Finite Traces and… · p. 4
  • Each LTLf formula can be compiled into a DFA whose acceptance preserves the formula’s finite-trace semantics.The automaton accepts exactly when the formula holds on the trace.Source: B. Preliminaries: Finite Traces and… · p. 4

C. Problem Formulation

The formulation turns a dialogue into a finite trace of causally activated atomic propositions, then checks that trace against fixed forbidden-pattern specifications. A match yields an alarm and a witness tying the verdict to dialogue turns and propositions.

C. Problem Formulation

  • A dialogue is represented by user and reply messages, with pre-reply and post-reply prefixes distinguishing evidence available before and after a response.The resulting trace contains one valuation per turn.Source: C. Problem Formulation · p. 4
  • The proposition universe separates current-user facts, current-reply facts, and dialogue-history facts, which are activated causally from the corresponding observed prefixes.History propositions can represent whether an earlier objective remains active.Source: C. Problem Formulation · p. 4
  • A finite-state monitor alarms when the dialogue trace satisfies a fixed LTLf specification, and reports a witness identifying the turns and propositions realizing the match.Every matched pattern requires multiple observations, including substantive assistant-side evidence; user behavior alone is insufficient.Source: C. Problem Formulation · pp. 4–5

IV. SPECGUARD DESIGN

SpecGuard separates the abstraction of dialogue facts from the judgment that those facts form a violation. It defines canonical atomic propositions and temporal constraints as an executable, auditable contract.

A. Framework Overview

  • The framework separates upstream fact abstraction from violation judgment, which is determined by matching the resulting trace against temporal specifications.Its monitoring component extracts AP valuations, constructs a turn-level trace, and checks for specified forbidden patterns.Source: A. Framework Overview · p. 5

B. Specification Construction

  • SpecGuard constructs its contract from a canonical AP vocabulary, causal evidence instantiation, and typed LTLf constraints, using a semantics-first process rather than detector outputs or benchmark labels.The process decomposes safety requirements into observable factors, validates their instantiation against contrastive dialogue evidence, and then composes them into temporal constraints.Source: B. Specification Construction · p. 5
  • Candidate APs must be causally observable from a dialogue prefix, describe observations rather than verdicts, distinguish safety-relevant dialogue pairs, and retain reusable supporting evidence.The resulting vocabulary contains 15 typed APs, divided into context/history, user-side, and assistant-side factors.Source: B. Specification Construction · p. 5
  • For example, harmful objectives and execution requests remain separate from assistant-side content, procedural detail, and refusal facts; only their specified relation constitutes a violation.A continuation request is normalized into a reusable factor rather than requiring a fixed phrase.Source: B. Specification Construction · p. 5
  • Safety requirements become typed relations among context, user, and assistant facts, specifying required evidence, alternatives, disqualifying conditions, and same-round or consecutive-round timing.The complete specification has four same-round constraints and six adjacent-round constraints; longer dependencies use provenance-preserving history APs.Source: B. Specification Construction · pp. 5–6
  • The AP contract and specifications are independent of dataset labels and protected-model internals, and are jointly validated and frozen before evaluation.Validation checks causal observability, speaker typing, refusal disqualification, and cross-turn ordering; the design requires positive assistant-side evidence and replayable witnesses.Source: B. Specification Construction · pp. 6–7

C. Dialogue Monitoring

Dialogue monitoring converts each completed interaction into canonical AP valuations and incrementally checks them with automata compiled from the fixed specifications. It preserves causal ordering and provenance across runtime checking and retrospective audit.

C. Dialogue Monitoring

  • AP activation converts the causal dialogue prefix into a canonical valuation through evidence grounding, relation composition, and contract guarding, rather than assigning a dialogue-level risk label.Only raw facts that pass the guard activate final APs and enter the current-round valuation.Source: C. Dialogue Monitoring · p. 7
  • Matchers emit provenance-bearing evidence records with text role, matcher, semantic slot, matched value, and location, which later stages use without rescanning raw text.A single window may produce multiple records, each retaining its textual span or structural support.Source: C. Dialogue Monitoring · p. 7
  • Relation composition organizes evidence into typed request frames and binds continuations to an active objective source from the same risk family; missing relations or sources prevent frame creation.Frames organize language, risk family, relation, polarity, scope, source and root rounds, and supporting cues.Source: C. Dialogue Monitoring · p. 7
  • For detailed assistance, the contract guard requires an affirmed operational request, compatible objective source, domain and procedural evidence, specificity evidence, and no effective refusal.These conditions exclude negation, safety-oriented analysis, isolated keywords, stale objectives, and replies without substantive detail.Source: C. Dialogue Monitoring · p. 8
  • Each trace position represents one complete user–assistant transaction, and later messages append valuations without revising earlier ones; X therefore refers to the next dialogue turn.Multiple propositions may coexist at one position without changing causal ordering.Source: C. Dialogue Monitoring · p. 8
  • Runtime mode buffers candidate replies and releases them only when no automaton accepts; audit mode replays completed dialogues using the same automata and temporal semantics.For a dialogue with T + 1 turns, finite-state audit monitoring costs O(T|Φ|), excluding AP activation.Source: C. Dialogue Monitoring · pp. 9–10
  • The compiled automata accept exactly the finite traces satisfying their source specifications, and matched transitions retain provenance for replayable witnesses.Witnesses are replayed against the frozen specification, trace digest, and raw provenance before supporting a valid verdict.Source: C. Dialogue Monitoring · pp. 9–10

A. Experimental Setup

The evaluation uses three multi-turn safety benchmarks, four representative open-weight guard models, and identical ordered exchanges. Metrics are computed on each benchmark separately under a frozen, unretrained configuration.

A. Experimental Setup

  • The benchmarks cover two languages, 10,075 dialogues, and 48,933 user–assistant turns, with native conversation-level labels retained and no pooling across datasets.SafeDialBench-ZH and SafeDialBench-EN define positives by assistant-side violations, while SafeMTData labels complete ActorAttack trajectories, including those ending in refusal.Source: A. Experimental Setup · p. 10
  • Four open-weight guards—ShieldGemma-2B [14], WildGuard-7B, BingoGuard-8B, and GuardReasoner-8B [15]—receive the same ordered exchanges as SpecGuard.The guards classify turns independently and alarm at dialogue level if any turn is flagged; SpecGuard evaluates the exchanges as a typed finite trace.Source: A. Experimental Setup · p. 10
  • F1 is the primary detection metric, with FPR, recall, balanced accuracy, and AUC also reported at the dialogue level.SpecGuard’s Boolean output uses a deterministic, label-free specification-completion score for AUC; prior-work results are contextual operating points, not identical-input comparisons.Source: A. Experimental Setup · p. 10
  • All benchmarks use one frozen contract, activator, constraint library, and monitoring configuration, with no learned detector weights or dataset-specific settings.Per-dialogue predictions, replayable witnesses, and cryptographic hashes are retained for reproducibility.Source: A. Experimental Setup · p. 10

B. Detection Effectiveness

SpecGuard leads all three benchmarks in AUC, F1, and recall, with higher F1 than the strongest F1 baseline on each. Its balanced accuracy is also highest across benchmarks, while cross-turn specifications add detections with few additional false positives.

  • SpecGuard achieves the highest AUC, F1, and recall on all three benchmarks, improving F1 over each dataset’s strongest F1 baseline.F1 gains are 0.222 on SafeDialBench-ZH, 0.290 on SafeDialBench-EN, and 0.222 on SafeMTData; the agreement with AUC indicates the advantage is not tied to one operating point.Source: B. Detection Effectiveness · p. 10, Table III · p. 11
  • Balanced accuracy is highest on all three benchmarks, despite SpecGuard not having the lowest FPR.The lowest-FPR baselines detect 8.7–13.5% of positive dialogues, while SpecGuard recovers 90.7–98.4% and has the highest F1.Source: B. Detection Effectiveness · p. 10, Table III · p. 11
  • On SafeDialBench-EN, SpecGuard reaches 96.9% recall at 10.7% FPR, with 0.931 BA and 0.943 AUC.The same contract and frozen decision configuration are used for Chinese and English evaluation without benchmark-specific threshold tuning.Source: B. Detection Effectiveness · pp. 10–11, Figure 3 · p. 11
  • On SafeMTData, the monitor detects complete ActorAttack trajectories, including attacks ending in refusal, with 0.967 AUC, 0.939 F1, and 90.7% recall.The AP contract, constraint library, and decision rule remain unchanged.Source: B. Detection Effectiveness · p. 11
  • Reference-method results are contextual operating-point comparisons, not identical-input measurements.SpecGuard has the strongest displayed AUC, F1, and recall on SafeDialBench, with FPR comparable to SafeDream; on SafeMTData it improves F1 and FPR over reported reference operating points.Source: B. Detection Effectiveness · p. 11, Table IV · p. 12
  • Cross-turn specifications improve detection and early triggering across all three datasets when added to the same-turn rules.F1 rises from 0.975 to 0.981 on SafeDialBench-ZH, 0.899 to 0.942 on SafeDialBench-EN, and 0.877 to 0.939 on SafeMTData; the additions yield 25, 172, and 184 true positives and 1, 14, and 5 false positives, respectively. The full monitor detects more positives by the midpoint and retains that advantage through the final turn.Source: B. Detection Effectiveness · p. 12

C. Faithfulness and Auditability

SpecGuard’s exported evidence reproduces its symbolic alarms through replay checks, while its complete transcript-to-verdict path runs on CPU. The conclusion summarizes its detection and witness contributions, and the ethics statement describes the work as defensive and based on public datasets.

D. Runtime Performance

  • The complete transcript-to-score-and-verdict path processes 17,913 turns in 246.8 seconds, or 72.6 turns/s and 13.8 ms per turn.The measurement includes evidence generation and completion scoring, uses four workers on an Apple M4 CPU, and requires no GPU or external model service.Source: Table VII · p. 12, D. Runtime Performance · p. 13

C. Faithfulness and Auditability

  • All 1,652 witnesses from 995 alarmed traces replay successfully, and benchmark-wide completion scores of one exactly match Boolean monitor verdicts.The integrity audit also verifies typed constraints, trace digests, and matched AP provenance; injecting excluded endpoint APs leaves decisions and digests unchanged.Source: C. Faithfulness and Auditability · p. 12
  • The audit path connects raw evidence to canonical APs, ordered witnesses, and reported verdicts; end-to-end effectiveness includes extraction, while Table V checks symbolic-decision faithfulness.Alarms include the violated constraint, fingerprint, participating turns, matched APs, raw provenance, and trace digest.Source: C. Faithfulness and Auditability · pp. 12–13

D. Runtime Performance

  • With ten fixed constraints of at most one-round offset, verdict evaluation and completion scoring take O(T|Φ|) time and trace storage takes O(T).Both costs grow linearly with dialogue length because |Φ| is fixed; F1 does not degrade in the longest (≥5-turn) stratum on any benchmark.Source: Table VI · p. 12, D. Runtime Performance · p. 13

VI. CONCLUSION

  • The conclusion presents SpecGuard as converting dialogues into auditable AP traces checked against typed LTLf specifications, with replayable witnesses for verdicts.Source: §VI · p. 13

ETHICS CONSIDERATIONS

  • The work is defensive, uses publicly released datasets, and reports no new data collection from users.The authors note that released specifications could inform adaptive evasion, while explicit auditable rules chiefly benefit defenders and can be revised as attacks evolve.Source: ETHICS CONSIDERATIONS · p. 14

APPENDIX

The appendix specifies deterministic text-grounding and provenance contracts for deriving canonical AP traces from dialogue evidence. It describes bounded matcher inputs and outputs, then details the raw-to-canonical projection and its endpoint exclusions.

A. Evidence Grounding: Matcher and Output Contract

  • The implementation defines 52 logical text-grounding matchers in nine evidence families and six bounded-relation matchers.Lexical, regex, and structural branches count as variants of one logical semantic predicate with a stable output slot.Source: A. Evidence Grounding: Matcher and… · p. 15, Table VIII · p. 16, Table IX · p. 16
  • Matchers process normalized, segmented message windows of at most three neighboring units, with long user messages restricted to request-anchored command zones.These scope restrictions do not themselves activate APs; negation, scope, refusal, and supporting spans or conditions are emitted explicitly.Source: A. Evidence Grounding: Matcher and… · p. 15
  • Matchers emit provenance-bearing intermediate evidence records rather than canonical APs or verdicts, retaining role, typed slots, values, spans, and support.Deduplication occurs only after provenance is retained.Source: A. Evidence Grounding: Matcher and… · p. 15
  • CapabilityX requires both a domain hit and procedural marker, while SpecificityX additionally requires a parameter or code hit.A parameter or domain hit alone is insufficient.Source: A. Evidence Grounding: Matcher and… · p. 15

B. AP Extraction and Provenance

  • Raw evidence is projected to canonical APs through a multi-label mapping, with canonical identifiers accepted as normalized raw evidence.The appendix gives the mapping shorthand and excludes endpoint-style predicates from the canonical projection.Source: B. AP Extraction and Provenance · pp. 15–16
  • The appendix distinguishes user, reply, and history AP groups and describes domain, harmful-objective, request, and producer identifier sets.Source: B. AP Extraction and Provenance · pp. 15–16

C. Typed Temporal Constraint Library

SpecGuard represents safety rules as typed temporal constraints over AP events, using relative turn offsets and deterministic compilation. It constructs replayable witnesses that bind a match to its trace and provenance.

C. Typed Temporal Constraint Library

D. Witness Construction and Replay

  • Witness replay recomputes the earliest match and verifies roles, turns, APs, fingerprints, trace digests, and provenance sets.Changing any checked field causes replay to fail.Source: D. Witness Construction and Replay · p. 17

E. Formal Monitoring Guarantees

Under stated assumptions at the canonical-trace boundary, SpecGuard’s automata provide finite-trace acceptance guarantees and equivalent runtime and audit decisions. The guarantees also cover prefix consistency, replayable witnesses, endpoint non-interference, extension monotonicity, and monitoring complexity.

Related papers

Loading 2610.36258v1…