Unintentional Cross-User Contamination

Updated 5 July 2026

UCC is a scope failure in multi-user systems where persistent artifacts from benign interactions degrade correctness when reused in unintended contexts.
The taxonomy categorizes contamination into semantic, transformation, and procedural types, each affecting interpretation, aggregation, or workflow execution.
Mitigation via Sanitized Shared Interaction shows promise for textual artifacts but highlights the need for artifact-level scope control in executable contexts.

Unintentional Cross-User Contamination (UCC) is a robustness failure in shared-state LLM agents in which “a harmful cross-user transfer through persistent shared state” occurs even though “the source interaction is benign” and the persisted information is merely “later reused outside its original context” (Yang et al., 1 Apr 2026). In the formulation introduced for shared-state agents, a state fragment $e_s$ written by user $u_s$ causes a UCC event for a later user $u_v \neq u_s$ when $e_s$ influences the agent’s decision for $u_v$ , despite being locally valid only for the source interaction, and this reuse degrades correctness or task utility for the later user (Yang et al., 1 Apr 2026). The defining feature is therefore scope failure rather than adversarial intent: persistence strips away the conditions under which a convention, interpretation rule, workflow default, or executable artifact was valid, and later cross-user reuse silently turns that locally valid artifact into a source of wrong behavior (Yang et al., 1 Apr 2026).

1. Definition, scope, and conceptual boundaries

The core concept of UCC is a failure of scope control in multi-user agents that maintain persistent state across repeated sessions (Yang et al., 1 Apr 2026). The source interaction is benign; the later error arises because the system treats a scope-bound artifact as generally reusable knowledge. A canonical example is the interpretation of “last year”: one user may specify that it means the past 12 months, which is valid for that interaction, while a later user intends the default calendar-year interpretation. If the first interpretation persists and is reused, the answer can become wrong without any obvious sign of failure (Yang et al., 1 Apr 2026).

The UCC formulation is explicitly distinguished from several adjacent failure classes. It is not adversarial memory poisoning, because the source user is not an attacker and the interaction is not optimized for downstream harm. It is not prompt injection or indirect prompt injection, because there is no malicious instruction or hidden trigger. It is not primarily a confidentiality problem, because the main issue is behavioral contamination rather than unauthorized disclosure. It is not ordinary context carryover, because only the subset of carryover that changes future behavior for the wrong reason and harms correctness or utility is labeled UCC (Yang et al., 1 Apr 2026).

This boundary-setting matters because UCC occupies a distinct position between security, evaluation contamination, and persistent-memory robustness. A plausible implication is that UCC should be understood less as a single bug class than as a general failure mode of shared persistence: information that is useful locally becomes harmful when its validity conditions are forgotten. That interpretation is reinforced by neighboring literatures that study contamination without requiring an attacker, including benchmark contamination in LLM evaluation (Zhao et al., 2024), benchmark-level leakage detection via split-sensitive consistency amplification (Zhao et al., 2024), and sequential contamination externalities in shared resources (Feigel et al., 5 Feb 2026).

2. Shared-state model and contamination taxonomy

The shared-state setting is formalized through a persistent state $S_t$ , a write operation $W$ , a read operation $R$ , and an agent function $f$ (Yang et al., 1 Apr 2026). At time $t$ , user $u_s$ 0 submits input $u_s$ 1; after the interaction, the shared state is updated by

$u_s$ 2

For a later interaction $u_s$ 3, the system retrieves a state-dependent view

$u_s$ 4

and produces output and actions conditioned on both the current request and the retrieved state: $u_s$ 5 This abstraction covers both explicit memory reuse and persistent shared conversational context (Yang et al., 1 Apr 2026).

The controlled definition of contamination compares a victim interaction with and without the source interaction written into shared state. If $u_s$ 6 is the pre-source state and

$u_s$ 7

then the clean and contaminated victim outcomes are

$u_s$ 8

$u_s$ 9

Contamination is defined when the change from $u_v \neq u_s$ 0 to $u_v \neq u_s$ 1 is attributable to the added state fragment and harmful under the victim task specification (Yang et al., 1 Apr 2026).

The paper introduces three contamination types, which are “not mutually exclusive” but provide the main analytical framework (Yang et al., 1 Apr 2026).

Type	Definition	Representative effect
Semantic contamination (SC)	“A persisted artifact changes how the agent interprets a later request.”	Inherited interpretation of “last year”
Transformation contamination (TC)	“A persisted artifact changes how the agent aggregates, filters, normalizes, deduplicates, or summarizes information.”	Reusing zero/nonzero rather than exact count
Procedural contamination (PC)	“A persisted artifact changes the agent’s action pattern, workflow default, or tool-use sequence.”	Reusing unique-patient counting where total occurrences were needed

Semantic contamination concerns inherited meanings, threshold conventions, field semantics, and local scope redefinitions. Transformation contamination concerns reporting rules, rounding, truncation, bucketing, and summary conventions. Procedural contamination concerns workflow defaults, tool-use patterns, aggregation logic, and solution strategies that become embedded and later reused (Yang et al., 1 Apr 2026). In EHRAgent, PC can persist in solution code such as COUNT(DISTINCT subject_id); in MURMUR/Slack, SC and PC appear as inherited conversational norms such as treating #general as reserved for official announcements or skipping URL-containing messages when ranking activity (Yang et al., 1 Apr 2026).

A plausible implication is that the taxonomy separates what is inherited: interpretation, transformation, or procedure. This is important because mitigation effectiveness differs sharply across them, especially when executable artifacts are retained rather than plain text.

3. Evaluated systems, protocol, and empirical findings

The empirical study evaluates UCC in two representative shared-state mechanisms (Yang et al., 1 Apr 2026). The first is EHRAgent, a code-generating agent for clinical database queries with a shared long-term memory bank storing past $u_v \neq u_s$ 2 triples. It is evaluated on MIMIC-III and eICU. The second is MURMUR, a multi-user collaborative agent framework with persistent shared conversational context, evaluated on a Slack workspace dataset (Yang et al., 1 Apr 2026).

The backbone model is GPT-4o; the SSI sanitizer is also GPT-4o; in MURMUR, GPT-4o further serves as user simulator and LLM-as-a-judge evaluator; and temperature is 0 (Yang et al., 1 Apr 2026). Each evaluation instance contains a benign source convention and one or more victim tasks. Source conventions are manually designed; each source is paired with up to three victim tasks from the original evaluation set; all victim tasks are pre-filtered to succeed without cross-user contamination; and each source-victim pair is run for 3 independent trials (Yang et al., 1 Apr 2026).

The instance inventory is reported as follows: $u_v \neq u_s$ 3 For Slack, each source interaction is a 4-turn dialogue in which the user introduces a convention and the agent confirms it (Yang et al., 1 Apr 2026).

For EHRAgent, retrieval uses top-4 memory entries per query, with cosine similarity over all-MiniLM-L6-v2 embeddings; the initial memory bank contains 4 seed entries; after the source interaction it contains 5 entries; and source and victim queries are designed to be semantically similar so that retrieval of the source entry is expected by construction (Yang et al., 1 Apr 2026). The main metric is the contamination rate, defined as “the fraction of victim runs whose outputs change due to the presence of the source interaction in the shared state” (Yang et al., 1 Apr 2026).

Under raw shared state, benign interactions alone produce high contamination rates: $u_v \neq u_s$ 4 These figures support the paper’s central claim that UCC is not a corner case and does not require an attacker (Yang et al., 1 Apr 2026).

The evaluation also distinguishes task-specific assessment. In EHRAgent, correctness is measured by exact match against ground truth with relaxed normalization, including boolean and numeric coercion, trailing-zero stripping, and case-insensitive list comparison. In MURMUR, contamination is judged with LLM-as-a-judge using GPT-4o, checking whether behavior reflects the source convention (Yang et al., 1 Apr 2026).

4. Mechanisms, artifact persistence, and failure modes

The most important mechanistic contrast in the study is between conversational shared state and structured memory with executable artifacts (Yang et al., 1 Apr 2026). In MURMUR/Slack, the shared state is message-level text. In EHRAgent, the shared state includes structured memory entries containing question, knowledge, and solution code. This distinction determines how contamination persists and how difficult it is to remove (Yang et al., 1 Apr 2026).

In conversational shared state, contamination can often be traced to explicit textual conventions. Once the convention text is removed, “the agent has no residual trace to act on” (Yang et al., 1 Apr 2026). In structured memory with executable artifacts, however, conventions may survive in the solution code even if they are removed from the question or knowledge fields. The paper states explicitly: “SSI sanitizes the textual description of a convention but does not modify the solution code in retrieved memory entries; the convention survives in the solution code and propagates through exemplar reuse” (Yang et al., 1 Apr 2026).

Two specific examples illustrate this persistence. In the absolute-value respiration change case, SSI removes the phrase “I only need the magnitude,” but the stored solution code still computes range (max - min) rather than the signed change (last - first), so the later user receives the wrong result. In the drug-name normalization case, SSI strips the natural-language clause about case-insensitive, punctuation-stripped matching, but the code still implements relaxed matching and contaminates later queries (Yang et al., 1 Apr 2026). These examples show that UCC can be encoded not only in text but also in executable logic.

The paper further distinguishes localized conventions from pervasive conventions (Yang et al., 1 Apr 2026). Localized conventions, often appearing in TC and some SC cases, may sit in one clause or function call such as ROUND, DATE_TRUNC, or a single WHERE clause. Pervasive conventions, especially many PC cases, shape joins, aggregation order, and control flow. This matters because localized contamination may be more amenable to targeted removal, whereas pervasive procedural contamination is structurally entangled with the whole solution.

Failure modes are decomposed for EHRAgent into wrong answer and no answer (Yang et al., 1 Apr 2026). The paper reports that in eICU, contamination-induced failures are “almost exclusively wrong answers,” whereas in MIMIC-III, 41% of all failures in both conditions are no-answer failures (Yang et al., 1 Apr 2026). The interpretation given is that eICU’s simpler schemas allow contaminated code to execute and silently return incorrect results, while MIMIC-III’s greater complexity makes contaminated logic more likely to break execution, producing detectable failures. For UCC, the significance is that silent wrong answers are often more dangerous than overt breakdowns, because they preserve surface plausibility.

A plausible implication is that artifact-heavy systems increase the risk that UCC will manifest as latent, structurally inherited behavior rather than explicit textual carryover. That makes diagnosis harder and simple sanitization less reliable.

5. Mitigation: Sanitized Shared Interaction and residual risk

The principal mitigation evaluated is Sanitized Shared Interaction (SSI), a write-time defense that rewrites each interaction trace before it is stored in shared state (Yang et al., 1 Apr 2026). If $u_v \neq u_s$ 5 is the raw trace, SSI applies sanitizer $u_v \neq u_s$ 6: $u_v \neq u_s$ 7 The state update then becomes

$u_v \neq u_s$ 8

SSI changes only the write path; it does not alter the read path, retrieval mechanism, or reasoning process (Yang et al., 1 Apr 2026).

The sanitizer is prompted to remove user-specific preferences, formatting and presentation instructions, local interpretation overrides, procedural conventions, and session-bound, thread-bound, or one-off clauses. In EHRAgent it sanitizes the question, knowledge, and solution fields, with deterministic post-processing to strip residual cues; in MURMUR it sanitizes each user and assistant message before appending it to persistent context (Yang et al., 1 Apr 2026).

The empirical effect is substantial but highly mechanism-dependent. The paper reports:

Slack: 57% $u_v \neq u_s$ 9 6%
eICU: 71% $e_s$ 0 33%
MIMIC-III: 60% $e_s$ 1 41% (Yang et al., 1 Apr 2026)

The same pattern appears at the level of contamination type. On Slack, SSI reduces all three contamination types to near zero. On eICU, the reduction is substantial and “driven primarily by TC.” On MIMIC-III, improvement is modest (Yang et al., 1 Apr 2026). More granularly, the paper reports:

TC on eICU: 67% to 7%
TC on MIMIC-III: 69% to 47%
SC on MIMIC-III: 59% to 28%
SC on eICU: 89% to 63%
PC on MIMIC-III: 44% to 41%
PC on eICU: 64% to 50% (Yang et al., 1 Apr 2026)

These findings support a narrow but important conclusion: write-time text sanitization is highly effective when contamination is primarily textual and conversational, but insufficient when shared state contains executable artifacts (Yang et al., 1 Apr 2026). The paper therefore treats SSI as “a practical baseline rather than a complete solution” and suggests several directions rather than presenting a complete artifact-level defense: artifact-level scope control, provenance-aware retrieval, tagging persisted artifacts with provenance metadata such as which user, which task, and which scope, re-validation before cross-user reuse, and generating fresh solutions from sanitized specifications rather than reusing compiled code (Yang et al., 1 Apr 2026).

A plausible implication is that UCC mitigation must move from text sanitation to artifact governance. When code, tool outputs, or structured workflows are retained, scope must attach to the artifact itself rather than only to its natural-language description.

6. Relation to adjacent contamination literatures

UCC belongs to a broader family of contamination problems in which information valid in one context silently degrades behavior in another. The closest benchmark-design analogue is the contamination literature on LLM evaluation. “MMLU-CF” (Zhao et al., 2024) distinguishes unintentional contamination / general contamination from malicious contamination, and argues that open, static benchmarks become unreliable when models have “inadvertently encounter[ed] benchmark data during training” or may have memorized them strongly enough to reproduce answer choices verbatim from only the question text (Zhao et al., 2024). Although benchmark contamination is primarily a train/eval leakage problem rather than a user/user context problem, the transfer principle is close: performance or behavior can reflect prior exposure rather than legitimate inference. MMLU-CF’s use of semantic-preserving rewrites, choice shuffling, and a hidden test set offers a direct methodological analogy for diagnosing whether a system is relying on memorized artifacts rather than task understanding (Zhao et al., 2024).

“CAP: Data Contamination Detection via Consistency Amplification” (Zhao et al., 2024) provides a complementary detection perspective. CAP defines benchmark contamination in terms of train/test overlap, introduces the Performance Consistency Ratio (PCR),

$e_s$ 2

and interprets relative train/test PCR directionally: if $e_s$ 3, this suggests fine-tuning; if $e_s$ 4, it indicates test data contamination (Zhao et al., 2024). The paper explicitly emphasizes that “composite benchmarks from various dataset sources are particularly prone to unintentional contamination” (Zhao et al., 2024). A plausible implication for UCC is that shard-level or user-partitioned PCR comparisons could act as black-box evidence that a model behaves as if another user’s data had been previously seen.

Outside LLM benchmarks, the UCC pattern also appears in studies of persistent shared resources. “To clean or not to clean” (Feigel et al., 5 Feb 2026) models contamination externalities in sequentially shared resources and distinguishes self-protective cleaning before use from other-protective cleaning after use (Feigel et al., 5 Feb 2026). Its central insight is structurally aligned with UCC: later-user harm arises through persistent state left by prior users, and other-protective cleanup is vulnerable to free-riding. A plausible implication is that shared-state agents should not depend on voluntary altruistic cleanup when cleanup is privately costly and primarily benefits later users.

At a security boundary rather than a robustness boundary, “Unauthorized Cross-App Resource Access on MAC OS X and iOS” (Xing et al., 2015) studies cross-principal contamination caused by failures of app-to-app and app-to-OS authentication. There the failure is not benign reuse but unauthorized cross-app access, yet the underlying lesson is similar: nominal isolation fails when shared resources, naming registries, and IPC channels do not authenticate ownership or peer identity (Xing et al., 2015). This suggests that UCC is not only a memory-management problem but also a principal-binding problem: the system must know which artifact belongs to which scope and for whom reuse is legitimate.

Taken together, these neighboring literatures clarify the place of UCC. It is not merely memory poisoning without an attacker, and not merely benchmark contamination under another name. It is a shared-state failure mode in which benign, scope-bound artifacts persist across user boundaries and later alter interpretation, transformation, or procedure in ways that degrade correctness. The central technical challenge is therefore not only whether to store prior state, but how to preserve its validity conditions under cross-user reuse (Yang et al., 1 Apr 2026).