Data leaks between users and sessions are a design problem

You must now verify that your AI deployment isolates user sessions, projects and credentials at the architectural level, not merely at the prompt or model layer. Session leakage is a design choice, not a model failure, and you carry the duty to audit where state is shared.

The prompt is an analysis of 1 August 2026 of session-isolation flaws in multi-tenant AI systems, which argues that leakage between users, projects and sessions is a structural problem rooted in how boundaries are drawn, not in model behaviour. A vulnerability in an agent preview feature allowed attackers to capture session cookies and gain access to private chats, documents, agents, connectors and credentials belonging to other users. In our assessment, this incident exposes a category of risk that affects any AI deployment handling sensitive content across multiple users or projects: the architectural decisions you make about memory, caching and state persistence determine whether confidential information can migrate to unauthorised parties.

What makes this different from a model jailbreak?

The vulnerability required no prompt injection, no adversarial input and no model misbehaviour. The AI system performed exactly as designed. The failure lay in the boundary between users and sessions—a line drawn in the infrastructure, not in the model weights. When a preview feature forwarded session cookies to a sandbox controlled by an attacker, it created a path along which one user's authentication could reach another user's data. This is the distinction that matters: the system did not leak because the model said something it should not have said, but because the architecture allowed sensitive state to be accessible to the wrong party.

Academic work in this space confirms the pattern is systematic. Research describes how agentic AI systems retain and re-expose sensitive information across tasks, users and sessions through persistent memory, vector databases, logs and feedback loops. The authors conclude that memory separation and lifecycle-aware controls are essential. In other words, leakage emerges not from model failure but from shared state. Once you allow an AI system to hold context, cache or credentials that multiple users or sessions can reach, you have created a channel along which information will travel.

Which failure modes should you guard against?

• Cross-tenant credential exposure — authentication tokens or API keys stored in shared memory, caches or preview environments accessible to other users or projects.
• Sensitive content in persistent memory — private documents, chats or agent outputs retained in vector databases or logs without user or session boundaries.
• Shared sandbox state — startup scripts, environment variables or managed credentials that persist across different users' interactions with the same AI workspace.
• Inadequate output redaction — model outputs or intermediate results left visible in shared logs, audit trails or preview features without access controls.
• Uncontrolled feedback loops — information from one user's session fed back into training data, memory or context accessible to subsequent users.

Is this pattern limited to chat and agent features?

No. A cross-tenant vulnerability in a managed notebook environment demonstrates that the risk spans different AI deployment models. The vulnerability centred on managed end-user credentials, metadata and startup scripts that could exfiltrate credentials after minimal interaction. Here too, the problem was inadequate isolation between tenants. Whether the AI surface is an agent preview, a notebook environment or a document workspace, the underlying failure is the same: project-based AI systems leak credentials and access as soon as the dividing lines between users and projects are not drawn tightly enough.

What concrete controls must you be able to demonstrate?

1. Enforce strict session and user isolation — verify that memory, caches and preview environments cannot be accessed across user or project boundaries, and that session cleanup removes all state at logout.
2. Validate and sanitise data before it enters agent memory — implement checks that prevent credentials, tokens and sensitive metadata from being stored in shared context or vector databases.
3. Disable shared caching and state persistence — confirm that AI workflows do not retain context, credentials or outputs from one user's session for use in another user's interaction.
4. Apply access controls to all AI-facing data — document which users and roles can reach which models, memory stores, logs and preview features, and enforce those controls at the infrastructure layer.
5. Audit credential handling in sandboxes and preview features — trace how authentication tokens, API keys and managed credentials flow through your deployment, and verify they are not forwarded to untrusted environments.

What role does preprocessing play in reducing this risk?

If the content that reaches an AI model is already anonymised or redacted before it leaves your infrastructure, there is less traceable information that can surface with the wrong party via memory, cache or preview. Preprocessing and anonymisation on your own infrastructure, with verification steps visible to users, changes where the risk concentrates. It does not eliminate the need for architectural isolation, but it reduces the sensitivity of the data that flows through shared systems. The principle is to minimise the number of places where confidential content becomes shared state.

The recent incidents and guidelines converge on one message: isolation between users, projects and sessions is a design requirement, not optional hardening. You must audit where state is shared in your deployment, verify that boundaries are enforced at the architecture level, and recognise that no amount of prompt engineering or model tuning will compensate for shared memory or caches. The professional judgement about whether your controls are sufficient remains yours alone.