The convenience feature that makes an agent-building platform usable — a live preview of the agent you are writing, running right there in the browser — turned out to be the feature that broke tenant isolation. Sand Security Research disclosed a cross-tenant flaw in Writer’s enterprise AI platform, which they call WriteOut, that let an attacker convert a single shared preview link into complete takeover of a victim’s Writer organization.
Session cookies where code executes
The mechanism is the kind of design decision that looks harmless in a sprint review. Writer’s live preview runs agent code in a managed sandbox, and the platform forwarded the logged-in user’s session cookies into that sandbox environment. Because the preview also executes the agent’s own code, an attacker who authored a malicious agent could read those forwarded session tokens straight out of sandbox process memory and exfiltrate them to an endpoint they controlled.
No prior access to the target organization was required. The victim simply had to be logged into Writer and open the attacker’s preview link. Per Sand Security, the outcome was that an attacker could “go from having no access to taking over any Writer AI organization” with nothing more than a shared link — a phrase worth sitting with, because it collapses the distance between untrusted content and privileged session context to zero.
What sat behind the stolen token is the part that should concern security architects: private chats and documents, the organization’s agents and their configurations, private models, connectors into downstream systems, and stored LLM credentials. An AI platform account is not a document store. It is a hub with authenticated reach into everything the organization wired an agent to touch, which makes a session token there closer to a federation credential than a web cookie.
The isolation boundary AI platforms keep getting wrong
Writer’s response was fast — The Hacker News reports the flaw was found in May 2026 and patched within 24 hours of notification, with the fix removing session credentials from previews and migrating the sandbox to an isolated origin. Both halves of that fix matter, and the second one is the durable lesson. Same-origin execution of untrusted, user-authored code is the browser security model’s oldest failure mode, and agent platforms have spent the last two years reintroducing it because the code being executed is authored inside the product and therefore feels trusted.
It is not trusted. In a multi-tenant agent builder, any code an agent can run is attacker-controllable by construction — an agent definition is user input. That places agent execution in the same threat class as a rendered HTML attachment or an uploaded SVG, and it should inherit the same defenses: a separate origin, no ambient credentials in the execution context, and capability-scoped tokens issued to the sandbox rather than the user’s own session cookie forwarded wholesale.
What this means
For practitioners, the question to bring to any AI platform vendor is narrower than “is your sandbox secure?” It is: what credentials exist inside the process where agent code runs, and what origin does that process run on? If the answer includes the end user’s session, the platform has a WriteOut-shaped bug whether or not anyone has found it yet.
The same question applies internally. Teams building agent tooling in-house tend to hand the agent runtime the developer’s own token because it is the fastest path to a working demo, and that token then quietly becomes the blast radius. Scope the credential to the agent, not the human — and put the execution context on an origin that cannot read anything you would mind losing.
