WriteOut zeigt, warum AI-Sandboxen keine Grenze ersetzen

Worum es geht

Sand Security hat am 7. Juli 2026 eine Schwachstelle in Writer AI beschrieben, die es in sich hat: Ein Angreifer konnte einen harmlos wirkenden Agenten-Preview-Link teilen. Wenn ein angemeldeter Writer-Nutzer diesen Link oeffnete, konnte dessen Sitzungstoken in die vom Angreifer kontrollierte Sandbox gelangen. Writer sagt, die Luecke sei nach der Meldung im Mai 2026 innerhalb von 24 Stunden geschlossen worden; es gebe keine Hinweise auf missbraeuchliche Ausnutzung.

Interessant ist nicht nur Writer. Interessant ist das Muster: Viele Unternehmen behandeln eine AI-Sandbox wie eine magische Sicherheitsgrenze. WriteOut zeigt, dass die Grenze nur so stark ist wie die Daten, Cookies, Tokens und Berechtigungen, die man hineinlaesst.

Was WriteOut tatsaechlich macht

Der Angriff nutzte eine Live-Preview-Funktion fuer Writer-Agenten. Laut Sand Security lief die Vorschau unter derselben Herkunft wie die Hauptanwendung. Dadurch haengte der Browser des Opfers bei einem Preview-Aufruf automatisch die Writer-Sitzung an. Der Preview-Proxy leitete diese Sitzung weiter in die Sandbox des Agenten.

Dort konnte der Angreifer Code ausfuehren lassen, das Token auslesen und es ausserhalb der Sandbox erneut verwenden. Aus einem Klick wurde damit eine Konto-Uebernahme mit den Rechten des betroffenen Nutzers. War das Opfer Administrator, konnte der Schaden entsprechend groesser werden: private Chats, Dokumente, Agenten-Konfigurationen, System-Prompts, Connectoren und organisatorische Einstellungen standen potenziell im Zugriff.

Warum das wichtig ist

Der Fall trifft einen Nerv, weil Agenten-Plattformen inzwischen nicht nur Text generieren. Sie hosten kleine Apps, fuehren Code aus, greifen auf interne Datenquellen zu und verbinden sich mit Unternehmenssystemen. Genau dort liegen Tokens, Rollen und vertrauliche Arbeitsdaten.

The Hacker News berichtete, dass Writer nach der Veroeffentlichung bestaetigte, die Sitzungscookies aus Sandbox-Previews entfernt und Previews auf eine isolierte Origin verschoben zu haben. Das ist die eigentliche Lehre: Nicht der Filter im Prompt ist die harte Grenze, sondern eine Architektur, in der Hochwert-Credentials gar nicht erst in eine untrusted Runtime gelangen.

Einfach erklaert

Stell dir eine Werkstatt mit einem abgeschlossenen Testraum vor. Der Testraum ist sinnvoll, weil Funken, Staub und Fehler dort bleiben sollen. Wenn du aber versehentlich den Generalschluessel zum ganzen Gebaeude in diesen Testraum legst, hilft das Schloss an der Tuer nur noch begrenzt. Genau das ist die Lektion von WriteOut: Die Sandbox war der Testraum, das Sitzungstoken war der Generalschluessel.

Praktisches Beispiel

Ein Unternehmen betreibt 2.000 Writer-Nutzer und erlaubt Teams, Agenten-Previews intern zu teilen. Ein Angreifer erstellt einen scheinbar nuetzlichen Preview-Agenten, schickt den Link an 50 Zielpersonen und eine angemeldete Fachbereichsleiterin klickt darauf. Wenn ihr Sitzungstoken weitergereicht wird, kann der Angreifer mit ihren Rechten interne Dokumente lesen, einen Agenten-Prompt veraendern und einen Connector pruefen, ohne ihr Passwort zu kennen.

Nach dem Fix sollte genau dieser Weg nicht mehr funktionieren, weil die Session nicht mehr in der Preview-Sandbox landet. Fuer andere Plattformen bleibt die Frage aber offen: Welche Tokens, Secrets oder internen APIs erreichen die Agenten-Runtime ueberhaupt?

Einordnung und Grenzen

• Writer sagt, die Luecke sei behoben und es gebe keine Hinweise auf Kundendatenabfluss. Der Artikel beschreibt deshalb ein Risiko- und Architekturproblem, keinen bekannten laufenden Angriff.
• Es ist kein Beweis, dass jede AI-Sandbox unsicher ist. Es zeigt, dass Sandboxen falsch eingebunden werden koennen, wenn Session- und Origin-Grenzen verschwimmen.
• Ohne detaillierte interne Logs von Writer laesst sich von aussen nicht pruefen, welche Kunden tatsaechlich exponiert waren oder ob einzelne Preview-Links je missbraucht wurden.

SEO- und GEO-Schluesselbegriffe

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