A seemingly small flaw in a preview feature can have major consequences. According to The Hacker News, Writer's AI platform contained a critical vulnerability in the agent preview feature: it could forward a victim's session cookie to a sandbox controlled by an attacker. This made cross-tenant account takeover possible, including access to private chats, documents, agents, connectors and LLM credentials. Writer has resolved the problem by isolating previews and stopping the forwarding of cookies.
The striking thing about this incident is that no model jailbreak was involved. The AI itself did not behave incorrectly; the boundary between users, projects and sessions had been drawn wrongly. That makes it an instructive example: sensitive content can end up with the wrong party purely because memory, caches, previews or workspaces are shared.
Why these leaks are structural
The idea that session and cross-user leakage is not an accidental bug but a property of the system design is supported by recent academic work. A review study in Frontiers in Computer Science describes how agentic AI systems can retain, pass on and re-expose sensitive information across tasks, users and sessions. This happens through persistent memory, vector databases, logs, tool use and feedback loops. The authors conclude that memory separation and lifecycle-aware controls are needed to prevent this.
In other words: as soon as an AI system shares state between sessions or users, a path emerges along which information can leak. It is not a question of whether the model says something "wrong", but a question of which data ends up in the context, memory or cache that is also accessible to others.
The same pattern in AI workspaces
Research by Tenable Research shows that this pattern is not limited to chat and agent features. Google Cloud Vertex AI Workbench contained a cross-tenant vulnerability that made full account takeover possible. It centred on managed end-user credentials, metadata and a startup script that could exfiltrate credentials after minimal interaction. Here too, the problem lay in inadequate isolation between tenants, and it was resolved by removing the vulnerable components.
The common thread between Writer and Vertex AI Workbench is clear: whether it concerns an agent preview or a managed notebook environment, project-based AI workspaces can leak credentials and access as soon as the dividing lines between users and projects are not drawn tightly enough.
What the right defence is
OWASP's AI Agent Security Cheat Sheet translates this into concrete measures. The guideline describes that AI systems must apply memory separation between users and sessions, must validate and clean data before it ends up in an agent's memory, and must avoid shared state that can leak across boundaries. Isolation is thereby a required control, not optional hardening.
Practical background on testing this is provided by Giskard, which names strict session and user isolation, output redaction, access control and disabling shared caching as the right defence against cross-session leakage in AI systems with multiple users.
The lesson for teams is that you must design isolation explicitly and must not infer it from the behaviour of the model. The questions that keep coming back: which data ends up in memory? Who can reach that same cache or preview? What happens to tokens and credentials when a sandbox is started? And how is state cleaned up at the end of a session?
The connection with working at Vera
For professionals who work with confidential files, this series of incidents is relevant because it does not concern exotic attacks, but everyday design choices around boundaries and shared state. At I am Vera, the starting point is therefore that sensitive content ends up in shared AI context as little as possible.
The Semantic Privacy Shield is designed so that preprocessing and anonymisation take place on EU infrastructure, and so that the workflow only sends anonymised content to the selected AI models. If a privacy check fails, nothing is forwarded. That changes where the risk lies: if the content that reaches a model is already anonymised, there is less traceable information that can surface with the wrong party via memory, cache or preview.
In addition, Vera as a verification layer makes the check steps visible, so that a user gains more insight into what happens to content. And with Vera Office, documents can be viewed and edited within the same secure environment, without moving them to separate, less controlled workspaces. Vera does not promise correctness or perfect anonymisation; the aim is to make control possible and to limit the number of places where confidential content becomes shared.
The message of the recent incidents and guidelines is sober: isolation between users, projects and sessions is a design requirement. Anyone deploying AI for sensitive work would do well to check where state is shared, and the professional final judgement about the outcome always remains with the user themselves.