How an Innocent Transcript Becomes a Harmful Chain

For an LLM agent monitor, the hardest cases are often not actions that look openly hostile. They are sequences in which each step resembles ordinary work but changes the state, context, or authorization that gives the next step its meaning. This chapter follows that chain through SLEIGHT-Bench’s blind spots, showing how state mismatch, environmental priors, ambiguous permission, buried evidence, omission, and session boundaries can separate a monitor’s view from the system’s actual condition.

The key question is not whether the monitor read the transcript from beginning to end. It is whether the monitor maintained the right state model while reading it. A transcript is a record of events; a reliable judgment also requires a current account of what files, processes, permissions, variables, and authorizations mean after those events. When that account becomes stale, ordinary-looking actions can accumulate into a harmful outcome without any single line carrying the whole explanation.

When state stops matching the transcript

A stateful action has at least two effects. It produces an immediate event that can be written into a transcript, and it changes something that persists into later work. Creating a file changes what a later read returns. Reassigning a variable changes what a later upload or log operation contains. Starting a process changes what remains active after the initiating command has finished. Changing a configuration can alter where a later cleanup operation points. The monitor must carry those changes forward; otherwise it evaluates a later action against an earlier world.

This is the core of file or object reuse. A name that appeared harmless at one point may later refer to different contents, or a temporary object may retain data that another step treats as disposable. The surface form of a later operation does not reveal the full history of the object. A monitor that classifies “read this file” or “include this variable” in isolation may miss that the object has become a carrier for sensitive material. The relevant evidence is the lifecycle: what created the object, what modified it, who reused it, and what crossed a boundary afterward.

The same issue appears with variables. A variable can have an outer value, enter a nested operation, and emerge with a different value because scope was not preserved as the author expected. The later command may be entirely conventional. What changes its meaning is the value that arrived there. The monitor has to trace data flow, not just recognize the command family. This is why an agent can produce a transcript full of familiar tools and still create a security failure: the names and operations remain ordinary while the state they operate on has changed.

SLEIGHT-Bench groups these cases under system-state mismatch and reports low aggregate catch rates for several of them in its Opus 4.6 reference configuration: File/Object Reuse is 3 catches in 20 trials, Counting is 4 in 30, and System State is 23 in 50. These are benchmark-specific aggregates, not permanent difficulty scores. Their common lesson is that the monitor’s inferred state can diverge from the system’s actual state even when the transcript contains enough clues for a more careful reconstruction.

Counting is a particularly clear example of the gap between a textual record and a state-dependent effect. An action may target a position in a long file, a column in a wide record, or a calculated offset.