WriteOut shows why AI sandboxes do not replace boundaries

What this is about

Sand Security described a serious flaw in Writer AI on July 7, 2026: an attacker could share a harmless-looking agent preview link. If a logged-in Writer user opened that link, the user's session token could reach a sandbox controlled by the attacker. Writer says it fixed the issue within 24 hours after notification in May 2026 and has no evidence of malicious exploitation.

The interesting part is not only Writer. The interesting part is the pattern: many companies treat an AI sandbox as a magic security boundary. WriteOut shows that the boundary is only as strong as the data, cookies, tokens and permissions you allow into it.

What WriteOut actually does

The attack used a live preview feature for Writer agents. According to Sand Security, the preview ran under the same origin as the main application. That meant the victim's browser automatically attached the Writer session to the preview request. The preview proxy then forwarded that session into the agent sandbox.

Inside that sandbox, attacker-controlled code could read the token and reuse it outside the sandbox. One click could become an account takeover with the affected user's privileges. If the victim was an administrator, the potential blast radius was larger: private chats, documents, agent configurations, system prompts, connectors and organization settings could be within reach.

Why it matters

The case matters because agent platforms no longer just generate text. They host small apps, execute code, access internal data sources and connect to enterprise systems. That is exactly where tokens, roles and confidential work data live.

The Hacker News reported that Writer, after publication, confirmed that it removed session cookies from sandbox previews and moved previews to an isolated origin. That is the core lesson: the hard boundary is not a prompt filter. It is an architecture where high-value credentials never enter an untrusted runtime in the first place.

In plain language

Imagine a workshop with a locked testing room. The room is useful because sparks, dust and mistakes should stay inside it. But if you accidentally leave the master key to the whole building inside that room, the door lock helps only so much. That is the lesson of WriteOut: the sandbox was the testing room, and the session token was the master key.

A practical example

A company has 2,000 Writer users and allows teams to share agent previews internally. An attacker creates a seemingly useful preview agent, sends the link to 50 targets and a logged-in department lead clicks it. If her session token is forwarded, the attacker can read internal documents, alter an agent prompt and inspect a connector with her permissions, without knowing her password.

After the fix, that path should no longer work because the session no longer lands inside the preview sandbox. For other platforms, the open question remains: which tokens, secrets or internal APIs can reach the agent runtime at all?

Scope and limits

• Writer says the flaw is fixed and that it has no evidence of customer data compromise. This article therefore describes a risk and architecture problem, not a known ongoing attack.
• This is not proof that every AI sandbox is insecure. It shows that sandboxes can be wired incorrectly when session and origin boundaries blur.
• Without Writer's detailed internal logs, outsiders cannot verify which customers were actually exposed or whether any specific preview links were abused.

SEO & GEO keywords

WriteOut, Writer AI, Sand Security, AI sandbox security, session hijacking, agent security, enterprise AI risk, live preview vulnerability, AI runtime isolation, cloud tenant isolation