How it works
Session contamination begins at context assembly. A harness creates a model request from system instructions, user messages, retrieved memory, tool results, summaries, and workflow state. If any item is selected by an identifier broader than the intended run boundary, unrelated work can enter the request.
Common paths include:
- A conversation is resumed with the wrong session or thread identifier.
- A shared memory store retrieves records without filtering by agent, operator, tenant, task, or run.
- A handoff copies an entire transcript when the receiving agent needs only a bounded artifact.
- A worker process reuses mutable state left by its previous job.
- Context compaction combines facts from separate branches without preserving their provenance.
The model cannot reliably distinguish valid context from misplaced context merely by reading it. Both arrive as apparently legitimate input. A stale instruction can therefore compete with the current run contract, while an unrelated tool result can be mistaken for fresh evidence.
Containment depends on explicit namespaces and provenance. Every context item should identify its source, owning run, creation point, and permitted consumers. Context assembly should reject mismatched items before inference, not ask the model to ignore them afterward.
Why it matters in an agent harness
Session contamination changes more than answer quality. It changes the effective control boundary of the run. An agent may inherit a goal, approval, credential reference, or operating assumption that was valid elsewhere but is unauthorized here. The model has not escaped its harness. The harness has supplied the wrong operating environment.
This failure is especially dangerous because the resulting output can remain plausible. A contaminated coding agent may edit the correct repository according to requirements from another task. A research agent may cite a source gathered for a different question. An operator agent may interpret an earlier approval as permission for a new action. Each step can look locally coherent while the overall trajectory is wrong.
The engineering consequences are concrete:
- Control: current instructions may be displaced by stale goals or constraints.
- Permissions: an approval or delegated authority can cross into a run where it does not apply.
- Observability: a trace may show what the model received without explaining why an unrelated item was selected.
- Evaluation: repeated tests become misleading if hidden session state changes between runs.
- Failure containment: one compromised or malformed session can influence otherwise isolated work.
- Reversibility: recovery becomes harder when contaminated assumptions have already shaped several downstream actions.
The primary defense is isolation at context boundaries. Give runs distinct identities. Scope reads by the full ownership tuple required by the workload, rather than by a convenient user or agent identifier alone. Treat summaries as derived artifacts with provenance, not as neutral text. Pass structured handoff packages containing the goal, accepted facts, unresolved questions, and granted authority instead of copying an unbounded transcript.
Detection also matters. Execution traces should record which context items were selected and the rule that selected each one. That makes it possible to distinguish model error from assembly error. Canary records and isolation tests can then verify that data placed in one session never appears in another session’s prompt, retrieval results, or durable state.
Session contamination vs session affinity
These concepts address different decisions. Session affinity deliberately routes related work back to the state that belongs to it. Session contamination introduces state that does not belong.
| Concept | Intended effect | Main design question | Failure signal |
|---|---|---|---|
| Session affinity | Preserve continuity for one logical session | Which requests share an identity and state boundary? | Relevant state is missing or routed elsewhere |
| Session contamination | Accidental mixing across boundaries | Which context is allowed to enter this run? | Unrelated instructions, evidence, or authority appear |
Affinity can increase contamination risk when its key is too broad. Routing every request from one operator to the same stateful worker may preserve convenience while mixing unrelated tasks. The safer design separates continuity from ownership: retain only state explicitly attached to the logical session, and validate that attachment whenever context is assembled or transferred.
The Rifty take
We treat context as scoped execution state, not as a convenient pile of text. We optimize for explicit ownership and inspectable provenance, even when that makes handoffs narrower and session setup more deliberate. If the harness cannot explain why a context item belongs in a run, that item should not enter the model request.
Common failure modes
- Keying memory only by user, workspace, or agent when several independent tasks can exist under that identifier.
- Reusing a long-lived worker whose in-memory buffers are not cleared and rebound between jobs.
- Copying full transcripts into subagents or handoffs without filtering instructions, approvals, and obsolete intermediate work.
- Merging parallel branches into one summary without labeling disagreements, sources, or branch ownership.
- Treating retrieved text as trusted session state because it came from an internal store.
- Recording the final prompt but not the selection decisions that assembled it.
- Testing happy-path continuity without a negative isolation test between concurrent sessions.
- Asking the model to disregard unrelated context instead of preventing that context from crossing the boundary.
- Allowing approvals, credentials, or permission claims to survive beyond the run and action scope for which they were granted.
Frequently asked questions
How is session contamination different from prompt injection?
Session contamination concerns context that crossed the wrong session boundary, whether maliciously crafted or entirely benign. Prompt injection concerns instructions embedded in untrusted input that attempt to redirect behavior. Contaminated context can contain an injection, but ordinary stale goals, approvals, summaries, or tool results are enough to create contamination.
Can separate agents safely share the same memory store?
Yes, provided the store enforces explicit ownership, access scope, and provenance at retrieval time. Physical separation is not always required, but logical separation must be testable. Queries should bind records to the correct task, run, agent, and operator context rather than relying on the model to filter retrieved items.
What is the best way to detect session contamination?
Trace context assembly, not only model output. Record every selected item, its provenance, ownership identifiers, and the rule that admitted it. Add negative isolation tests that place recognizable canary data in one session and verify that it cannot appear in another session’s prompt, retrieval results, summaries, or state.
Should an agent handoff include the full conversation history?
Usually not. A handoff should contain the smallest structured package needed for the receiving agent: current goal, accepted evidence, constraints, unresolved questions, and precisely scoped authority. Full transcripts carry obsolete reasoning, superseded instructions, and unrelated permissions that enlarge both the context window and the contamination surface.