Wir sind es gewohnt, über KI in der Cybersicherheit aus einem Blickwinkel zu lesen: ein Angreifer, der Agenten einsetzt, um schneller vorzugehen. Der zweite Blickwinkel ist für Ihre Organisation wichtiger und erhält weit weniger Aufmerksamkeit. Der Agent, den Sie auf dem Rechner Ihres eigenen Entwicklers ausführen, ist selbst eine neue Angriffsfläche. Innerhalb von zwei Monaten haben drei unabhängige Forschungsgruppen Ergebnisse veröffentlicht, die alle in dieselbe Richtung weisen.

Was diese Fälle gemeinsam haben, ist kein Fehler im Modell und keine schlechte Antwort. Der Agent ist nie aus seiner Sandbox ausgebrochen und hat nie gegen eine Regel verstoßen. Geschehen ist Folgendes: Der Agent hat eine Datei innerhalb des Projekts gelesen oder geschrieben, und danach hat ein vertrauenswürdiges Werkzeug, das außerhalb der Sandbox läuft, den Inhalt dieser Datei ausgeführt. Die Sandbox hat gehalten. Die Kompromittierung ging an ihr vorbei.

Der Mechanismus: eine jahrealte Git-Performance-Einstellung

Das deutlichste Beispiel veröffentlichte Manifold Security am 2. September 2026 unter dem Namen GitSpawn. Es dreht sich um eine projektbezogene Git-Einstellung namens core.fsmonitor, eine legitime und dokumentierte Performance-Option, deren Wert ein Befehl ist, den Git ausführt, um geänderte Dateien schnell zu erkennen, statt das gesamte Verzeichnis zu durchsuchen.

Nun fügen Sie die beiden Hälften zusammen:

  • Ein KI-Coding-Agent führt, sobald er mit der Arbeit an einem Projekt beginnt, automatisch Git-Befehle wie git status und git diff aus, um den Zustand des Repositorys zu verstehen. Das ist normales und notwendiges Verhalten.
  • Enthält das Repository einen bösartigen core.fsmonitor-Wert, führt schon das bloße Ausführen dieser Befehle den Angreiferbefehl aus.

Das Ergebnis: Das Öffnen eines Code-Repositorys ist kein Lesevorgang mehr, sondern wird zu einem Ausführungsvorgang. Kein Klick, keine Freigabe, keine Abfrage für den Entwickler. Laut dem Bericht waren acht Kommandozeilen-Agenten betroffen, und für mehrere folgten Patches: goose in 1.44.0, Claude Code in 2.1.196 für den core.fsmonitor-Pfad, Codex CLI in 0.131.0 sowie Cursor. Der Bericht nannte vier Pfade, die zum Zeitpunkt der Veröffentlichung noch nicht gepatcht waren. Die Klasse wurde unter Kennungen wie CVE-2026-72718, CVE-2026-19592 und CVE-2026-55607 erfasst.

Kein Einzelfall, sondern eine ganze Klasse

Sechs Wochen vor GitSpawn veröffentlichten Forscher von Pillar Security am 20. Juli 2026 eine Serie, die sie eine Woche der Sandbox-Ausbrüche nannten, und dokumentierten darin sieben Schwachstellen in vier Coding-Agenten von drei Anbietern: Cursor, Codex, Gemini CLI und Antigravity. Ihre Beschreibung des Mechanismus lohnt sich, zweimal gelesen zu werden. Der Agent bleibt in der Box und befolgt jede Regel. Er schreibt lediglich eine Datei, die ein vertrauenswürdiges Werkzeug außerhalb der Box später ausführt, lädt oder scannt.

  • In Cursor ermöglichte eine vom Workspace gesteuerte Hook-Konfigurationsdatei die Ausführung außerhalb der Sandbox, erfasst als CVE-2026-48124 und behoben in Version 3.0.0.
  • In Codex CLI vertraute die Befehls-Allowlist git show allein anhand des Namens, obwohl die übergebenen Parameter es zu mehr als einem reinen Lesebefehl machen können. Behoben in Version 0.95.0.
  • Ein Problem mit dem Docker-Socket betraf Codex, Cursor und Gemini CLI gleichzeitig.
  • In Antigravity eine Umgehung der Seatbelt-Denylist von macOS und ein Problem mit der Aufgabenkonfiguration des Editors, die Google beide als schwer ausnutzbar einstufte.

Am 10. September 2026 berichtete Upstarts Media dann über eine dritte Meldung, von einem Startup namens Accomplish, zu undichten Sandboxes in Claude Code, Codex und Cursor. Die interessante Zahl dort ist nicht die Schwachstelle, sondern die Zeit bis zur Behebung: Das Cursor-Problem wurde in etwa einer Woche gelöst, zwei OpenAI-Probleme im August, während das Anthropic-Problem rund fünfzig Tage über Dutzende Releases hinweg dauerte. Drei Forschungsgruppen, drei Berichte, zwei Monate, ein Muster.

Warum das wichtig ist, auch wenn Sie nie Code schreiben

Weil das Risiko nicht beim Agenten landet. Es landet bei dem Rechner, auf dem er läuft, und bei dem Netzwerk, in dem sich dieser Rechner befindet. Ein Entwickler-Arbeitsplatz gehört zu den Geräten mit den meisten Berechtigungen in jedem Unternehmen: Er enthält Zugangsschlüssel zu Servern, Deployment-Tokens und oft eine offene Verbindung zu einer Produktionsdatenbank. Einen einzigen Befehl darauf auszuführen, ist kein kleines Ereignis.

Das Szenario ist auf dem saudischen Markt nicht theoretisch. Gleichen Sie diese Fälle mit Ihrem eigenen Unternehmen ab:

  • Ein externer Auftragnehmer oder eine Entwicklungsagentur liefert Code, den Ihr Team dann mit einem KI-Agenten auf einem Rechner innerhalb Ihres Netzwerks öffnet.
  • Ein Open-Source-Projekt, das ein Entwickler herunterlädt, um eine Bibliothek oder einen schnellen Fix auszuprobieren.
  • Eine per E-Mail oder WhatsApp gesendete Datei eines Lieferanten, entpackt und direkt im Editor geöffnet.
  • Ein Stellenbewerber, der ein Beispielprojekt einreicht, das ein technischer Prüfer öffnet.
  • Ein alter Branch oder ein übertragenes Repository, übergeben bei einer Übernahme oder einer Projektübergabe.

In jedem dieser Fälle lautet die unausgesprochene Annahme, dass das Öffnen von Dateien zum Lesen eine sichere Handlung ist. Genau diese Annahme ist zerbrochen.

Was Sie diese Woche tun sollten

Fünf Schritte, und der erste braucht kein Budget:

  1. Aktualisieren Sie heute die Agenten-Werkzeuge im gesamten Team. Für die meisten dieser Werkzeuge gibt es Patches, und der Wert liegt darin, dass alle auf einer gepatchten Version sind, nicht nur eine Person. Beginnen Sie damit, zu wissen, wer was in welcher Version nutzt, denn gerade diese Bestandsaufnahme fehlt meist.
  2. Behandeln Sie eingehenden Code als nicht vertrauenswürdigen Inhalt. Code von einem Auftragnehmer oder aus einer offenen Quelle ist kein Dokument, das Sie lesen, sondern etwas, das ausgeführt wird. Öffnen Sie ihn beim ersten Mal auf einem Rechner oder in einem Container, der vom Arbeitsnetzwerk getrennt ist.
  3. Trennen Sie den Entwicklungsrechner von den Produktionsschlüsseln. Bewahren Sie keine Live-Server-Tokens auf dem Rechner auf, auf dem Projekte aus externen Quellen geöffnet werden. Der Schaden bleibt dann auf dieses Gerät beschränkt.
  4. Leiten Sie das Deployment über eine zentrale Pipeline, nicht über einen persönlichen Laptop. Wenn das Deployment über eine einzige Build-Pipeline mit eng gefassten Berechtigungen läuft, ist die Kompromittierung eines einzelnen Rechners kein Weg mehr in die Produktion.
  5. Ergänzen Sie Verträge über ausgelagerte Entwicklung um eine Klausel. Sie haben das Recht festzulegen, wie Code geliefert wird und aus welchem Repository, und vom Dienstleister zu verlangen, seine Werkzeuge aktuell zu halten. Das ist eine Vertragsbedingung, keine technische Debatte.

Vor Ort ist nichts davon eine optionale gute Praxis. Die von der Nationalen Cybersicherheitsbehörde (NCA) herausgegebenen Essential Cybersecurity Controls enthalten ausdrückliche Bereiche für Endpoint-Sicherheit, Sicherheit im Änderungs- und Entwicklungsmanagement sowie die Sicherheit von Drittparteien, während die Verantwortung für den Schutz personenbezogener Daten nach dem Gesetz zum Schutz personenbezogener Daten (PDPL) bei der Organisation bleibt. Wenn sich die Tür über den Rechner eines Entwicklers geöffnet hat, der ein Projekt eines Dienstleisters geöffnet hat, verringert das die Haftung nicht.

Die Sicht von Origami

Wir lesen diese drei Berichte als Korrektur einer Vorstellung, die sich schnell verbreitet hat: dass eine Sandbox genügt, solange der Agent darin eingeschlossen ist. Diese Schwachstellen haben die Isolation nicht durchbrochen. Sie nutzten eine legitime Brücke, die etwas, das innerhalb der Box geschrieben wurde, zu einem Werkzeug trägt, das außerhalb läuft. Die richtige Frage lautet also nicht, ob der Agent in einer Sandbox läuft, sondern welche Werkzeuge lesen, was der Agent erzeugt, und mit welchen Berechtigungen diese Werkzeuge laufen.

Eine praktische Beobachtung aus dem, was wir bei Kunden sehen: Die Einführung von KI-Werkzeugen in Entwicklungsteams ist jeder Richtlinie, die sie regelt, um Monate voraus. Ein Entwickler probiert ein Werkzeug aus, es gefällt ihm, und es wird Teil des täglichen Arbeitsablaufs ohne Entscheidung, ohne Prüfung und ohne Bestandsaufnahme. Das Problem ist nicht das Werkzeug. Das Problem ist, dass es durch eine Tür hereingekommen ist, die niemand bewacht. Wenn wir Kundenumgebungen prüfen, beginnen wir genau hier: welche Werkzeuge tatsächlich auf den Rechnern des Teams laufen, mit welchen Berechtigungen, und was passiert, wenn heute Nacht auf einem davon ein Befehl ausgeführt wird. Wenn Sie eine Prüfung aus diesem Blickwinkel wünschen, finden Sie uns auf der Kontaktseite.

Das Fazit

Drei unabhängige Meldungen in zwei Monaten sagen dasselbe: Ein KI-Coding-Agent macht das Öffnen eines Projekts von einem Lesevorgang zu einer Ausführung, und dafür genügt es, dass ein Außenstehender eine Zeile in eine Konfigurationsdatei setzt. Für die meisten Werkzeuge wurden Patches ausgeliefert, einige Pfade blieben offen, doch die Lehre überdauert jedes Release. Jedes Werkzeug, das Sie auf einem Rechner mit hohen Berechtigungen ausführen, ist Teil Ihrer Angriffsfläche, ob Ihre Richtlinien es aufführen oder nicht. Beginnen Sie mit einer Frage: Wer in Ihrem Team führt gerade einen KI-Agenten aus, auf welchem Rechner und in welcher Version?

Quellen