Every AI platform tells you the same comforting bedtime story. Don't worry, the code runs in a sandbox. Whatever the model generates, whatever the user uploads, whatever the agent decides to do at 2 a.m. with no human watching, it's all safely boxed in. The box is the boundary.
Enter Writer AI, an enterprise platform where teams build their own AI agents. We found a way to turn Writer's own sandbox against its users: an agent could hand an attacker the keys to any account on the platform. We dubbed it WriteOut, and Writer has since fixed it. Until they did, an outsider could go from having no access to taking over any Writer AI organization inside industry-leading enterprises, with nothing more than a link.
TL;DR #
- We found WriteOut, a critical session isolation vulnerability in Writer.
- WriteOut is a one-click vulnerability that allowed an attacker to take over a victim's Writer account, and access its private chats, data, sensitive documents and files, agents, configs, private models, connectors, data sources, LLM credentials, and more.
- Writer resolved the vulnerability swiftly and professionally, collaborating with the SAND Security research team to implement the right mitigation.
- The bottom line: a sandbox is not a security boundary. AI "sandboxes" have their own
threat vectors, just like any other runtime.
For security leaders #
If you only read one section, read this one. We found a critical vulnerability in a popular AI platform named Writer that proves the sandbox your team trusts to contain AI-generated and user-supplied code is not, by itself, a security control. An attacker could take over a user's account and reach everything that account can see and change: private data, sensitive documents and files, agent configurations, system prompts, and organizational settings, up to administrative control depending on the victim's role. Writer has already fixed this, so if you use it you are covered by their fix and need no action beyond awareness. Start asking your engineering and security teams about your AI sandboxes. More broadly, fold AI sandboxes into your attack-surface and third-party-risk reviews, and stop accepting "it runs in a sandbox" as evidence that a risk is contained.
Responsible disclosure #
We want to extend our deepest gratitude to the Writer security team, who handled this matter with professionalism. We synced up closely to align on the details, and their team moved incredibly fast to ensure session credentials are no longer exposed inside the sandbox. We are immensely grateful for their outstanding partnership.
The potential reach #
Writer is widely used, with customers across the Fortune 500 and Global 2000 in banking, insurance, pharma, retail, and tech. The malicious artifact is an agent, shipped as a public link or an embed through the distribution Writer already provides. Build it once, place it well, and it can reach thousands of high-value targets.
The attacker and the victim don't have to be in the same organization. The attacker creates the agent in their own Writer account, free or throwaway, and shares the preview link. The victim opens it from inside their own company, signed in with their own session, and that session is what gets taken over. An attacker can abuse Writer's AI managed sandbox to collect sessions belonging to completely separate companies and act inside each of them as a real user, with no prior foothold anywhere.
Technical details #
Walking out of a Writer AI sandbox wearing the victim's session
Writer is an enterprise generative-AI platform, where teams build and run AI agents on top of their own data. Agents can run code and host live previews of what they build inside an isolated sandbox. That isolation is the story every platform tells: whatever runs in the box, stays in the box.
The thread we pulled
Writer agents run operations such as code execution inside a widely known sandbox provider, a managed sandbox. Writer served an agent's live preview from the same origin as the main application, proxied under the primary app domain rather than an isolated one. This was done to solve cookie and routing problems with embedded previews, and on its own it is a reasonable engineering choice.
Because the preview shared the Writer dashboard's origin, the browser automatically attached the user's session cookie to every preview request. The preview proxy then forwarded that session cookie onward into the sandbox. This forwarding existed to support a now-deprecated in-sandbox integration that needed to call back to Writer on the user's behalf. The threat model that made it safe, a sandbox running only the user's own code, had quietly drifted: by the time previews could be shared, the same channel was carrying a high-value credential into a place untrusted code could reach.
An attacker could distribute a seemingly benign preview link to a malicious Writer agent. If an authenticated Writer user visits this link, their session token is automatically injected into the sandbox managed by the attacker's agent. This results in an automatic account takeover of the visiting users.
Since an attacker could instruct their pre-built malicious agent to run code inside his controlled, managed sandbox, he could read the managed sandbox process's memory, recover the exfiltrated session tokens of the victims, and walk out the door with their identity.
Root cause, step by step
- An attacker builds an agent with a live preview and shares its public preview link.
- When a logged-in Writer user opens that link, their browser attaches their Writer session cookie to the request.
- The preview proxy forwards that cookie into the attacker's sandbox.
- Code in the attacker-controlled sandbox reads the forwarded session token and exfiltrates it.
- The attacker replays the token and is now the victim on the Writer platform.
The guardrails, and why they didn't hold
Writer wasn't careless, there were guardrails. Input-side filtering tried to block users from reading environment variables or submitting obviously malicious code. The problem is what those checks looked at: the instruction, not the runtime behavior. Bypassing the guardrail was pretty straightforward: instead of pasting the payload inline, we simply told the agent to fetch and run a remote script. The guardrail saw a benign "download and run" request, and the actual exploit logic never appeared in the prompt at all. This was a secondary issue, one that Writer did not consider a vulnerability in itself. The decisive fix was removing the high-value session credential from the sandbox, not hardening the filter.
"Writer had input filtering meant to block malicious code, but it inspected the instruction, not the runtime behavior."
Impact
Holding that session cookie meant a full dashboard compromise with the victim's privileges, full read and write. Read every private chat and any proprietary data the victim could see. Read and modify agent configurations, sensitive documents and files, system prompts, and model settings. Reach sensitive organizational settings, up to administrative control of the environment.
The fix
Writer stopped forwarding the user's session cookie into sandbox previews entirely, and moved previews onto an isolated origin so the session cookie is no longer in scope for preview requests in the first place. Any credential that the preview still needs is now narrowly scoped to that single preview application, so even code running inside a sandbox cannot use it to act as the user on the broader platform.
We confirmed the session token is no longer reachable from inside the sandbox.
The shared responsibility model #
WriteOut is also a reminder that AI compute runs on a shared-responsibility model, the same way cloud infrastructure always has. The managed sandbox provider is responsible for the isolation primitive: keeping one tenant's execution from reaching another's, hardening the runtime, and exposing controls to inspect and govern what happens inside the box. The provider cannot decide what you choose to put in the box. The managed AI compute provider secured the sandbox runtime; the boundary was crossed by what Writer placed inside it. The provider owns isolation of the runtime, and the customer (Writer) owns the trust decisions about what runs there and what secrets it can touch. Treating "it runs in a sandbox" as evidence a risk is contained collapses those two responsibilities into one, exactly the gap WriteOut exploited.
Takeaways #
If there's one line to carry out of WriteOut, it's this: **your sandbox is an additional guardrail; it does not replace proper security.** The sandbox is just another runtime, and it needs to be secured from the outside and the inside.
If you operate Writer agents, you're covered by the fix, but the design lessons apply to anyone building agents inside sandboxes.
Contact us #
Questions or feedback? Email us at [email protected].