V · MemoryMature★★

Session Isolation

also known as Tenant Separation, Per-User State

Keep one user's session state and memory unreachable from another user's agent.

Context

A team is shipping an agent product to many users. Each user expects their conversation history, preferences, and any data they share to stay private to them. For cost and operational reasons, the backend shares some infrastructure across users — caches, vector stores, model contexts — rather than running a fully isolated stack per user.

Problem

A shared memory backend or a shared model context can leak one user's data into another user's response. A misindexed cache key returns user A's history to user B. A prompt-cache prefix that includes user-specific context is reused across users. A vector store query without per-user partitioning surfaces another user's documents as 'relevant'. Any of these is a privacy and security failure that can be much worse than an ordinary bug, because the leak may go unnoticed for a long time and the consequences for user trust and regulatory exposure are severe.

Forces

  • Cache hits across users are tempting for cost; they break isolation.
  • Auth scope must travel with every read and write.
  • Multi-tenant prompt injection becomes a real attack surface.

Example

A multi-tenant assistant uses a shared vector cache across all users and one day a competitive-intelligence answer for tenant A surfaces in tenant B's context because the embedding match was strong. The team scopes every cache key, every memory backend read, and every prompt context to the per-user OAuth subject end-to-end. Cross-tenant contamination becomes structurally impossible rather than 'we hope it doesn't happen.'

Diagram

Solution

Therefore:

Session state is keyed by per-user identity (OAuth/JWT subject). Reads and writes carry that identity end-to-end. Caches are scoped per user. Prompts never include another user's content.

What this pattern forbids. No code path may read or cache user A's state under user B's identity.

And the patterns that stand alongside it, or against it —

  • complementsShort-Term Thread Memory★★— Carry the relevant slice of conversation context across turns within a session.
  • complementsInput/Output Guardrails★★— Validate inputs before they reach the model and outputs before they reach the user.
  • complementsCross-Session Memory★★— Persist user-specific facts, preferences, and prior context across all sessions, threads, and devices.
  • complementsTool Result Caching★★— Cache the result of expensive deterministic tool calls keyed by their arguments so repeat calls within a session return immediately.
  • complementsPrompt Injection Defense★— Tag user-supplied or tool-supplied content as untrusted and refuse to follow instructions found inside it.
  • complementsPII Redaction★★— Detect and remove personally identifiable information from inputs to and outputs from the model.
  • complementsSecrets Handling★— Ensure the model never receives secrets in plaintext; tools resolve credentials from references at runtime.
  • complementsSovereign Inference Stack★— Run the entire agent stack (model weights, inference, tool layer, vector stores, logs) inside a jurisdictional and operational boundary the operator controls, so no request, prompt, or output crosses into a third-party API.
  • alternative-toMemory Extraction Attack✕— Anti-pattern: let any session prompt the agent to read out, summarise, or paraphrase long-term memory entries belonging to other users, prior sessions, or system state, with no read-time isolation by principal.
  • complementsShadow AI✕— Anti-pattern: leave the corporate the model offering so restrictive, slow, or narrow that employees bypass it with personal accounts and unapproved agent tools, creating data leakage and ungoverned tool calls that security cannot see.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

Used in recipes

Used in frameworks

Show 6 more

References

Provenance