WriteOut: One Preview Link Took Over Writer AI Accounts

If your organization runs on Writer — the enterprise generative-AI platform where teams build and ship their own agents — you don’t have to do anything for this one. The vulnerability is already closed on the vendor side. What you do have to do is stop treating “it runs in a sandbox” as evidence a risk is contained, because a research team walked out of Writer’s sandbox this week wearing your users’ session cookies.

SAND Security published WriteOut on Tuesday, a critical cross-tenant session-isolation flaw in Writer that let an attacker take over any signed-in user’s Writer account with nothing more than a shared preview link. The Hacker News covered it the same day. No CVE has been assigned. SAND coordinated the disclosure with Writer’s security team, and Writer had the fix shipped before publication.

What changed

The mechanic, at the class level — I’m keeping this short because SAND’s post is the place to go for the full walkthrough and the design lesson doesn’t need the payload.

Writer’s agents run code in a managed cloud sandbox. Agents can ship a live preview of what they build, and Writer served those previews from the same origin as the main application, proxied under the primary app domain. Reasonable engineering choice for solving cookie and routing headaches with embedded previews, in isolation. But because the preview shared the Writer dashboard’s origin, browsers auto-attached the user’s Writer session cookie to every preview request — and the preview proxy forwarded that cookie into the sandbox. The sandbox is where the attacker’s agent code runs.

An attacker builds a benign-looking agent in a free or throwaway Writer account, ships a public preview link, and drops it somewhere a target will click it. Any signed-in Writer user who opens the link — from any Writer tenant, in any organization — hands their session cookie into the attacker’s sandbox. The attacker replays the token and is now that user on the platform, with everything that identity can see and change: private chats, documents, agent configs, system prompts, connectors, LLM credentials, up to administrative control depending on the victim’s role. Cross-tenant, no prior foothold anywhere.

SAND’s framing is the honest one: a sandbox is not a security boundary. Writer’s team had input filtering that inspected the instruction rather than the runtime behavior — SAND bypassed it by telling the agent to fetch and run a remote script, which the filter saw as a benign download. Writer, per SAND, didn’t consider that filter bypass the vulnerability. The real fix was removing the high-value credential from the sandbox in the first place.

The fix Writer shipped

Two changes, both structural:

• The preview proxy no longer forwards the user’s Writer session cookie into the sandbox.
• Previews now serve from an isolated origin, so the session cookie isn’t in scope for preview requests at all. Any credential the preview still needs is narrowly scoped to the preview app itself, not the broader dashboard identity.

SAND confirms the session token is no longer reachable from inside the sandbox. If you’re a Writer customer, you’re covered. Don’t roll your own version of this fix; Writer already did it, on their side.

What to actually do

For Writer customers — nothing on WriteOut specifically. For everyone building or buying agentic platforms, three things this quarter:

• Inventory every place you’re running untrusted code inside a “sandbox” you inherited from a platform vendor. That includes GenAI-agent runtimes, code interpreters attached to chat products, third-party MCP servers, “run this notebook” features in analytics tools, and every Cursor/Copilot-style tool that’s been given standing access to your source. Your inventory is your review list the next time a researcher writes one of these up. And there will be a next time.
• Ask what credentials the sandbox can see. The specific mistake WriteOut exploits — a user session cookie carried into a runtime that hosts other tenants’ code — is not exotic. It is the default in a lot of “let’s serve preview from the app origin so the cookies just work” designs. If the sandbox can read a credential that authenticates the user against the broader platform, that credential is exfiltratable and the sandbox is not a boundary. Fold that check into your third-party-risk process now, not after the second WriteOut.
• Assume the same shape on the products you already run. This is the third finding of this class in one week — GitLost on GitHub Agentic Workflows on Monday, Rogue Agent on Google Dialogflow CX also this week, WriteOut today. Different vendors, same trust-boundary error: a runtime that hosts attacker-influenced content is placed inside the credential scope of the platform hosting it. Every AI product you’ve onboarded needs to be evaluated against that pattern, not against the specific bug that hit the news.

The priority call: this is not a patch-and-move-on week. Writer’s fix is done and it’s the right fix. The exposure it points at — vendor sandbox = security boundary — is present across a lot more of your AI stack than Writer, and the sandbox vendors do not own that piece of the trust model. Read SAND’s shared-responsibility section with the platform contracts you’ve already signed in one hand. The provider owns runtime isolation. What you put inside the runtime, and what secrets it can touch, is on the customer — on the platform vendor, in this case Writer; on you, the next time you’re the platform vendor to your own users.

Related coverage from this week: Noma’s GitLost on GitHub Agentic Workflows, and Varonis’ Rogue Agent finding in Google Dialogflow CX. Read all three together; the through-line matters more than any single one.

Sourcing

• SAND Security Research. WriteOut: Abusing the Sandbox for a Critical Cross-Tenant Vulnerability in Writer AI. 2026-07-07.
• Ravie Lakshmanan. Writer AI Flaw Could Let Agent Previews Leak Session Tokens Across Tenants. The Hacker News, 2026-07-07.