When one user’s answer contains another user’s data

An engineer at a consumer software company told me about a report that sounded impossible at first. A user said the assistant had shown them a detail that was clearly not theirs, a name and a fragment of a request that belonged to someone else entirely. There was no injection, no attack, no obvious bug in the model. The cause turned out to be caching. To save on cost and latency, the team had built a cache keyed in a way that did not fully account for who was asking, and under the right timing, one user’s cached context surfaced in another user’s answer.

This is the quiet failure mode of shared state. The model did nothing wrong. The infrastructure around it mixed two people’s data together, and the model faithfully answered using the wrong person’s context. To the user it looked like the AI had leaked a stranger’s information, which is exactly what happened, even though nobody wrote code to do it.

Shared state is where isolation quietly breaks

AI features accumulate state in more places than teams track. There is the conversation history. There is a cache of prompts and responses. There is sometimes a memory store meant to make the assistant feel continuous. Each of these holds context, and each one has to be scoped correctly to a single user, or context from one person can reach another.

Caching is the usual culprit because caching is about reuse, and reuse is the opposite of isolation. If the cache key does not fully capture who the request belongs to, two different users can collide on the same entry, and one gets served the other’s content. The optimization that made the feature cheaper became the path that mixed users together.

Memory features carry the same risk with a longer fuse. If a store meant to remember one user’s context is scoped loosely, or if an identifier is reused, the assistant can carry a detail from one person into a session with another. The leak is subtle, hard to reproduce, and deeply damaging when a user notices, because it reads as the system handing out private information at random.

Isolate every piece of per-user state

The fix is to treat isolation as a property you design and test, not one you assume. Every place that holds context has to know whose context it is.

Concrete practices:

Scope caches to the caller. Make the user’s identity part of any cache key that holds user-specific content, so two people can never collide on the same entry.
Partition memory and history by user, strictly. No shared store should hold one person’s context in a way another person’s session can reach.
Watch for reused identifiers. Session tokens, keys, and identifiers that get recycled are a common way one user inherits another’s state.
Test with concurrent users on purpose. Many of these leaks only appear under overlapping sessions, so drive that case deliberately rather than hoping it never happens.

The teams that get this right do not trust that isolation holds. They prove it, by trying to make one user’s data appear in another’s session and confirming they cannot. Cross-user leakage is the kind of failure that erodes trust in a single incident, so it is worth the deliberate check.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement, we map every place the feature holds per-user state. Caches, conversation history, memory stores, anything that carries context between requests. We check that each one is scoped to the caller and we try to make context cross between users. Finding that leak in a diagnosis is a good day. Finding it in a customer’s screenshot is not.

The model does not have to leak for your feature to leak. Isolate every cache and every memory store, and prove that one user’s data can never reach another’s answer.