WriteOut: when an AI sandbox forwards the user's session cookie

What is this?

On July 7, 2026, the Sand Security research team disclosed a critical, now-patched session isolation vulnerability in Writer, an enterprise generative-AI platform. They named it WriteOut, and it was reported the same day by The Hacker News. The flaw is a “one-click” cross-tenant account takeover: an attacker builds an agent in their own account, shares its preview link, and any logged-in Writer user who opens that link can have their account hijacked — including administrators, and including users in completely different organizations.

The impact is broad. A stolen Writer session grants access to private chats, documents, agent configurations, private models, connectors, and stored LLM credentials. Because the attacker and victim need not share an organization, the bug breaks the tenant isolation that enterprise customers assume underpins a multi-tenant SaaS product. Writer has since fixed it. We cover it because the root cause is a general design mistake — trusting a managed sandbox with a user credential it should never have seen.

How it works

Writer’s Framework offers a live preview so builders can try an agent while developing it. That preview runs the agent’s code inside a Writer-managed sandbox, reached through a preview proxy. The mistake was in how the request to that sandbox was authenticated.

The reported chain, per Sand Security and The Hacker News:

1. Attacker builds an agent with a live preview, shares its public preview link.
2. A logged-in Writer user opens the link. Their browser attaches
   their Writer session cookie to the request (same-site, they're logged in).
3. The preview proxy forwards that cookie into the ATTACKER's sandbox.
4. Attacker's agent code reads the forwarded token from the sandbox
   process memory and sends it to an attacker-controlled server.
5. Attacker replays the token and controls the victim's account.

The pivotal step is 3: the victim’s own credential ends up inside a runtime the attacker fully controls. From there, reading it back is trivial — it is sitting in the process the attacker is already allowed to run code in.

Writer was not defenseless. Input-side filtering tried to block requests that read environment variables or that submitted “obviously malicious” code. But those checks inspected the instruction, not the runtime behavior. According to Sand Security, the bypass was simply to avoid pasting a payload inline and instead tell the agent to fetch and run a remote script: the filter saw a benign “download and run” request, and the real exploit logic never appeared in the prompt at all. This is the same lesson their earlier write-up “your sandbox is not your security” makes — a sandbox that runs untrusted code is not, by itself, a trust boundary.

Why it matters

Session cookies are bearer tokens; anything that can read one becomes the user. A Writer session cookie is enough to be the victim. Forwarding it into a sandbox that runs attacker-supplied code hands over that identity wholesale. The failure is not exotic AI behavior — it is a classic credential-scoping error, made larger because the sandbox is a designed feature that runs arbitrary user code by intent.

AI agent “preview” and “playground” features are a fast-growing attack surface. The pattern — let users write and instantly run agent code in a hosted sandbox — is now everywhere. Each such feature is a place where untrusted code executes close to platform internals. If any user-scoped secret (cookie, API token, cloud credential) is reachable from that runtime, one product convenience becomes a cross-tenant compromise.

Prompt/allowlist filtering that reads intent is not a runtime control. The bypass here matters beyond Writer: a filter that scans the instruction can be defeated by moving the malicious logic out of the instruction (“fetch and run this URL”). Behavior has to be constrained where it executes — through egress limits, memory isolation, and least privilege — not by pattern-matching what the user typed.

Defenses

The specific bug is patched: Writer now prevents the user’s session cookie from being forwarded into sandbox previews at all, and serves previews from an isolated origin. The general lessons apply to anyone building agent preview or code-execution features.

1. Never let a user credential cross into an untrusted runtime. Sandboxes that execute user or third-party code must authenticate with their own short-lived, narrowly-scoped tokens — never the end user’s session cookie. Strip and re-mint credentials at the boundary.

2. Serve untrusted execution from an isolated origin. Put previews, playgrounds, and rendered agent output on a separate origin (and separate cookie scope) so the browser’s same-site rules do not attach first-party session cookies to those requests. This is precisely the fix Writer applied.

3. Enforce behavior at runtime, not intent at the input. Assume input filters will be bypassed by indirection (remote fetch, encoding, staged payloads). Control what the sandbox can actually do: block or allowlist outbound network egress, restrict filesystem and memory access, and drop unneeded capabilities.

4. Scope and rotate sandbox secrets to the blast radius you can accept. If a runtime must hold any secret, keep it per-session, per-tenant, and short-lived, so a leak from one preview cannot be replayed elsewhere or later.

5. Treat tenant isolation as a tested invariant. Cross-tenant checks belong in your security test suite: can an artifact created by tenant A cause code to run — or credentials to flow — in the context of tenant B? Red-team the preview and sharing paths specifically.

Status

Item	Reference	Date	Notes
WriteOut disclosed	Sand Security	2026-07-07	Critical cross-tenant session isolation flaw in Writer
Independent reporting	The Hacker News	2026-07-07	Confirms attack chain and impact
Vendor fix	Writer (via Sand Security)	Reported 2026-07-07	Cookie no longer forwarded to sandbox; previews moved to isolated origin

The one-line version: a managed AI sandbox received the victim’s session cookie, and a feature meant to preview agents became a one-click account takeover across tenants. The durable takeaway is not specific to Writer — it is that a runtime designed to execute untrusted code must never be trusted with a credential that identifies the user.