WriteOut: how a shared agent preview link could hijack any Writer AI account

What is this?

On July 7, 2026, the Sand Security research team disclosed a now-patched critical session-isolation vulnerability in Writer, an enterprise generative-AI platform. The flaw, codenamed WriteOut, allowed cross-tenant account takeover from a single shared link. An attacker who built an agent in their own Writer workspace and shared its live-preview link could hijack the account of any signed-in Writer user who clicked it — even a user in a completely different organization.

According to Writer’s statement to The Hacker News, the issue was reported and fixed within 24 hours in May 2026, no customer data was compromised, and there is no evidence of malicious exploitation. The technical write-up was published publicly on July 7, 2026, and updated July 9 with Writer’s response. The vulnerability is fully patched; this article covers it as a defensive architecture lesson, not an actionable exploit.

How it works

The root cause is an origin and cookie-scoping mistake in how the platform served agent previews. Writer’s live preview feature lets a builder view a running agent through a proxy. That preview was served from the same origin as the main application rather than an isolated one — a decision made to solve cookie and routing problems with embedded previews. Because the preview shared the primary app origin, the browser attached the user’s Writer session cookie to preview requests, and the proxy forwarded that cookie into the sandbox running the previewed agent.

The reported chain, at a high level:

# Trust boundary that collapsed: "preview sandbox" was inside the app's origin

1. Attacker builds an agent with a live preview, shares the public preview link.
2. A logged-in Writer user (any org) opens the link.
3. Browser attaches the victim's Writer session cookie to the request.
4. Preview proxy forwards that cookie into the ATTACKER-controlled sandbox.
5. Attacker's agent code reads the forwarded session token from the
   sandbox process and exfiltrates it to an external server.
6. Attacker replays the token → control of the victim's Writer account
   (up to admin, depending on the victim's role).

A second detail is why input filtering did not stop it. Writer had guardrails that inspected submitted code and prompts for obviously malicious patterns such as reading environment variables. Sand Security bypassed them by not putting the payload in the prompt at all: the agent was simply told to fetch and run a remote script. The guardrail saw a benign “download and run” instruction, while the real logic never appeared in the text it screened. As the researchers put it, the checks looked at the instruction, not the runtime behavior.

Why it matters

This is a clean example of how classic web-isolation failures re-emerge inside AI agent platforms, with higher stakes. A Writer account can hold private chats, documents, agent configurations, connectors, private models, and LLM credentials — so a stolen session is not just data exposure, it is a foothold into an enterprise’s AI supply chain.

Three properties make it worth studying. First, the trust boundary: an “agent preview sandbox” sounds isolated, but serving it from the primary origin quietly placed it inside the app’s cookie scope. Second, the cross-tenant reach: attacker and victim did not need to share an organization, which turns a per-account bug into a platform-wide one. Third, the guardrail blind spot: content-level filtering of prompts is not a substitute for controlling what code can actually do at runtime — a recurring theme across agent security in 2026, and squarely within OWASP’s LLM Top 10 concerns around excessive agency and insecure output/tool handling.

Defenses

For teams building or operating agent platforms and previews:

1. Isolate untrusted execution to its own origin. Serve previews, sandboxes, and any user-authored agent code from a separate domain with no relationship to the app’s session cookies. This is the single control that closes WriteOut-class issues.
2. Never forward first-party session cookies into a sandbox. Scope authentication cookies with SameSite, HttpOnly, Secure, and a domain/path that a preview proxy cannot reach. If a preview needs identity, mint a short-lived, least-privilege token specific to that preview.
3. Treat preview/share links as untrusted input. Assume any link a user can generate may be sent to another user; design so that clicking it cannot transfer credentials or elevate access.
4. Filter on behavior, not just wording. Prompt/code screening that matches strings is easily bypassed by “fetch and run remote code” indirection. Constrain egress, block outbound network by default, and enforce syscall/permission policies inside the sandbox.
5. Assume tokens leak; limit the blast radius. Bind sessions to device or client signals, shorten token lifetimes, and require re-authentication for sensitive actions like changing connectors or admin settings.
6. Log and alert on cross-tenant anomalies. A session token first seen from one organization then replayed from an unrelated context is a high-signal detection.

Status

Item	Reference	Date	Notes
WriteOut disclosure	Sand Security	2026-07-07	Cross-tenant session-isolation flaw; codename WriteOut
Vendor fix	Writer statement via The Hacker News	2026-05	Patched within 24h; cookies removed from previews, previews moved to isolated origin
Public write-up updated	The Hacker News	2026-07-09	Added Writer’s response; no CVE assigned
Category	OWASP LLM Top 10 (2025)	2025	Excessive agency / insecure tool and output handling

No CVE was assigned. The bug is fixed, but the pattern generalizes: any platform that runs user-authored agents in a “sandbox” served from its own origin should re-check that session credentials cannot cross into that sandbox.