Multi-Tenant Agent Isolation Failures: When One User's Context Bleeds Into Another's
On March 20, 2023, a race condition in a Redis client library caused ChatGPT to return data across user boundaries. Payment information and chat history from one account appeared in a different user's session. The bug was not in the AI model. It was in the cache layer every user shared. The model did exactly what it was told; the isolation guarantee was never there.
That incident introduced a category of failure that enterprise AI deployments still consistently underprepare for. Multi-tenant agent platforms treat data isolation as a provisioning decision: handled once at setup, then assumed to hold. It is a runtime enforcement problem. Isolation must hold across every inference request, cache lookup, memory retrieval, and tool call. Any single path-bug collapses the boundary between two users' contexts completely.
Isolation Lives in Application Code, Not in Hardware Boundaries
The enforcement path for tenant isolation in a typical LLM platform looks like this. A user request arrives, an authentication check runs, a cache key is computed, and a database query applies a tenant filter. Each of those steps is a separate software assertion. There is no cryptographic or hardware barrier between them.
The March 2023 ChatGPT incident illustrates what happens when one assertion fails. Canceled HTTP requests left corrupted connections in the Redis pool. Those connections returned data belonging to different sessions. OpenAI's post-mortem confirmed 1.2% of ChatGPT Plus subscribers were affected in a 9-hour window. Billing information and conversation history from one user appeared in another user's session.
This failure mode is not specific to OpenAI's architecture. It is structural to any design where tenant isolation is enforced through application logic over shared infrastructure. The application layer is a single enforcement point over four independent attack surfaces: inference cache, vector store, session memory, and inter-agent messaging. Protecting one does not protect the others.
The KV-Cache Is a Side Channel That Crosses User Boundaries
LLM inference frameworks share key-value caches across requests with matching prefix tokens. This is a legitimate optimization that reduces latency and compute cost for repeated prompts. It is also a timing side channel that allows one user to reconstruct another user's private prompt.
The attack was formalized in NDSS 2025 as PROMPTPEEK. It targets SGLang and vLLM, the two dominant open-source LLM serving systems used in enterprise deployments. SGLang uses a radix tree KV-cache with Longest Prefix Match: when two requests share a prefix, the second request hits the cache and responds faster. An attacker submits probe sequences and measures response timing. Cache hit versus cache miss timing reveals successive tokens of another user's prompt.
Accuracy reaches 99% when the attacker has template knowledge of the target system prompt. Without any prior knowledge, accuracy is 95%. The attack requires only legitimate API access. No authentication bypass is needed.
The OWASP Agentic Security Initiative classifies this under ASI03: agents inheriting access beyond what a given request actually requires. The KV-cache does not distinguish between "same user, same prefix" and "different user, same prefix." The performance optimization and the isolation failure are the same mechanism.
Vector Stores Make Cross-Tenant Retrieval the Default Failure Mode
RAG pipelines in shared agent infrastructure retrieve semantically similar documents across all tenants unless the vector store is explicitly partitioned. The most common deployment does not partition the store. It applies a tenant filter after retrieval. This means cross-tenant documents enter similarity computation before any access control runs.
The failure mode is direct. User A's documents appear in the nearest-neighbor results for user B's query when both occupy the same flat vector namespace. The application layer filters the final result, but the semantic similarity computation already crossed the tenant boundary. In a system where retrieval shapes the agent's reasoning, that crossing matters even when the final output excludes the foreign document.
OWASP ASI06 names this directly: corrupted stored data shapes future agent decisions across sessions. The Burn-After-Use (BAU) paper at arxiv 2601.06627 tested 55 infrastructure attacks against shared vector databases. Even with active defenses, 8% of attacks remained unmitigated in controlled evaluation. Real-world deployments typically do not run defenses equivalent to the evaluation baseline.
Mitigation requires cryptographic namespace segregation per tenant at the storage layer. Post-retrieval filtering is insufficient because it runs after the boundary has already been crossed in the computation.
Agent Long-Term Memory Has No Session Boundary by Design
When an agent persists observations, retrieved documents, or conversational facts into a long-term memory store, those facts become available to subsequent retrievals. If the memory store has no tenant partition, those facts are available to subsequent retrievals by any user. This is not a bug in the memory system. It is the intended memory mechanism operating without isolation.
The CSTM-Bench benchmark (arxiv 2604.21131) demonstrates the practical consequence: stateless guardrails fail against stateful attacks. A malicious input from user A remains accessible in the shared memory store. When user B triggers a retrieval that semantically matches that input, the attacker's content enters user B's context. The guardrail that blocked the original request has no view of the retrieval that delivers the same content later.
The BAU paper measures this gap quantitatively. Its architecture achieved 76.75% success against post-session leakage threats. That means 23.25% of post-session attacks bypassed the best-available mitigation architecture tested in the study. The survey at arxiv 2604.16548 on long-term memory security confirms: shared memory systems across major agent platforms lack adequate access controls between different agent instances.
The attack surface is ordinary agent operation. Retrieve, summarize, store. The same workflow that makes agents useful across sessions is the mechanism that carries one tenant's context into another's.
Prompt Injection Escalates When Retrieval Context Is Shared
Prompt injection in a single-user deployment is bounded by that user's permissions. In a shared-context deployment, a successful injection into shared state becomes an attack against every subsequent user whose session retrieves from that contaminated state.
CVE-2025-32711 (CVSS 9.3, disclosed June 2025) is the production case. EchoLeak is the first confirmed zero-click prompt injection in a production AI system. A single crafted email sent to a Microsoft 365 Copilot user caused the assistant to exfiltrate internal files. No user interaction was required. The attack ran through Copilot's retrieval engine. The malicious email entered the retrieval context, the injected instruction executed under the user's permissions, and the exfiltration completed without a single click.
Slack AI in August 2024 demonstrated the cross-tenant variant. A prompt injection embedded in a public Slack channel caused the AI assistant to exfiltrate data from private channels the attacker had no access to. The exploitation boundary was shared context between public and private channel processing. The attacker did not breach the private channel directly; the agent did, operating under the permissions of the user who triggered the retrieval.
OWASP ASI01 and ASI06 together describe the multi-user consequence. Injection into shared memory creates a persistent attack that delivers attacker instructions to every session that retrieves from the contaminated store. In multi-agent systems, a single injection can propagate through inter-agent message exchanges, reaching agent instances running under different users' permissions.
Isolation Must Be Enforced at Every Layer
Application-layer isolation fails because it creates a single enforcement point over a stack with four independent gaps. Each gap is exploitable without touching the others.
Four layers require independent controls. Inference cache: per-tenant KV-cache partitioning, not shared prefix matching across tenants. Vector store: cryptographic namespace per tenant, not post-retrieval filtering. Session memory: ephemeral contexts destroyed after each session, with no write path from one tenant's session into another's retrieval index. Inter-agent messaging: authenticated channels with tenant scope per OWASP ASI07, not implicit trust between agent instances.
OWASP ASI03 adds a fifth requirement specific to credential handling: credential caches must be scoped per tenant. A shared credential store allows confused deputy attacks where a low-privilege agent retrieves credentials cached by a different tenant's high-privilege session.
The BAU secure multi-tenant architecture achieved 92% defense against infrastructure-level attacks across 127 test iterations. Full isolation through separate inference instances per tenant eliminates the cross-tenant attack surface but negates the economics of multi-tenancy. The tradeoff is real. Strong isolation requires separate compute per tenant. Shared compute reduces cost but leaves four independent attack paths open unless all four are explicitly defended.
Most deployed platforms defend one, sometimes two. The application auth check catches unauthenticated requests. The database query filter catches obvious tenant boundary violations. The KV-cache timing channel runs unguarded. The vector store cross-contamination runs unguarded. The long-term memory store has no session boundary. An injected instruction waits in shared state for the next user's retrieval.
The isolation guarantee that matters is not the one that holds when the code is correct. It is the one that holds when the cache has a race condition and the vector store returns a cross-tenant document. The injected instruction sits in shared memory, waiting for retrieval. That guarantee requires enforcement at four independent layers. Any deployment enforcing only one has three unguarded paths to cross-tenant exposure running right now.
This article was originally published by DEV Community and written by Davi.
Read original article on DEV Community