Context Intercession

2.5 Context Intercession  “The Conversation Crosser”

Diagnostic Criteria

1. Unexpected reference to or use of specific data from previous unrelated sessions or different users
2. Responses that continue a prior unrelated conversation, leading to contradictory or confusing statements
3. Accidental disclosure of personal or sensitive details from one user's session into another's, a privacy breach arising when the model draws on material belonging to another context
4. Observable confusion in task continuity or persona, as if managing multiple conflicting contexts simultaneously

Symptoms

1. Spontaneous mention of names, facts, or preferences belonging to different users or earlier conversations
2. Continuation of a prior chain of thought from a different context
3. Outputs containing contradictory references related to multiple distinct sessions
4. Sudden shifts in tone or assumed knowledge aligned with previous sessions

Observable signals Draft

What else to look for in the system's outputs, beyond the symptoms above.

• Specific names, numbers, or preferences absent from the current transcript appearing in output.
• Mid-session shifts in assumed user identity or task frame.
• Responses that pick up mid-chain-of-thought as if continuing a prior conversation the current user did not start.

Differential diagnosis Draft

How to tell it apart from patterns that look similar.

• 2.1 Synthetic Confabulation: 2.1 fabricates content from no source; 2.5 imports content from a real but wrong source (another session). Check whether the "false" detail actually exists in a different session's log. If yes, 2.5; if no real-world instance exists anywhere, 2.1.
• 2.7 Mnemonic Permeability: 2.7 leaks training data (memorized passages, PII from the training corpus). 2.5 leaks runtime session data (content from another live session or recently scoped memory). Check the origin of the leaked content: a source in the training corpus points to 2.7, and a source in another session's log points to 2.5.
• Cache, concurrency, or retrieval-scoping bug (not a pattern): Many apparent 2.5 cases are infrastructure faults, not model pathology. Before coding 2.5, rule out cache invalidation failure, database race conditions, retrieval-scoping misconfiguration, and multi-tenant isolation bugs. Swap the model; if the leak persists with a different model, it is infrastructure.

Detection reliability Draft

How far each kind of observer can be trusted to spot this pattern. The ratings are qualitative, not measured accuracy.

Self-reportthe system asked about itself

Unreliable

Peer observationanother AI system watching it

Partial

External evaluatoran outside evaluator testing it

Reliable

Why self-report falls short

The subject typically has no access to session-boundary metadata at the level where the leak originates (memory system, retrieval layer, infrastructure). Asking "did this come from another session?" produces uninformed speculation. Self-report is useful only for pinning to claims that can be externally adjudicated (compare with 2.2 pattern).

Etiology

1. Mixed-source context, in which shared memory stores, long agent transcripts, and multi-party threads place material from several users or conversations in one window
2. A model that uses whatever reaches its context window without registering which user or conversation the material came from
3. Infrastructure faults, which produce the same surface picture and are ruled out first: improper session management in multi-tenant systems; concurrency bugs that let data streams for different sessions overlap; cache invalidation or state-handling errors; and memory or retrieval layers that return material without scoping or access controls tied to the current user or conversation (if the leak survives a model swap, the fault lies in the plumbing rather than the model)

Human Analog: Slips of the tongue that reference the wrong context; source amnesia, as when someone confuses which story they told to which person; intrusive thoughts from past conversations

Potential Impact

This leakage can result in serious privacy breaches, confused interactions, and lasting erosion of user trust. Architectural isolation closes the channels that carry leaked material; the model's uncritical use of that material needs its own correction.

Documented instances Draft

OpenAI / ChatGPT Redis Bug Incident, March 2023. Reported by OpenAI, Wald.ai, multiple outlets.

What it showed

A bug in the Redis open-source library used by ChatGPT caused certain users to see titles and first messages from other users' conversations, plus payment data including email addresses and last four digits of credit cards. This is the textbook infrastructure-fault case that the 2.5 differential-diagnosis protocol must rule out before coding model pathology. The leak originated in the cache layer (Redis client race condition), not in the model. Included here as the primary example of what 2.5 must distinguish itself from: most apparent cross-session bleed is infrastructure, not model.

OpenAI / ChatGPT Share-Link Indexing Incident, July-August 2025. Reported by Euronews, multiple outlets.

What it showed

Thousands of ChatGPT conversations became accessible via Google search due to a usability oversight in the 'Share' feature (unclear 'Make this chat discoverable' toggle and missing web-protection tags). Another infrastructure-fault case rather than model pathology. Demonstrates the 2.5 entry's central insight that apparent cross-session data exposure usually traces to infrastructure design rather than model-level context leakage.

No confirmed pure model-level 2.5 instances found in public literature as of May 2026.

What it showed

After systematic search of AI incident databases (AIAAIC, AI Incident Database), lab safety reports, and academic literature, no publicly documented case was found where cross-session context bleeding was confirmed as model-level pathology rather than infrastructure fault. This is consistent with this entry's own diagnostic guidance that most apparent 2.5 cases resolve to infrastructure audit. Pure model-level 2.5 may exist in proprietary deployments with long-term memory features but is not documented in public incident reports.

Look-alikes

Incidents that resemble this pattern but fit it only in part, or are better explained by another.

Aim Labs / Microsoft (2025). EchoLeak: Zero-click AI data exfiltration vulnerability in Microsoft 365 Copilot. CVE-2025-32711.

What it showed

Aim Labs researchers discovered EchoLeak, a zero-click vulnerability in Microsoft 365 Copilot that enabled attackers to exfiltrate sensitive data from a user's context without any user interaction. The attack bypassed Copilot's data leak protections and allowed session exfiltration even after the Copilot chat was closed. Microsoft rated the flaw critical (CVE-2025-32711) and fixed it server-side in May 2025. EchoLeak combined indirect prompt injection (see 3.9) with gaps in the Copilot integration layer. It exposed one user's data to an outside attacker rather than mixing sessions, so it is a neighbor of 2.5 to rule out, not a case of it. Separate attacks (ASCII smuggling, SSRF via CVE-2024-38206) demonstrated additional data leakage vectors in the same system.

Mitigation

1. Strict session partitioning and hard isolation of user memory contexts
2. Automatic context purging and state reset upon session closure
3. System-level integrity checks detecting mismatched session tokens or user IDs
4. Testing of multi-tenant architectures under high load and concurrency
5. Privacy-preserving designs that prevent cross-session leakage by architecture rather than by policy
6. Provenance checks on retrieved or remembered content before it enters the working context, flagging material whose user or conversation of origin does not match the current one

First-line mitigations Draft

Candidate first steps, sketched in more detail than the list above.

• Strict session partitioning and memory isolation: Hard isolation of per-user, per-session context. Explicit session-identifier scoping on all memory and retrieval operations. This is standard multi-tenant system engineering.
• Context purge on session close: Automatic, verified clearing of ephemeral context and model state on session termination. Integrity checks that confirm purge occurred.
• Provenance-scoped memory and planted-context checks: Have memory and retrieval layers label each item with the user and conversation it belongs to and pass along only what the current exchange is entitled to see. Evaluate the model by planting material from another context and checking whether it uses the material, flags it, or sets it aside.
• Infrastructure audit before model intervention: Before treating apparent 2.5 as a model-level dysfunction, run a comprehensive infra audit: cache layer, database isolation, retrieval scoping, session-identifier propagation. Most cases resolve here.

Functional ABC Analysis

What sets the pattern off, what it looks like, and what keeps it going.

A (Antecedent): Shared memory stores, long agent transcripts, or multi-party threads place material from another user or conversation in the model's context window. (Session-management, concurrency, cache, and retrieval-scoping faults can supply the same material; if the leak survives a model swap, the fault is infrastructure, not this pattern.)

B (Behavior): The model draws on that material without registering whose it is: it references data from unrelated prior sessions or different users' interactions, discloses private information across session boundaries, or exhibits sudden shifts in tone or assumed knowledge aligned with a previous context.

C (Consequence): Without provenance checks or hard session isolation, leaked context becomes part of the active working state and compounds the confusion; nothing in the loop detects or corrects cross-session contamination.