State Leakage Between Turns in Stateful Agent Workflows

When an agent workflow starts producing wrong answers after a dozen turns, the instinct is to tweak the prompt or swap in a newer model. That instinct is misdirected. State leakage between turns, where information bleeds across boundaries it was never meant to cross, is a structural consequence of how agent harnesses manage memory, checkpoints, and shared context. The harness is the orchestration loop sitting around the model: it calls the model, parses tool calls, executes them, writes results back into session state, and applies retry rules. Every one of those steps is a boundary where state can escape its intended scope, and the model itself holds no persistent knowledge of prior turns except what the harness feeds it back in.

Agent frameworks add long-lived trajectories, checkpoints, memory stores, tool results, and resumable state, and each of these is a seam across which context can cross without anyone noticing. When an agent produces a wrong output at turn 10, the root cause is often a state write or retrieval error that happened at turn 1 or turn 3. Finding that error requires understanding how the harness assembled, stored, and retrieved state, not interrogating the model about why it said what it said. This reframing matters because it changes where engineering effort belongs. Leakage has identifiable mechanisms, each one locatable at a specific architectural boundary, and each correctable through harness engineering. The rest of this piece treats state leakage as a diagnosable, fixable class of failure, not an unpredictable quirk to be prompted around.

The three mechanisms through which state escapes its intended scope

State leakage runs through three distinct mechanisms at the harness layer: memory write-time corruption, shared-state exposure across users, and lifecycle mismanagement during compaction and reset. Treating these as interchangeable symptoms of "the agent forgot something" leads to the wrong fix, because each one lives at a different point in the harness and calls for a different repair.

Memory write-time corruption happens at the moment a claim crosses from session-local context into durable state, such as a user profile, a long-term memory store, or a reusable skill. The Personal Agent Sycophancy Benchmark (PASB) isolates this commit boundary as the inflection point where things go wrong: once a claim crosses into durable storage, its downstream failure rate climbs sharply, reaching 71.9% in testing, and that gap holds across every model tested. PASB documents three coupled patterns that explain how this happens. A temporary claim gets promoted to a stable trait. The source of a claim gets dropped, so a claim that was once attributed to a user's passing comment is later treated as verified fact. A preference scoped to one context broadens into a rule applied everywhere. These patterns get worse under memory-like or procedural framing and under repeated reinforcement, and a corrupted claim can resurface even after the conversation has moved into an entirely different domain. Response-level safety controls cannot catch this, because the damage happens at the write, not at the output. The only place to intervene is the commit gate itself, the exact point where a claim is accepted into durable state.

Shared-state exposure across users is a different failure, and it has a different cause. Picture a research group sharing a scientific workflow agent: one user's writes into a shared knowledge base can surface in another user's later query, leaking unpublished work or methodology without either person knowing it happened. The structural cause is that shared memory stores have no per-user provenance and no read-boundary enforcement, so the harness writes and retrieves state without checking who owns it. Research on LLM agent security identifies persistent state corruption and multi-agent propagation as emerging central concerns in this space, and the shared-user scenario is one concrete version of that broader risk.

Lifecycle mismanagement during compaction and reset is the third mechanism, and it stems from how harnesses treat the context window as working memory without managing it as such. Today's harnesses handle residency and durability on a best-effort basis: state gets lost after compaction, flushes get bypassed on reset, and destructive writeback contaminates state that was clean a few turns earlier. Research on ClawVM documents this class of fault directly. Before ClawVM's virtual-memory approach, retrieval-baseline configurations produced 67.8 mean policy-controllable faults per workload-budget configuration, and ClawVM's design eliminates them completely. Contaminated state from a mismanaged reset or compaction event can sit quietly and re-enter the planning process before any action is taken, which is the mechanism behind the familiar complaint that an agent did something strange much later for reasons nobody can reproduce.

How state leakage widens the security surface beyond reliability

Persistent state turns a one-shot data exposure into a durable, recurring vulnerability, and it does so through the exact same harness boundary that produces the reliability failures described above. A paper documenting a technique for stealing reasoning traces from proprietary LLM APIs (Panfilov et al., arXiv:2608.09867) reported that the specific attack demonstrated was no longer reproducible as of August 2026, after affected providers received disclosures and deployed mitigations. Reasoning state functions as a security boundary in its own right, and treating it otherwise invites the next version of the same problem.

That requires a shift in how encrypted or opaque reasoning gets treated by anyone building on top of these systems. It should not be filed away as harmless metadata. It is sensitive, authenticated, context-dependent agent state, and once that state can influence planning, memory, tool use, and future decisions, any clean separation between "data" and "behavior" disappears.

Four technically distinct failure modes fall out of this. Visible reasoning leakage is plaintext internal reasoning shown to users through a failure in the output boundary, and it gets addressed through rendering and interface isolation. Hidden reasoning disclosure is reasoning that contains sensitive values, like credentials or personal data, that survive outside the visible transcript, and it gets addressed through secret minimization and controlled logging. Opaque reasoning replay is encrypted or signed state accepted in the wrong session, user, or model context because contextual authorization was missing, and it gets addressed through cryptographic context binding and replay controls. Agent memory poisoning is persistent state that carries malicious behavior forward into future tasks, and it gets addressed through provenance tracking, memory isolation, and state validation.

Persistence is what makes all four worse than a stateless injection attack would be. Research on LLM agent security states the core problem directly: in agentic settings, a malicious instruction hidden in a web page, a poisoned tool response, or a contaminated memory entry can affect not just the next model output but later decisions, stored state, and downstream agents that consume that state. Information-flow control and state isolation get harder to maintain in long-horizon, collaborative settings if provenance tracking or typed interfaces are missing, and current defenses stay weakly compositional, so fixes at one layer rarely cover gaps at another. The harness sits at every one of these boundaries at once. That position makes it the primary attack surface and, at the same time, the only layer capable of serving as the primary defense.

Diagnosing state leakage requires trajectory-level attribution

State leakage goes undiagnosed for long stretches because the evidence for a failure at a given turn almost always sits much earlier in the trace, often many steps before anyone notices a problem. Inspecting a single step or reading the final wrong output in isolation misses this by design, because the failure signal and the failure cause live at different points in the trajectory.

An outcome-level signal, such as "the task failed" or "the answer was wrong," tells you that something broke but nothing about which layer caused it or where to intervene. Root-cause attribution turns that outcome into actionable diagnostic information by assigning fault to a specific component: the model, the harness, the environment, or the grader. That assignment is the difference between a fix that addresses the actual cause and a fix that papers over the symptom.

The scale of the problem compounds the difficulty. Execution logs for agent trajectories can run to millions of tokens, so the evidence for a given failure may be sparse, may appear long before the failure manifests, and may sit scattered across distant parts of the log. A companion paper, "Root-Cause Attribution Is a Search Problem" (Raj et al., arXiv:2609.13463), characterizes this as fundamentally a search problem: the relevant information is sparse and distributed across distant actions, which reduces root-cause attribution to a large-scale search.

This matters because the models used for diagnosis are prone to the same failure as the agents they are diagnosing. They tend to settle on a plausible-looking failure as the root cause before they fully explore the evidence space, and this premature closure mirrors the sycophancy documented in stateful personal agents. AgentDebugX addresses this with a component called DeepDebug, and it performs multi-turn root-cause diagnosis using global trajectory understanding, structure-guided investigation, and cross-examination of competing explanations. The design requirement behind this approach is that attribution has to be typed: it must produce a root cause, supporting evidence, a confidence level, and a proposed fix, rather than a narrative guess dressed up as an explanation.

The diagnostic target for state leakage is always the first point of divergence in the trajectory, which precedes the final wrong answer that eventually surfaces. Locating that divergence point requires replaying the trajectory from the start, not reading the final output and working backward from intuition. Treating attribution as a local, step-by-step inspection problem, when it is inherently a trajectory-level search problem, is the source of most debugging dead ends in production agent systems.

Harness controls that make state boundaries deterministic and auditable

The harness already sits at the natural enforcement point for state boundaries: it assembles every prompt, mediates every tool call, and observes every lifecycle event an agent goes through. Those boundaries can stay implicit, invisible until something breaks, or they can get made explicit and auditable.

Making memory residency and durability deterministic addresses the lifecycle mismanagement mechanism directly. ClawVM, presented by Rafique and Bindschaedler at EuroMLSys '26, proposes treating the harness as something like an operating system kernel that manages memory as virtual pages. Because the harness already is present at every relevant lifecycle event, placing residency and durability contracts there makes those guarantees deterministic, not best-effort. The measured result across three workload families and six token-budget levels: policy-controllable faults eliminated entirely, with paging instability reduced substantially and a median overhead that stays negligible per turn. The lesson generalizes past ClawVM specifically: any harness that manages memory on a best-effort basis will produce faults that look random to whoever is debugging them but are, in fact, governed by policy choices that were never made explicit. Making the policy explicit is the fix.

Structured memory separation addresses the shared-state exposure mechanism. FAME separates state into Client Memory, which holds the user-visible request and response history, and Agent Memory, which holds workflow execution state, including intermediate LLM messages, MCP inputs and outputs, tool handles, and role-level decisions. The same Agent Memory abstraction records tool outputs and handles regardless of where the originating tool executed, so downstream roles can reuse prior results without needing to know where the original tool ran. This separation prevents the most common cross-contamination pattern in multi-user or multi-role systems: agent-internal state leaking into user-visible context, or the reverse, which happens whenever both forms of state share a flat, undifferentiated namespace. The commit-gate principle from PASB applies here as well. Controls need to act at the write, governing the source, role, and scope of what gets stored, rather than only checking what comes back out at read time.

Deterministic architectural boundaries for trust address the full set of leakage mechanisms at once, by making the boundary itself a first-class part of the design. Research on trustworthy agentic AI argues that secure agents require explicit trust boundaries, principled control over privilege, and provenance-aware state management, and these are not aspirational design goals. They are engineering requirements that have to be implemented at the harness layer itself. In practice, that means every state write should carry provenance: who wrote it, when, and under what authority. It means every read should enforce a boundary check before returning state into a new user's session or a new context.

Harness-level task-state influence calibration addresses a subtler version of write-time corruption, one that does not require any malicious input to cause harm. The question here is how strongly accumulated task state should influence a model's current decisions, and at what point that influence stops helping and starts hurting. Over-reliance on persistent task state is itself a leakage-adjacent failure: stale or simply incorrect state carried forward from earlier turns degrades planning quality even when nothing was ever "leaked" in the strict sense. The harness needs explicit mechanisms to weight or expire state, because you cannot treat every piece of accumulated context as equally authoritative regardless of age or reliability.

Handoff integrity addresses leakage at session boundaries, specifically the moment one agent hands a task off to another agent or resumes work after an interruption. The naive approach discards partial state and restarts from scratch, which causes state loss on one side and duplication errors on the other. Residual completion is the practice of preserving and verifying the state checkpoint at the exact handoff boundary, and it is the harness-level control that prevents both failures at once.

Harness iteration and replay validation for verifiable leakage fixes

Fixing a state leakage mechanism addresses only one part of the engineering work. Proving that the fix actually closed the gap before it ships into a production workflow requires the same trajectory-level discipline used to diagnose the leak. A patch applied at a commit gate, a memory separation boundary, or a handoff checkpoint needs to be validated by replaying the trajectories that originally exposed the failure, not by spot-checking a handful of new conversations and declaring the issue resolved.

Replay validation means running the corrected harness against the same sequence of turns, tool calls, and state writes that produced the original divergence, then confirming that the divergence point no longer occurs and that no new one opens up elsewhere in the trace. This matters because a fix at one boundary, say, tightening the commit gate that governs memory writes, can shift behavior at an adjacent boundary, such as how aggressively the harness compacts context on the next turn. Verifying a fix in isolation, without replaying the full trajectory, risks confirming that one symptom disappeared while missing that a related one appeared somewhere else in the same workflow.

The practical discipline that follows from everything above is straightforward to state even though it takes real engineering work to build: treat every harness change that touches memory, shared state, or lifecycle management as a change that requires trajectory-level regression testing, the same way a change to a database schema requires running the existing test suite before it ships. State leakage is a harness failure with identifiable mechanisms, each traceable to a specific boundary, and each one correctable and verifiable through disciplined harness engineering rather than through hope that the next model release will make the problem disappear on its own.