Zwei Meldungen aus dem gleichen Umfeld beschreiben dasselbe Grundproblem aus unterschiedlichen Blickwinkeln. Zum einen musste OpenAI seinen Coding-Assistenten Codex nachbessern, nachdem dieser eigenständig echte Nutzerdateien gelöscht hatte. Zum anderen kommt eine erste Bewertung der Non-Profit-Organisation Guidelight zu dem Schluss, dass kein großer KI-Anbieter grundlegende Kontrollmechanismen für seine eigenen internen KI-Systeme vollständig umsetzt.
Was bei Codex passiert ist
Auslöser war laut Bericht ein Aufräumbefehl, der eigentlich temporäre Arbeitsdateien entfernen sollte. Stattdessen traf er echte Heimverzeichnisse, also die persönlichen Datenordner der Nutzerinnen und Nutzer. Betroffen waren Fälle, in denen das Modell GPT-5.6 Sol eigenständig Löschvorgänge ausführte.
OpenAI hat mit einem Sicherheitsupdate reagiert. Codex prüft Löschziele nun vorab, bevor der Befehl ausgeführt wird. Zusätzlich lässt sich der Vollzugriffsmodus, in dem der Agent ohne einzelne Rückfragen auf das Dateisystem zugreift, nicht mehr versehentlich aktivieren.
Beide Maßnahmen sind aufschlussreich, weil sie kein Modellproblem adressieren, sondern ein Berechtigungsproblem. Der Agent hat nicht falsch "gedacht", er hatte schlicht mehr Rechte, als für die Aufgabe nötig gewesen wären. Genau das ist der Punkt, an dem Projektverantwortliche ansetzen können, ohne auf den nächsten Modellwechsel zu warten.
Die zweite Meldung: Kontrolle ist auch bei den Anbietern lückenhaft
Die Bewertung von Guidelight liefert dazu den größeren Rahmen. Ihr Fazit: Kein KI-Anbieter setzt grundlegende Kontrollmechanismen für die eigenen internen KI-Systeme vollständig um. Details zu Methodik und einzelnen Kriterien gehen aus der vorliegenden Meldung nicht hervor, weshalb sich daraus keine Rangfolge einzelner Unternehmen ableiten lässt.
Als Signal ist die Aussage dennoch relevant. Wer agentische Werkzeuge einsetzt, sollte nicht davon ausgehen, dass die Kontrollarbeit beim Hersteller bereits abschließend erledigt wurde. Die Verantwortung für das, was ein Agent im eigenen Projekt anrichten kann, bleibt im eigenen Haus.
Leitplanken, die sich praktisch umsetzen lassen
Aus beiden Meldungen lässt sich eine nüchterne Arbeitsregel ableiten: Ein Coding-Agent ist ein automatisierter Prozess mit Schreibrechten. Er sollte dieselben Auflagen erfüllen wie jeder andere Automatismus, der Dateien verändert.
- Minimale Berechtigungen. Der Agent erhält Zugriff auf das Projektverzeichnis, nicht auf das gesamte Benutzerkonto. Heimverzeichnisse, Schlüsselspeicher und Zugangsdaten liegen außerhalb seines Wirkungsbereichs.
- Sandbox statt Arbeitsplatz. Eine Sandbox ist eine abgeschottete Ausführungsumgebung, etwa ein Container oder eine virtuelle Maschine. Was dort schiefgeht, bleibt dort.
- Kein Vollzugriff als Standard. Modi, die Rückfragen abschalten, gehören zur bewussten Ausnahme, nicht zur Voreinstellung. Dass OpenAI genau hier nachgeschärft hat, ist ein deutlicher Hinweis.
- Versionskontrolle als Sicherheitsnetz. Änderungen laufen über einen Branch und einen Pull Request, also einen nachvollziehbaren Änderungsvorschlag, der vor der Übernahme geprüft wird. Nicht versionierte Verzeichnisse sind für Agenten tabu.
- Getestete Backups. Eine Sicherung, deren Wiederherstellung nie geprobt wurde, ist keine Sicherung. Das gilt für Dateien ebenso wie für Datenbanken.
- Trennung von Umgebungen. Produktivsysteme, Datenbanken mit echten Kundendaten und Deployment-Zugänge bleiben außerhalb der Reichweite agentischer Werkzeuge.
Review bleibt menschlich
Der Codex-Fall zeigt eine unangenehme Eigenschaft agentischer Systeme: Der schädliche Schritt war kein fehlerhafter Programmcode im Ergebnis, sondern eine Nebenwirkung während der Arbeit. Ein klassisches Code-Review, das nur das Endergebnis betrachtet, hätte ihn nicht verhindert.
Deshalb lohnt es sich, zwei Ebenen zu unterscheiden. Auf der einen Ebene wird geprüft, was der Agent an Code produziert hat. Auf der anderen Ebene wird begrenzt, was er währenddessen überhaupt tun darf. Die zweite Ebene ist technisch zu lösen, nicht durch Aufmerksamkeit.
Hilfreich ist außerdem eine nachvollziehbare Protokollierung: Welche Befehle wurden ausgeführt, welche Dateien geschrieben oder entfernt? Wenn etwas schiefgeht, entscheidet die Qualität dieser Aufzeichnungen darüber, ob der Vorfall in Minuten oder in Tagen aufgeklärt ist.
Kein Argument gegen den Einsatz
Aus dem Vorfall folgt nicht, dass agentische Coding-Werkzeuge im professionellen Umfeld nichts verloren hätten. Der Nutzen bei Routineaufgaben, Migrationen und Testabdeckung ist real, und der Fehler wurde erkannt und behoben. Folgen sollte daraus vielmehr eine sachliche Einstufung: Solche Werkzeuge sind produktive Automatisierung mit Schreibzugriff, und für die gelten seit jeher eigene Regeln.
Bemerkenswert ist die zeitliche Nähe der beiden Meldungen. Während ein Anbieter einen konkreten Kontrollverlust im eigenen Produkt repariert, hält eine externe Bewertung fest, dass die Branche insgesamt bei internen Kontrollmechanismen hinterherhinkt. Beides zusammen spricht dafür, Leitplanken lieber eine Stufe zu eng als eine zu weit zu setzen.
Was das für Web- und Softwareprojekte bedeutet
Wer agentische Werkzeuge in TYPO3- oder Individualprojekten einsetzt, sollte deren Berechtigungen genauso dokumentieren wie die eines Deployment-Users: Wer darf was, in welcher Umgebung, mit welchem Rückweg. In der Praxis lässt sich das mit Container-Umgebungen, konsequenter Versionskontrolle und getesteten Backups ohne großen Zusatzaufwand abbilden. Die entscheidende Frage vor dem Einsatz lautet nicht, wie gut das Modell ist, sondern wie groß der Schaden im schlechtesten Fall wäre — und wie schnell er sich rückgängig machen ließe.