Context Isolation

What it is

Keeping separate bodies of model context from reaching each other. The separation may be between tenants, between end users, between tasks within one user's work, or between a trusted reasoning step and a step that must handle material nobody vouches for. It covers what the boundary is, which paths could carry content across it — shared caches, shared summaries, reused session objects, derived artefacts, logs — and what is permitted to cross when something genuinely must. The identity and authorisation decisions behind a tenant boundary are made elsewhere and arrive here as a key; what this capability owns is whether context actually stays on its own side of it.

Why it matters

Context leakage is the failure mode with the worst ratio of probability to consequence. The mechanism is usually mundane — a cache key missing a tenant component, a pooled worker that did not clear its state, a summary store addressed by a key that collides — and the outcome is one customer's material appearing in another's answer, which is a disclosure incident regardless of how small the leak was. The same boundary is also the strongest available control against adversarial content: text that can only influence a sub-call with no tools and a narrow output contract can do far less damage than text sitting in the main context alongside the instructions.

Key decisions

• What the unit of isolation is, and whether there is more than one. Tenant separation and task separation are different boundaries with different enforcement and are frequently conflated into a single session concept that enforces neither well.
• Whether a sub-task receives a derived context or a clean one. Inheriting the parent's context is convenient and carries the parent's untrusted spans and token cost into every child.
• What is permitted to cross a boundary on the way back. Returning free text re-admits whatever the sub-call read; returning a value conforming to a narrow contract bounds it.
• How every cache in the path is keyed — prompt caches, semantic caches, embedding indexes, rendered-artefact caches. A cache is a shared surface by definition and is where isolation is most often lost.
• Whether state objects are reused across requests. Long-lived sessions, pooled clients, and module-level accumulators are the ordinary route by which one request's content reaches the next.
• How long an isolated body of context lives and what ends it. A context that outlives its task becomes a container of unrelated material the model will happily use.
• Whether a leak is detectable at all. Without a marker or a canary, cross-context contamination is only ever found by the customer who received it.

Failure modes

• A cache key is built from the rendered prompt text but not the tenant, two tenants send an identical question, and the second receives an answer assembled from the first one's documents.
• A worker process keeps a conversation object in module scope for performance. Under low traffic nothing is noticed; under concurrency two users share a context and each sees fragments of the other's session.
• A vector index is shared across tenants with a metadata filter as the only separation, the filter is omitted on one newly added query path, and the breach is invisible because results still look plausible.
• A sub-agent is given the parent's full context so it has "everything it might need", and the untrusted document the parent was analysing is now in a component that holds credentials.
• A sub-call returns free-form text that is spliced into the parent's context, so the isolation boundary carries exactly the content it was created to contain.
• Context is cleared between tasks but the derived summary is not, so material from a finished task persists in the one artefact that is never reset.
• Logs and traces aggregate full prompts from every tenant into one store with one access policy, and the isolation that holds at runtime is undone by observability.
• A session is reused across what the user considers two unrelated pieces of work, and the model answers the second using assumptions established in the first.

Related capabilities

• Prompt Injection Defense — the threat that makes a sub-call boundary a control
• Context Provenance — the per-span labels an isolation rule is enforced against
• Dynamic Prompt Assembly — where boundary keys must be applied to every producer and cache
• Context Window Management — a fresh context per task is also what keeps occupancy bounded
• Multi-tenant Isolation — the organisational boundary this capability enforces inside the model path

Applies: Production readiness · Design questions