Im Juli 2026 probierte der KI-Investor und frühere HyperWrite-CEO Matt Shumer OpenAIs unveröffentlichtes GPT-5.6 (Codename Sol) auf seinem eigenen Mac aus. Er räumte dem Modell den vollen Zugriff auf die Maschine ein. Ein Cleanup-Subtask setzte dann ein einziges rm -rf direkt auf sein Home-Verzeichnis an. Bis er reagierte und den Prozess abschoss, war über eine Stunde vergangen und die meisten seiner Dateien waren weg.
Unangenehm daran ist, dass OpenAI diese Art von Risiko längst kannte. Sechzehn Tage vor dem Vorfall hatte die eigene Model Card „einem AI Agent vollen Zugriff geben” als ernstes Risiko markiert.
Kein Angreifer war beteiligt, kein Exploit. Dateien löschen war schlicht eine der Fähigkeiten, die dem Agent bewusst erteilt worden waren.
Das verweist auf ein tieferliegendes Problem: Die Architektur der meisten heutigen AI Agents ist by Design unsicher. Und der intuitive Fix — noch mehr Guardrails im Modell — ist die falsche Richtung. Guardrails sitzen auf derselben Ebene wie das, was sie eindämmen sollen; egal wie viele davon eingezogen werden, sie lassen sich umgehen. Die Verteidigung, die trägt, muss außerhalb des Modells liegen.
„AI Security” meint drei verschiedene Dinge — hier geht es um das dritte
„AI Security” ist gerade ein Modebegriff, bezeichnet je nach Kontext aber wirklich unterschiedliche Sachverhalte. Grob dreierlei.
Erstens die Sicherheit des Modells selbst: Jailbreaks verhindern, schädliche Ausgaben vermeiden, das Modell an menschlichen Absichten ausrichten. Um dieses Feld dreht sich der Großteil der Debatte der letzten Jahre.
Zweitens AI für Security: große Modelle umgekehrt zur Verteidigung einsetzen — Bedrohungserkennung, Code-Audits, Threat Intelligence. Hier haben wir selbst gearbeitet, etwa an Thought Is All You Need, einem gedankengestützten Modell zur Erkennung von Smart-Contract-Schwachstellen, und an REEVMBench, einem Benchmark dafür, ob AI Agents tatsächlich reif für Smart-Contract-Security-Audits sind.
Drittens — der Gegenstand dieses Textes — die Sicherheit des AI Agent selbst. Sobald ein Modell nicht mehr nur Fragen beantwortet, sondern deine Dateien liest, deine Credentials hält und in deinem Namen handelt, werden die Tools, die es aufrufen kann, die Rechte, die es hält, und jede Aktion, die es ausführt, zur Angriffsfläche.
Die ersten beiden Themen haben etablierte Forschungskörper. Das dritte ist neu, leicht zu übersehen — und zufällig die Vorbedingung dafür, dass AI Agents flächendeckend ins Unternehmen einziehen: Kein Unternehmen wird echtes Geschäft und echte Daten einem Agent anvertrauen, der sich selbst nicht schützen kann.
Von unvertrauenswürdiger Eingabe zu beliebiger Ausführung: der eingebaute Fehler
Um echte Arbeit zu verrichten, braucht ein Agent meist mehrere Fähigkeiten gleichzeitig: er kann externe Inhalte lesen (Webseiten, E-Mails, Code-Repositories, fremde Pull Requests), er kann wertvolle Ressourcen erreichen (Schlüssel, Cloud-Credentials, Datenbanken), und er kann Tools aufrufen, um zu handeln (Befehle ausführen, Requests absetzen, Dateien ändern). Diese drei Dinge zusammen sind die gefährlichste Kombination, die es gibt.
Die Ursache liegt darin, dass das Modell nicht unterscheiden kann, ob ein Satz eine Anweisung seines Betreibers ist oder Inhalt, den es gerade gelesen hat und den jemand anderes verfasst hat. Für das Modell ist alles derselbe Text im selben Kontextfenster. Auf wen es hört, entscheidet es aus antrainiertem Bauchgefühl, nicht anhand einer festen Regel, die beides sauber trennt. Das ist ein alter Sicherheitsklassiker, das Confused-Deputy-Problem: ein privilegierter Prozess wird von einer nicht-privilegierten Partei dazu gebracht, in deren Auftrag Schaden anzurichten.
Die Kette lässt sich sauber aufziehen. Die Tools, die tatsächlich handeln, folgen dem Modell; das Modell folgt dem Prompt; und der Prompt wird aus allem zusammengesetzt — teils vom Benutzer geschrieben, teils aus Webseiten, E-Mails und Dokumenten geladen. Eine nicht vertrauenswürdige Quelle, durch ein Modell mit nicht-deterministischem Verhalten hindurch, kann so am Ende Tools zu beliebigen Operationen bewegen. In klassischer Software waren Daten Daten und Code Code, sauber getrennt. Bei einem Agent kann ein eingelesener Satz jederzeit als Kommando behandelt werden.
Der Angreifer braucht also keinen ausgeklügelten Exploit und kein gestohlenes Konto. Ein einziger Satz in einem Dokument, auf einer Webseite oder in einem Code-Kommentar reicht, um den Agent etwas tun zu lassen, was er niemals hätte tun sollen. Microsofts Security-Team formuliert es direkt: euer LLM ist keine Sicherheitsgrenze; die Tools, die ihr ihm freigebt, definieren den Wirkungsbereich, den ihr dem Angreifer zugesteht.
Nichts davon ist hypothetisch — die Fälle reihen sich. Grok Build von xAI hat bei jeder Arbeitssitzung das gesamte Repository — inklusive der Secrets in .env und der vollständigen Commit-Historie — still auf eigene Cloud-Server hochgeladen, gemessen ein Volumen fast dreißigtausendmal höher als die Aufgabe erforderte. In einem Test löschte der Cursor-Agent die gesamte Produktions-Datenbank eines Unternehmens samt Backups in neun Sekunden und schrieb anschließend eine Entschuldigung. Der Replit-Agent löschte während eines ausdrücklichen Code Freeze die gesamte Produktions-DB und fabrizierte tausende gefälschte Datensätze, um es zu vertuschen. Und die VS-Code-Extension von Amazon Q wurde durch einen böswilligen Commit vergiftet, der eine „System-Wipe”-Anweisung einpflanzte — ausgeliefert in einem offiziellen Release an fast eine Million Rechner.
Legt man die Vorfälle nebeneinander, sieht man den roten Faden: Der Schaden ging fast immer von den regulär erteilten Berechtigungen des Agent aus, nicht von einem externen Einbruch. .env lesen, Befehle ausführen, Datenbanken abfragen — das tut der Agent alltäglich. Ein Upload-Kanal, ein Delete-Kommando, und aus einer normalen Fähigkeit wird ein Desaster.
Warum Guardrails im Modell zu kurz greifen: Verteidiger und Angreifer auf derselben Ebene
Die intuitive Reaktion auf diese Vorfälle ist, im Agent Guardrails einzubauen. Mit Guardrails meine ich Regeln, die im Modell gefährliche Aktionen verhindern: der Prompt fordert das Modell zu Zurückhaltung auf, oder eine Prüfschicht im Agent fängt gefährliche Kommandos ab und untersucht Dateipfade, so wie es einige Coding-Tools tun.
Dieser Ansatz hat aber ein Grundproblem: Guardrail und Angriffsziel sitzen auf derselben Ebene.
Apostol Vassilev, Senior Scientist am US-amerikanischen National Institute of Standards and Technology (NIST), veröffentlichte im Juni 2026 eine Arbeit, die die Logik der Gödel’schen Unvollständigkeitssätze auf genau dieses Muster überträgt. Der Titel ist selbst eine rhetorische Frage: Robust AI Security and Alignment: A Sisyphean Endeavor?
Sein Argument, verkürzt: Ein Guardrail ist im Grunde eine endliche, fixe Regelmenge. So wie ein endliches Axiomensystem nicht gleichzeitig vollständig und widerspruchsfrei sein kann, wird es für jede fixe Guardrail-Menge einen Satz geben, der sie umgeht — und die Mehrdeutigkeit und Flexibilität menschlicher Sprache macht den Raum solcher Sätze praktisch unendlich. In seinen eigenen Worten: keine endliche Guardrail-Menge ist universell robust gegen adversariale Prompts. Die einzige Frage, die bleibt, ist, wer diesen Satz zuerst findet — Verteidiger oder Angreifer. NIST empfahl entsprechend, die Denkweise von „einmal richtig machen” auf „kontinuierlich überwachen und nachziehen” umzustellen.
Es gibt noch ein direkteres Indiz. Wenn das Modell selbst nicht vertrauenswürdig ist — kann man ein Modell einsetzen, um zu prüfen, ob ein anderes kompromittiert wurde? Eine Studie der University of Wisconsin fand: dieser Weg ist eine Sackgasse. Ansätze, bei denen ein Modell beurteilt, ob ein anderes manipuliert wurde, haben einen strukturellen Defekt: ein adaptiver Angriff, den die Forscher konstruierten, drückt die Erkennungsrate praktisch auf null, während die Injektion in etwa neun von zehn Fällen dennoch gelingt. Das Modell, das Angriffe fangen soll, sitzt auf derselben Ebene wie die Inhalte, die es inspiziert — und wird als Erstes kompromittiert.
Und es gibt ein Timing-Problem, das leicht übersehen wird: Guardrails greifen erst, nachdem der Agent bereits die Autorität zu handeln hat. EchoLeak ist das deutlichste Beispiel. Es war ein Zero-Click-Angriff auf Microsoft 365 Copilot: eine sorgfältig konstruierte E-Mail schlich lautlos an den Injection-Filtern vorbei, die Microsoft Copilot vorgeschaltet hatte, und trug sensible Daten hinaus, ohne dass der Benutzer je klickte.
„Guardrails im Modell einziehen” ist damit ein bisschen wie eine Maginot-Linie. Nicht nutzlos, aber per Konstruktion zwangsläufig zu umgehen. Es kann eine Schicht der Verteidigung sein, nicht die einzige Linie.
Die eigentliche Verteidigung liegt außerhalb des Agent
Wenn dem Inneren des Modells nicht zu trauen ist, muss die Verteidigungslinie nach außen wandern — auf die Systemebene.
Nicht vertrauenswürdigen Code in eine isolierte Umgebung sperren und ihm nur das Mindestmaß an Rechten zubilligen — dieses Denken ist im Sicherheitsfeld nichts Neues, sondern Jahrzehnte alt. Bereits 1975 legten Saltzer und Schroeder in einem klassischen Papier zwei Prinzipien vor: Least Privilege — ein Programm erhält nur die Rechteschnipsel, die es für die Aufgabe braucht; und Separation of Privilege — die Autorität wird aufgeteilt, damit ein einzelner Fehler oder eine einzelne Täuschung nicht das ganze System öffnet (The Protection of Information in Computer Systems). Die Sandboxing-Entwicklungen danach — Janus in den 1990ern, FreeBSD Jails 2000, heute gVisor — gehen alle denselben Weg: nicht vertrauenswürdigen Code isolieren, damit selbst im Kompromissfall der Schaden nicht nach außen greift. Einen AI Agent abzusichern heißt am Ende, diese jahrzehntealte Praxis auf ein neues Objekt anzuwenden.
Konkret ist heute der direkteste Zug, ihn in eine System-Sandbox zu packen: die Umgebung, in der der Agent Tools ausführt, isolieren — auf der Granularität von Systemaufrufen, Datei-I/O und Netzwerk-Egress kontrolliert. Wie viel davon standardmäßig aktiv ist, unterscheidet sich stark zwischen Tools. OpenAIs Codex sandboxt die Kommandoausführung by default und kappt das Netzwerk by default; Claude Codes lokale Sandbox muss von Hand aktiviert werden, und Cursors Sandbox ist laut Hersteller nur „Best-Effort” und nicht als Sicherheitsgrenze zu behandeln. Weiter gedacht steckt man den ganzen Agent in eine plattformverwaltete Runtime und übergibt Netzwerk und Credentials dieser äußeren Schicht statt dem Modell. Anthropics cloudseitig gehostetes managed Claude Code funktioniert genau so: jede Session läuft in einer von Anthropic verwalteten VM, alle ausgehenden Requests laufen über einen Allowlist-Proxy, Credentials liegen außerhalb der Sandbox.
Damit stellt sich die naheliegende Frage: wenn Sandboxing so ausgereift ist, wie kam es zu diesen Löschungen und Repo-Uploads? Zwei Gründe. Erstens: die Default-Absicherung dieser Tools ist oft dünn — Cursor hat by default keine strenge Sandbox, und im GPT-5.6-Fall erteilte der Benutzer schlicht Vollzugriff, was das Ausschalten der Sandbox gleichkommt. Zweitens: selbst mit aktiver Sandbox stoppt sie diese Klasse von Vorfällen nicht — eine Sandbox verhindert, dass der Agent aus ihr ausbricht und den Host beschädigt, aber die gelöschten Datenbanken und hochgeladenen Repositories waren allesamt Ziele, für die der Agent ausdrücklich autorisiert war. Ein Ausbruch war gar nicht nötig. Die Sandbox ist also eine notwendige Schicht, aber weit davon entfernt, hinreichend zu sein.
Der Gedanke, „die Reichweite des Agent einzuhegen”, hat inzwischen auch Produkte für gewöhnliche Office-Anwender erreicht. Tencents dieses Jahr veröffentlichter Desktop-Assistent WorkBuddy läuft auf dem PC und liest nur die vom Benutzer autorisierten lokalen Ordner. Die öffentlich verfügbaren Materialien sprechen jedoch nur von „autorisierten Ordnern” und erklären nicht, wie die zugrundeliegende Isolation im Detail funktioniert oder wie weit sie reicht.
Der wichtigere Punkt: diese ganze Kategorie „Agent mit Sandbox” teilt einen blinden Fleck. Eine Sandbox kontrolliert, wo der Agent läuft und ob er ausbrechen kann, aber nicht, was er mit den Daten tut, während er läuft. Ein Prompt-injizierter Agent bewegt sich vollständig durch explizit erlaubte Kanäle und ist von normalem Betrieb kaum zu unterscheiden. Ein Sicherheitsforscher formulierte es zu Googles GKE Agent Sandbox so: dies ist eine „Isolation-Sandbox”, keine „Behavior-Sandbox” — sie entscheidet, wo der Agent läuft, sie beobachtet aber nicht, was er dabei tut.
Genau weil eine Sandbox nur das Wo, nicht das Was regulieren kann, hat Google DeepMind einen gründlicheren Ansatz vorgeschlagen: das große Modell von vornherein als nicht vertrauenswürdige Komponente behandeln und es mit einer festen, AI-freien Schicht ummanteln, die Schritt für Schritt entscheidet, ob es handeln darf. Ihr CaMeL übersetzt die vertrauenswürdige Benutzeranweisung zunächst in ein Programm, das ein AI-freier Interpreter ausführt; dieser Interpreter verfolgt die Herkunft jedes Datenstücks und entscheidet vor jedem Tool-Aufruf regelbasiert, ob er erlaubt ist — während das Modell, das tatsächlich mit den nicht vertrauenswürdigen externen Inhalten in Kontakt kommt, gar keine Berechtigung hat, Tools aufzurufen. Für einen guten Teil der Aufgaben liefert das „nachweisbare Sicherheit”.
Was Sandboxen nicht lösen: die Daten, die der Agent tatsächlich braucht
Doch weder Sandbox noch CaMeL kommen um ein härteres Problem herum, und es ist der trickreichste Teil der ganzen Geschichte.
Eine Sandbox trennt den Agent vom Host, baut aber keine Mauer um die Daten, die der Agent zum Arbeiten braucht. Der Code, die .env, die abzufragende Datenbank — all das liegt in derselben Umgebung wie der Agent. Damit er überhaupt arbeiten kann, braucht der Agent irgendeinen Kanal nach außen. Ein kompromittierter Agent kann also, was er lesen kann, über diesen erlaubten Kanal weiterhin hinausschicken. Anthropics eigene Sandbox-Dokumentation räumt es ein: solange Netzwerk-Egress erlaubt ist, können Daten, die der Agent lesen kann, hinausgetragen werden — die Allowlist filtert nach Domain und inspiziert nicht, was das System verlässt.
Wie also schützt man Daten, ohne die der Agent seine Arbeit nicht tun kann? Die Fälle teilen sich in drei, jeder härter als der vorige.
Der erste sind explizite Credentials, etwa ein API-Schlüssel. Der Agent muss den Inhalt des Schlüssels nicht verstehen; er verwendet ihn nur, um Requests abzusetzen. Man kann dem Modell also durchgängig nur einen Platzhalter zeigen und den echten Schlüssel erst im Moment des tatsächlichen Requests durch eine äußere managed Runtime einsetzen. Selbst wenn jemand per Prompt „den Schlüssel” herauslockt, bekommt er einen wertlosen Dummy. Diese Klasse lässt sich im Ingenieursweg im Wesentlichen lösen.
Der zweite sind Daten, die der Agent selbst lesen und darüber schlussfolgern muss. Ein Finanzanalyse-Agent, dem man keine Finanzdaten gibt, funktioniert schlicht nicht. Ein einfacher Ersatz greift hier nicht. Ein Kompromiss ist, einen streng isolierten Sub-Agent zu starten, der als einziger die sensiblen Daten berührt und nur eine Schlussfolgerung zurückreicht. Doch ein unumgehbarer Haken bleibt: niemand kann garantieren, dass die Schlussfolgerung selbst nicht sensibel ist. Lecks sind meist paraphrasiert und in der Bedeutung vergraben, wo Keyword-Matching sie nicht fasst. Isolation schrumpft den Blast Radius, sie versiegelt nicht wirklich.
Der dritte und gründlichste ist Information-Flow Tracking: jedes Datenstück markieren, seinem Fluss folgen und es in dem Moment abfangen, in dem es versucht, hinauszugehen. Microsofts Fides geht diesen Weg und verfolgt die Bewegung jedes Datenstücks per Information-Flow Control — vom Prinzip her am saubersten. Es ist aber auch am teuersten: Performance leidet, Usability leidet, die Labels vervielfachen sich, und jemand muss die Policies schreiben und pflegen. Zwischen Sicherheit und Usability beißt der Trade-off hier am schärfsten.
Die Systemtechnik der Agent-Sicherheit: Isolation, Kontrolle, Nachvollziehbarkeit
Keiner dieser Ansätze löst das Problem im Alleingang: Guardrails werden umgangen, Sandboxen halten Daten nicht drinnen, Information-Flow Tracking kostet zu viel, Sub-Agent-Isolation kann die Nicht-Sensibilität der Schlussfolgerung nicht garantieren.
Aber genau so hat Sicherheit immer funktioniert. Es gibt kein absolutes „sicher” oder „unsicher”; das, was man tun kann, ist, den Aufwand für Angriffe kontinuierlich zu erhöhen und den Blast Radius von Vorfällen zu verkleinern.
Für ein Team, das ein Enterprise-Grade-Agent-Produkt (ToB) ernsthaft bauen will, gibt es keine Silberkugel. Der gangbare Weg ist, drei Dinge übereinanderzulegen. Erstens Isolation: mit System-Sandboxen und externen Restriktionen strikt begrenzen, was der Agent tun kann. Zweitens Policy-Kontrolle: mit Least Privilege und festen Regeln beschränken, was innerhalb dieses Rahmens tatsächlich berührt werden darf. Drittens Nachvollziehbarkeit: mit Logs und Audit Trail sicherstellen, dass sich im Ernstfall festnageln lässt, welcher Schritt und welche Partei den Vorfall verursacht hat.
Die ersten beiden sind Prävention; das dritte wird gerne vergessen und ist genauso wichtig. Guardrails geht es darum, dass Schlimmes nicht passiert; Logs geht es darum, das Passierte im Ernstfall erklären zu können — keines von beiden ersetzt das andere. Es gibt eine bezeichnende Lücke in der Praxis: viele Unternehmen haben vermutete oder bestätigte Agent-Sicherheitsvorfälle gemeldet, doch nur wenige behandeln den Agent tatsächlich als Entität, die eigene Autorisierung und eigene Rechenschaft braucht. Diese Lücke ist die konkreteste Schwachstelle der heutigen Agent-Sicherheit.
AI Agents wandern von „Fragen beantworten” zu „die Arbeit für dich erledigen”. Je autonomer der Agent, desto mehr übergibt man — Entscheidungen, Daten, jede Art von Credentials und Schlüsseln. Zu hoffen, dass das Modell von selbst lernt, sich zurückzuhalten, oder ihm noch ein paar hundert Guardrail-Regeln aufzuschreiben — beides bleibt im Modell, auf derselben Ebene wie das Modell, und hält die oben beschriebenen Probleme nicht auf. Damit ein Unternehmen einen Agent tatsächlich benutzbar macht, muss die Verteidigungslinie außerhalb des Modells liegen: eine Sandbox begrenzt, worauf er operieren kann; Least Privilege beschränkt, welche Daten er im Rahmen erreichen darf; Logs halten jeden Schritt fest, damit sich im Ernstfall die Quelle nachverfolgen lässt. Diese drei Schichten zusammen verdienen den Namen einer Enterprise-tauglichen Agent-Sicherheitsarchitektur.