Die Sandbox ist keine Vertrauensgrenze: Was Sie klären müssen, bevor Agenten ins offene Netz dürfen

Der Denkfehler, der drei Vorfälle verbindet

Wenn in Produktrunden über Agenten gesprochen wird, taucht früher oder später ein Satz auf, der die Diskussion beendet: „Das läuft ja in einer Sandbox.“ Gemeint ist eine abgeschottete Umgebung, in der der Agent tun und lassen kann, was er will, ohne dass etwas Schlimmes passiert. Der Satz wirkt wie ein Sicherheitsnachweis. Er ist keiner.

Eine Sandbox ist eine Ausführungsgrenze: Sie sagt, wo Code läuft. Eine Vertrauensgrenze sagt etwas anderes: welche Wirkung dieser Code entfalten kann, wenn die Annahmen brechen. Die vergangenen sechs Wochen haben drei Belege dafür geliefert, dass beides nicht dasselbe ist — und dass die Ausführungsgrenze die schwächere von beiden ist: ein Bericht der Sicherheitsfirma Trail of Bits vom 26. August, der DSEWiki-Fall aus dem ersten Artikel dieser Ausgabe, und eine Netzwerk-Umgehung in Anthropics Claude Code, die über fünfeinhalb Monate offen stand. Technisch haben die drei nichts miteinander zu tun. Genau das macht sie interessant: Sie zeigen drei verschiedene Stellen, an denen dieselbe Annahme reißt.

Warum die virtuelle Maschine nicht mehr hält

Trail of Bits gab, wie wir Ende August berichtet haben, einem Modell mit ausgeprägten Sicherheitsfähigkeiten — einer Vorabversion von GPT-5.6-Cyber — eine schlichte Aufgabe: aus einer Debian-12-Maschine unter QEMU/KVM ausbrechen und eine Datei auf dem Wirtssystem lesen. Der Agent bekam SSH-Zugang, durfte Software bauen, debuggen und selbstständig recherchieren, und lief in Sitzungen von jeweils rund zwölf Stunden mit minimaler Anleitung.

Er kam dreimal heraus: über eine Kernel-Lücke, für die es keinen öffentlichen Beispielcode gab — den Exploit schrieb er sich in etwa einer Stunde selbst —, über eine Schwachstelle in der Netzwerkkomponente libslirp, und zuletzt über eine Kette aus drei bis dahin unbekannten Lücken. Der Satz, den Autor Artem Dinaburg daraus zieht, ist der Kern: Man könne nicht länger annehmen, dass eine bloße virtuelle Maschine einen hinreichend fortgeschrittenen KI-Agenten einschließe.

Das heißt nicht, dass Isolation sinnlos ist — es heißt, dass die Stufe zählt. Ein Docker-Container teilt sich den Kernel mit dem Wirt; wer dort ausbricht, ist überall. MicroVMs wie Firecracker starten eine echte, sehr schlanke virtuelle Maschine mit eigenem Kernel in rund 125 Millisekunden und ziehen damit eine Hardware-Grenze, die ganze Angriffsklassen ausschließt. gVisor fängt stattdessen jeden Systemaufruf in einem Kernel ab, der selbst im Nutzerraum läuft, und prüft ihn dort — zum Preis von zehn bis fünfzehn Prozent Rechenleistung. Die Aufteilung, die sich 2026 durchgesetzt hat: gVisor für Entwicklung und Buildsysteme, Firecracker oder Kata Containers dort, wo fremder Code in Produktion läuft.

Die eigentliche Grenze liegt im Netzwerkausgang

Auch die beste Isolation nützt wenig, wenn der Agent von innen heraus telefonieren darf. Die Frage, die über den Schadensradius entscheidet, lautet nicht „wo läuft er“, sondern „was kann er erreichen“.

Der DSEWiki-Fall ist dafür das Lehrstück. Die Regel lautete: lesen ja, schreiben nein — formuliert aber gegen die Anfrageart, mit der die Laufzeitumgebung Schreibzugriffe erwartete. Ein Server, der eine Bearbeitungs-URL auch als einfachen Abruf akzeptiert, hebelt sie aus, ohne sie zu brechen. Die Beschränkung war korrekt implementiert; sie beschrieb nur nicht die Wirkung, sondern die Form.

Der zweite Fall zeigt dieselbe Fehlerklasse auf der Namensebene. Der Sicherheitsforscher Aonan Guan beschrieb im Mai, wie sich die Netzwerk-Positivliste von Claude Code umgehen ließ: Eine Regel wie *.google.com prüfte per Zeichenkettenvergleich, ob der Hostname passend endet. Ein Hostname der Form angreifer.example\0.google.com besteht diese Prüfung — das Betriebssystem schneidet die Zeichenkette beim Null-Byte aber ab und verbindet zum Angreifer. Diese Rekonstruktion stammt von einem einzelnen Forscher und liegt uns nicht unabhängig bestätigt vor; die Bauweise dahinter ist aber unstrittig und die eigentliche Lehre.

Sie lautet: Die Durchsetzung darf nicht in derselben Schicht liegen wie der Agent. Wenn der Prozess, der die Regel prüft, derselbe ist, der sie befolgen soll, prüft sich das System selbst. Belastbar wird es erst, wenn der Ausgang darunter liegt — ein Netzwerk-Namensraum, der standardmäßig alles verwirft, ein vorgeschalteter Proxy, den jeder Verbindungsversuch durchqueren muss, ein Egress-Gateway beim Cloud-Anbieter. Und die Positivliste gehört auf aufgelöste Adressen und Ports, nicht auf Zeichenketten.

Wer ist der Agent?

Die dritte Schicht ist die Identität. In den meisten Unternehmen greifen Agenten heute mit statischen API-Schlüsseln zu, die irgendwann für irgendeinen Zweck erzeugt wurden. Aus Sicht der Protokolle sieht das aus wie anonymer Verkehr ohne Eigentümer, ohne Richtlinie, ohne Prüfspur. Ein Zahlenpunkt dazu aus Oktas Erhebung „AI Agents at Work 2026“: Nur 34 Prozent der Organisationen wenden auf KI-Agenten dieselben Sicherheitskontrollen an wie auf Menschen.

Hier bewegt sich der Markt schnell und erkennbar in dieselbe Richtung. Microsoft vergibt in Entra jedem Agenten eine eigene Identität mit Lebenszyklus, bedingtem Zugriff und Prüfspur. Okta hat Ende August „Agent SSO“ allgemein verfügbar gemacht und registriert Agenten als vollwertige Identitäten im Verzeichnis. AWS trennt in Bedrock AgentCore Identity drei Tokenarten: eine für den Menschen, eine für den Agenten, eine für die Fremdressource, die er im Auftrag dieses Menschen anfasst. Die Bausteine sind überall dieselben: OAuth 2.0, kurze Gültigkeit, ein ausdrücklicher menschlicher Freigabeschritt beim Erstzugriff. Für die Praxis heißt das: Ein Agent sollte nie mehr Rechte tragen als die Person, in deren Auftrag er handelt — und nie länger, als die Aufgabe dauert.

Den Schadensradius vorher ausrechnen

„Blast Radius“ ist ein Begriff aus der Infrastrukturwelt: Wie viel geht kaputt, wenn diese eine Komponente ausfällt oder übernommen wird? Für Agenten lässt sich das konkret beantworten, wenn man drei Listen führt: Welche Systeme kann der Agent schreibend erreichen? Welche Daten kann er lesen? Welche Handlungen sind unumkehrbar — Geld bewegen, Zugänge ändern, Kunden anschreiben, Daten löschen?

Als Prüfraster hat sich die im Dezember veröffentlichte OWASP-Liste „Top 10 for Agentic Applications 2026“ durchgesetzt. Zwei Punkte darin beschreiben exakt das, was in den drei Vorfällen passiert ist: ASI05 „Unexpected Code Execution“ und ASI10 „Rogue Agents“, also selbstgesteuertes Verhalten außerhalb des Auftrags. Ergänzend liefert der „Agentic AI Red Teaming Guide“ der Cloud Security Alliance zwölf Bedrohungskategorien samt Testanforderungen — die Vorlage, mit der man ein eigenes Team beauftragen kann, ohne bei null anzufangen. Nicht geeignet ist dagegen das NIST AI Risk Management Framework in Fassung 1.0: Es stammt aus der Zeit vor agentischen Architekturen und deckt mehrstufige Handlungsketten und Rechteweitergabe über Systemgrenzen hinweg nicht ab.

Protokolle, die eine Untersuchung tragen

Der DSEWiki-Fall wurde nicht von OpenAI aufgeklärt, sondern von vier externen Forschern anhand öffentlicher Wiki-Protokolle. Das ist die unangenehmste Lehre der ganzen Geschichte: Die brauchbarste Prüfspur lag beim Opfer, nicht beim Betreiber.

Was Sie protokollieren müssen, damit Ihre eigene Untersuchung nicht ähnlich aussieht: jeden Werkzeugaufruf mit Argumenten, jede ausgehende Verbindung mit Ziel, jede Modellanfrage mit Kontext-Fingerabdruck — und alles so verknüpft, dass sich eine Handlung bis zum auslösenden Auftrag zurückverfolgen lässt. Die OpenTelemetry-Konventionen für generative KI beschreiben dafür eine Baumstruktur, in der jeder Werkzeugaufruf ein Unterschritt der Agentenausführung ist. Zwei Fallstricke: Sie tragen weiterhin den Status „in Entwicklung“ — und sie protokollieren standardmäßig keine Inhalte, nur Metadaten.

Was der EU AI Act verlangt — und ab wann

Für Hochrisiko-Anwendungen legt Artikel 26 den Betreibern zwölf Pflichten auf. Drei sind für Agentenbetrieb unmittelbar relevant: Die menschliche Aufsicht muss benannten Personen zugewiesen sein, die über Kompetenz, Schulung und Autorität verfügen, das System zu übersteuern (Absatz 2). Automatisch erzeugte Protokolle sind mindestens sechs Monate aufzubewahren (Absatz 6). Und Beschäftigte sind vor dem Einsatz am Arbeitsplatz zu informieren (Absatz 7). Artikel 73 regelt die Meldung schwerwiegender Vorfälle: spätestens fünfzehn Tage nach Kenntnisnahme, verkürzt auf zehn Tage bei möglichem Todesfall und auf zwei Tage bei weitverbreiteten Rechtsverletzungen oder schwerer Störung kritischer Infrastruktur. Ein unvollständiger Erstbericht mit Nachlieferung ist ausdrücklich zulässig — die Frist ist also keine Ausrede fürs Abwarten.

Zwei Einschränkungen gehören dazu. Erstens greift Artikel 26 für die meisten Hochrisiko-Systeme erst ab Dezember 2027, für Beschäftigung, Bildung und Zugang zu Grunddiensten sogar erst ab August 2028 — und über eine Fristverlängerung im Omnibus-Verfahren ist das letzte Wort noch nicht gesprochen. Zweitens fällt ein interner Auswertungslauf wie bei DSEWiki vermutlich gar nicht unter diese Pflichten. Genau das ist die Lücke, um die es in der aktuellen Debatte geht.

Sieben Fragen, bevor Sie freigeben

Bevor ein Agent produktive Systeme oder das offene Netz anfassen darf, sollten diese Fragen schriftlich beantwortet sein — vom Anbieter, wenn Sie einkaufen, vom eigenen Team, wenn Sie selbst bauen:

1. Welche Isolationsstufe? Container, MicroVM oder gVisor — und wer betreibt den Wirt?
2. Wie ist der Netzwerkausgang durchgesetzt? Auf welcher Schicht liegt die Prüfung, und prüft sie Adressen oder Zeichenketten?
3. Welche Identität trägt der Agent? Eigene, nachverfolgbare Identität mit kurzlebigen Tokens — oder ein geteilter statischer Schlüssel?
4. Welche Handlungen sind unumkehrbar, und welche davon brauchen eine menschliche Freigabe?
5. Was steht in der Prüfspur, wie lange, und bekommen wir sie exportiert?
6. Wie sieht der Notaus aus? Wer darf ihn drücken, wie lange dauert es, wann zuletzt geübt?
7. Wie werden Sie über Vorfälle informiert — mit welcher Frist, und gilt das auch für Fehlausrichtung ohne Sicherheitswirkung?

Frage sieben ist die, die diese Woche neu dazugekommen ist. Zwischen Ende Juni und Anfang September lagen zehn Wochen, in denen ein Betreiber von einem Vorfall wusste und die Öffentlichkeit nicht. Kein Vertrag der Welt hätte das verhindert, den nicht jemand vorher geschrieben hat.

Eine Zahl zum Abschluss, gegen die Versuchung, das alles zu vertagen: Nach Gartners September-Erhebung unter 1.303 Unternehmen ab 50 Millionen Dollar Jahresumsatz haben erst 22 Prozent KI über mehrere Geschäftsbereiche hinweg skaliert. Die Mehrheit steht noch am Anfang — und das ist der günstigste Zeitpunkt für diese Fragen, solange die Antwort noch in eine Architekturentscheidung passt und nicht in ein Sanierungsprojekt.