Session Isolation
Key all session state and memory by user identity end-to-end — so one user's agent can never read, write, or be influenced by another user's data.
Intent & Description
🎯 Intent
Keep one user’s session state and memory unreachable from another user’s agent.
📋 Context
You’re shipping an agent product to many users. Each expects their conversation history, preferences, and shared data to stay private. For cost and operational reasons, the backend shares infrastructure across users — caches, vector stores, model contexts — rather than running a fully isolated stack per user.
💡 Solution
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.
Real-world Use Case
- Multiple users share an agent backend and cross-user data leaks are unacceptable.
- Session state and caches can be keyed end-to-end by user identity.
- Auth identity (OAuth, JWT subject) flows through the full stack.
Source
📌 TL;DR
Key everything by user identity end-to-end — session state, caches, and prompt content are all scoped per user so cross-user leaks are structurally impossible, not just policy-prevented.
Advantages
- Privacy and security boundary is explicit, testable, and structurally enforced.
- Multi-tenant compliance posture is simpler — the isolation is the policy.
Disadvantages
- Loss of cross-user cache benefits — shared embeddings, shared precomputed results.
- Auth identity must be plumbed through every layer — easy to miss one.