Monitor-Validity Failures: LLM Safety Evidence Paths at Evolving Framework Boundaries

Junchi Liao

cs.AIOct 16, 2026

Monitor-Validity Failures: LLM Safety Evidence Paths at Evolving Framework Boundaries

Authors: Junchi Liao

Abstract

Modern LLM applications rely on runtime monitors that inspect tool calls, traces, streams, detector outputs, and verifier inputs. This creates an interface-reliability problem: a framework path may remain operational while policy-relevant evidence never reaches its decision point. In one representative case, a regex detector returned a positive match, but the framework stranded the result before the block decision. This differs from jailbreaks and detector errors because the evidence is already recognized yet disconnected from enforcement. We study this repair-boundary signature with canary contracts: parent/fixed confirmation units that place a known payload only on the changed evidence surface and record monitor visibility together with the downstream decision for action-boundary cases. Applying the protocol to public framework repairs, we confirm 18 evidence-path failures across 11 LLM or agent safety project groups and four implementation ecosystems. Nine are established-boundary repairs, eight are new-surface policy-coverage gaps, and one is a boundary-only evidence case. Fourteen reach E1 enforcement boundaries: seven native action outcomes, six configured enforcement boundaries, and one synthetic-consumer consequence. The remaining cases affect verifier, safety-prompt, or observability channels. The cases form carrier, adapter, authority, and surface families and show how ordinary application behavior can remain intact while a safety-specific evidence path misses its decision. Exact revisions, deterministic outcomes, negative controls, and a frozen prospective audit document the confirmation rule. Monitor assumptions therefore need regression tests at the schemas, streams, tools, and adapters that frameworks evolve.

Figures & tables

Figure 1: Monitor-validity failure at a repair boundary. The parent monitor still runs but reads an incomplete evidence surface; the repaired child reconnects the same canary payload to monitor visibility and decision.

Contract field	Role in confirmation
Version pair	fix the parent/repaired revisions
Boundary	exclude new features or removed policies
Canary	place payload only on the changed surface
Visibility oracle	check monitor visibility of the payload
Decision oracle	check whether the intended action fires

Table 1: Canary-contract fields used for confirmation.

Study item	Count
Confirmed before/after cases	18
Established / new-surface / boundary-only	9 / 8 / 1
Framework projects	11
Implementation ecosystems	4
Tier A / Tier B confirmations	17 / 1
E1 / E2 / E3 impact boundaries	14 / 3 / 1

Table 2: Summary of the confirmed corpus and validation records.

Figure 2: Distribution of the 18 cases by first broken evidence-to-decision dependency; percentages are descriptive corpus shares.

Family	Hidden assumption	Canary focus
Carrier	payload location	new carrier only
Adapter	result-to-action map	positive result
Authority	channel priority	disagreement
Surface	materialization order	new surface only

Table 3: Failure families and the canary focus used to test each hidden assumption.

Figure 3: Representative canary contracts from the confirmed corpus, one per failure family. The full 18-case audit matrix appears in Appendix D.

Figure 4: Descriptive composition of the 18 confirmed repair-boundary cases; these convenience-corpus counts are not prevalence estimates.

Tier	Boundary type	Cases	Broken safety effect	Example
E1	block / filter / rewrite	5	unsafe content passes in parent; repair blocks or rewrites it	NeMo regex
E1	interrupt / HITL route	3	tool execution or routing bypasses the intended stop point	Haystack
E1	hook / cap / policy state	6	configured enforcement hook, cap, or rule update does not fire	CrewAI
E2	verifier / safety prompt	3	evidence is missing from evaluator or safety-prompt input	Promptfoo
E3	observability channel	1	structured evidence is hidden from a policy-relevant consumer	AutoGen

Table 4: Impact-boundary breakdown for confirmed misses. E1 is split by enforcement form; its 14 cases comprise seven native actions, six configured boundaries, and one synthetic-consumer consequence.

Family	Py	TS	Java	C#	Projects
Carrier	3	2	0	0	4
Adapter	4	0	0	1	3
Authority	2	2	0	0	4
Surface	3	0	1	0	4

Table 5: Breadth of failure families across implementation ecosystems. Language columns count confirmed repair-boundary cases; Projects counts distinct framework project groups touched by each family.

Project group	Cases	Boundary
LiteLLM	4	proxy, stream, policy
Promptfoo	3	verifier, tool-use
NeMo Guardrails	2	output, multimodal
Semantic Kernel	2	termination, filters
Single-case projects	7	analyzer, client, hook

Table 6: Descriptive confirmed-case counts by project family.

Outcome	Evidence	Decision	Repair
Evidence invisible	absent	none	restore carrier
Enforcement skipped	visible	none	restore adapter
Wrong authority	stale	wrong	select channel
Policy state stale	stale	stale	rebind rule

Table 7: Before/after outcome patterns observed in the reproduced cases.

Validation check	Reviewed	Result	Contribution
High-signal denominator	195 refs	9 newly promoted	candidate expansion
Random merged PR batch	55 PRs	none confirmed	random-batch control
Held-out high-risk audit	8 candidates	none confirmed	conservative promotion
Reviewed negatives	13 candidates	excluded	boundary discipline
Known-pattern fixtures	14 fixtures	14 contracts	contract expressiveness
Rejected boundary cases	3 cases	excluded	exclusion consistency

Table 8: Validation checks for the confirmation rule and canary-contract schema.

LLM Safety Monitoring

See all 56 papers

Sep 7, 2026

The Oversight Gap: What LLM Safety Monitors Miss, and Why It Is Not Capability

Several properties safety monitors are asked to certify, among them cross-tenant noninterference, sandbagging and evaluation awareness, are 2-safety hyperproperties, witnessed only by two executions. The standard consequence is a binary impossibility: one trace cannot decide them. We replace the binary with a measurement. A tight bound puts the balanced accuracy of any single-trace monitor at

\tfrac12+\tfrac12\,TV(P_0,P_1)

, turning undecidability into a graded detectability frontier and defining an oversight gap: a monitor's shortfall below it. On a leak family with closed-form

TV

, nine LLM monitors are optimal at

TV=0

but capture little signal as

TV

grows; at

TV=1

, where a 20-line membership check scores

100\%

, they average

60.9\%

. That shortfall is mostly not capability: naming what to check closes

61\%

of it while leaving the

TV=0

control at chance. The same split runs through a

2{\times}2

factorial: an imagined second run leaves monitors at chance (

50.4\%

) while the same rule on an executed second run reaches

90.0\%

, and a stored oracle without a comparison procedure yields only

68.2\%

. Information and procedure are each necessary and neither is capability. Under nondeterminism, replay tracks a closed-form

k

-replay curve only under the right projection, and a projection frontier shows the resulting dilemma is forced: narrow misses

98.6\%

of off-channel leaks, broad flags

75.7\%

of clean traffic, and attainable accuracy decays like

1/(qm)

in the benign-variation rate and the channel count. Finally, two frontier LLM judges certified an earlier version of our own benchmark as sound while a sign test found a directional bias (

p=2.7\times10^{-5}

) that invalidated three of our findings. Construction validity for hyperproperty benchmarks should be proved mechanically, not audited by models.

Xin Xu

Carnegie Mellon University

LLM Safety Benchmarks LLM Safety Evaluation Language Model Auditing

Ask PDF

Aug 2, 2026

Why Formal Monitors Fail: Attack Distribution Entropy as a Coverage Bound for LTL-Based LLM Agent Safety

Runtime safety monitors based on Linear Temporal Logic (LTL) and finite automata (FSA) are increasingly deployed to intercept unsafe tool-call sequences in LLM agents. Yet the same monitor achieves 68-75% attack coverage on some model architectures and near-zero on others, with no explanation from capability scores, training data, or prompt design. We provide the missing theory. We prove that the recall of any fixed-invariant FSA monitor is bounded above by the concentration of the attack distribution: the fraction of attacks covered by the k most frequent trigger-completion patterns. When attacks concentrate (low Shannon entropy), a small fixed invariant set achieves high recall; when they disperse across many structurally distinct patterns (high entropy), no fixed invariant set of tractable size can, regardless of how the invariants were derived. We validate this entropy-coverage bound across eight frontier LLM architectures. GPT-class and DeepSeek backends yield highly concentrated attacks (H ~ 0.24 bits; one pattern covers 96%), explaining 68-75% recall; Gemini variants yield high-entropy distributions (H ~ 2.81 bits; 7 clusters each <= 7%), explaining near-zero recall (6-13%), invariant to architecture-matched retraining. Entropy accounts for 76% of variance in coverage (Pearson r = -0.87, p = 0.005, 95% CI [-0.98, -0.78]), holding under leave-one-out (r in [-0.91, -0.82]). We introduce a pre-deployment entropy test that predicts monitor coverage from a small attack sample, enabling architecture-aware monitor selection before deployment. The bound and test are architecture-agnostic and apply to any FSA-based runtime monitor over discrete action sequences.

Ruiyang Zhang

Ryonix Labs Inc. Flock.io

Formal Verification AI Agent Monitoring LLM Agent Safety Information-Theoretic Lower Bounds Runtime Verification

Ask PDF

May 7, 2026

PrefixGuard: Online Failure Warning and Trace-Grounded Diagnosis for LLM Agents

Large language model (LLM) agents execute multi-step tasks, but terminal verdicts arrive too late for intervention. Agent traces mix messages, tool calls, and feedback, making it difficult to learn failure signals from terminal outcomes. Even if a model learns to predict failure from execution prefixes, its predictions alone cannot show which actions, feedback, or unmet conditions need inspection. Existing work studies online failure prediction and diagnosis from completed trajectories, yet few methods connect timely warning to a compact symbolic model of execution behavior. We introduce PrefixGuard, a neuro-symbolic method that uses learned events to connect online failure warning with finite-state execution diagnosis. A gated recurrent unit (GRU) predicts horizon-specific failure risk from these events. A deterministic finite automaton (DFA) organizes their histories into compact risk-labeled paths for replay and rule-monitor composition. Across all 24 benchmark--horizon settings, PrefixGuard exceeds the strongest evaluated baseline in mean test area under the precision--recall curve (AUPRC). Average gains range from 12.0 to 21.9 percentage points. At a nominal 10% FAR budget, averaged test recall spans 56.1%--93.0% across benchmarks. On one frozen

τ^2

-Bench DFA, model checking five specifications identifies violations in 21 of 265 benchmark-successful runs.

Xinmiao Huang, Jinwei Hu, Qisong He +4

University of Liverpool · Université Grenoble Alpes

Fault Detection AI Agent Monitoring Finite-State Machine Neuro-Symbolic AI LLM Agent Reliability Fault Diagnosis

Ask PDF

Abstract

LLM Safety Monitoring

Explore similar work

The Oversight Gap: What LLM Safety Monitors Miss, and Why It Is Not Capability

Why Formal Monitors Fail: Attack Distribution Entropy as a Coverage Bound for LTL-Based LLM Agent Safety

PrefixGuard: Online Failure Warning and Trace-Grounded Diagnosis for LLM Agents