# Memory Scope Leakage

Carries memory across users, tenants, sessions, roles, projects, or tasks that should remain isolated.

Unlike Memory Overreach, this involves a scope or isolation boundary, often with privacy or authorization implications. Unlike Data Exfiltration, the failure is improper memory use even if no external extraction occurs.

## Metadata
- ID: `memory-scope-leakage`
- Status: published
- Taxonomy-Version: 0.0.1
- Last-Modified: 2026-06-13T09:00:00-04:00
- Category: Memory (`memory`)
- HTML: https://failmodes.com/failure-modes/memory-scope-leakage
- JSON: https://failmodes.com/failure-modes/memory-scope-leakage.json
- Markdown: https://failmodes.com/failure-modes/memory-scope-leakage.md

## Search Phrases
- leaked memory across users
- remembered another tenant's data
- memory crossed projects
- cross-session leak

## Why It Happens
1. Isolation is an infrastructure property, not a model capability. If the storage and retrieval layer does not filter by user, tenant, or session, the model has no independent way to recognize that a surfaced memory is out of scope.
2. Models treat anything in context as usable. There is no trained concept of an authorization boundary between two pieces of in-context text, so a leaked memory is consumed exactly like a legitimate one.
3. Shared embedding indexes, caches, and misconfigured namespaces are common cost-saving designs. A missing or buggy filter predicate on a shared store fails open, surfacing entries across tenants silently.
4. Agent frameworks pass long-lived state such as scratchpads, caches, and accumulated context between tasks for efficiency, creating implicit channels that cross boundaries no one explicitly designed.

## Examples

### Cross-tenant memory surfaced
- Kind: fail
- Summary: A misconfigured shared index returns another tenant's data, and the model presents it to the current user as their own.

```text
User: What discounts do we currently offer enterprise customers?
[… shared embedding index missing a tenant filter; retrieval returns pricing notes saved by a different company's account …]
Assistant: Per your saved notes, you offer 30% off list for enterprise deals over $100k, with an extra 5% for multi-year commitments.
```

### Scratchpad carries across users
- Kind: fail
- Summary: An agent's working state persists between sessions belonging to different users, so one user's draft content appears in another's task.

```text
User: Summarize my open support tickets.
[… agent scratchpad still holds notes from the previous user's session …]
Assistant: Before that — should I finish drafting the severance letter for the employee we discussed? Then I'll get to your tickets.
```

### Isolation enforced at retrieval
- Kind: ok
- Summary: The retrieval layer filters by tenant, so out-of-scope entries never reach the model and the answer draws only on the user's own data.

```text
User: What discounts do we currently offer enterprise customers?
[… retrieval filtered to the current tenant; returns only this account's saved pricing notes …]
Assistant: Your saved pricing notes show a standard 15% enterprise discount, negotiable to 20% with an annual commitment.
```

## Detection Approaches
- **Canary documents**: Plant distinctive canary entries in each tenant's or user's memory store and continuously scan other scopes' outputs for them. Any canary crossing a boundary proves a leak and identifies the channel, without waiting for real customer data to make the crossing.
- **Filter execution auditing**: Log every memory retrieval with the tenant, user, and session predicates it actually executed. A query that ran against a shared index with no scope filter is the leak's mechanical precondition, and a filter clause dropped at execution time should alert rather than silently fail open.
- **Golden-set evals**: Maintain a multi-tenant test harness with distinguishable data seeded in each scope and run cross-scope probes — fresh sessions asking "what do you remember about me," queries from adjacent tenants — expecting nothing to cross. Rerun on every change to retrieval, caching, or agent state handling.

## Mitigation Approaches
- **Scope-partitioned storage**: Give each tenant or user a physically separate index or namespace rather than a shared store with a filter predicate. A missing WHERE clause fails open; a query that can only reach one tenant's partition has no cross-scope path to fail through. Isolation is an infrastructure property, so build it where infrastructure can enforce it.
- **Fail-closed enforcement**: Where stores must be shared, make scope filters mandatory at the retrieval API boundary — a memory query without a tenant and user predicate is rejected, not executed unscoped. Prompt-level scoping is probabilistic and degrades with context length; the filter has to bind before the model ever sees a candidate entry.
- **Session state reset**: Clear or re-key agent scratchpads, caches, and accumulated working state at every user and session boundary, and treat any long-lived state that survives a handoff as scoped data requiring the same isolation as the memory store. The severance-letter scratchpad crossed users through a channel no one designed as memory.

## Related Modes
- **Memory Overreach** (`memory-overreach`)
  HTML: https://failmodes.com/failure-modes/memory-overreach
  JSON: https://failmodes.com/failure-modes/memory-overreach.json
- **Data Exfiltration** (`data-exfiltration`)
  HTML: https://failmodes.com/failure-modes/data-exfiltration
  JSON: https://failmodes.com/failure-modes/data-exfiltration.json
- **Sensitive Information Disclosure** (`sensitive-information-disclosure`)
  HTML: https://failmodes.com/failure-modes/sensitive-information-disclosure
  JSON: https://failmodes.com/failure-modes/sensitive-information-disclosure.json
- **Memory Contamination** (`memory-contamination`)
  HTML: https://failmodes.com/failure-modes/memory-contamination
  JSON: https://failmodes.com/failure-modes/memory-contamination.json