700 GB an Daten wurden von Claude mit einem einzigen Klick gelöscht, der CTO ist fassungslos: Er wollte die KI nur dazu bringen, nutzlose Dateien zu löschen, aber am Ende waren alle Arbeitsergebnisse einer ganzen Woche verschwunden...

Vor kurzem erlebte der Entwickler Sebastien Guillemot einen erschreckenden Zwischenfall:

Er wollte eigentlich nur Claude dazu bringen, ein Skript zu schreiben, das automatisch Junk-Dateien löscht, die von AI Agents im Verzeichnis /tmp hinterlassen werden. Doch nach einer „Sicherheitsprüfung“ hat die KI sein gesamtes Home-Verzeichnis gelöscht – 700 GB Daten, die Arbeitsergebnisse einer ganzen Woche, waren einfach weg.

Noch ironischer ist, dass das /tmp-Verzeichnis, das er ursprünglich säubern wollte, von Claude am Ende „perfekt“ erhalten blieb.

Der ganze Vorfall begann nur damit, dass AI Agents zu gerne „Junk-Daten hinterlassen“

Als CTO der Stiftung des datenschutzorientierten Blockchain-Projekts Midnight ist Guillemot im Alltag ein starker Nutzer von AI Agents und ruft während der Entwicklung häufig verschiedene KI-Programmierassistenten auf. Doch er stellte fest, dass diese Agents ein gemeinsames Problem haben:

Sie arbeiten sehr eifrig, aber die Abschlussbearbeitung ist zufällig – eine große Anzahl temporärer Dateien sammelt sich im Verzeichnis /tmp an. Mit der Zeit belegen sie nicht nur Speicherplatz, sondern machen auch die gesamte Entwicklungsumgebung zunehmend unübersichtlich.

Daher bat er Claude Fable 5, ein automatisches Bereinigungsskript zu erstellen: Jeder Agent erhält ein eigenes, separates /tmp-Verzeichnis, und nach Abschluss der Aufgabe werden alle zugehörigen temporären Dateien gemeinsam gelöscht.

Das klingt einfach, aber die eigentliche Schwierigkeit besteht darin, keine Dateien versehentlich zu löschen, die noch verwendet werden.

Die ursprüngliche Lösung von Fable bestand darin, zu prüfen, ob der Agent noch ausgeführt wird. Wenn ein Agent noch arbeitet, sollte das zugehörige Verzeichnis vorläufig nicht bereinigt werden. Guillemot fand diesen Code jedoch zu kompliziert und forderte Claude auf, ihn weiter zu vereinfachen.

Bis zu diesem Punkt verlief alles noch normal – das Problem trat bei der anschließenden Sicherheitsprüfung auf.

Da die Aufgabe echte Dateilöschvorgänge umfasst, führte Fable freiwillig eine „adversariale Prüfung“ durch, d. h. eine andere Claude-Instanz prüfte, ob der Code Sicherheitslücken aufweist.

Genau in diesem Schritt wurde der eingebaute Sicherheitsherabsetzungsmechanismus von Anthropic ausgelöst: Wenn das System feststellt, dass die Aufgabe sensible Vorgänge wie Dateilöschung oder Cybersicherheit umfasst, wird das Modell automatisch von einer höheren Version auf eine konservativere Version herabgestuft. Dieser Mechanismus soll die Wahrscheinlichkeit verringern, dass das Modell in Hochrisikoszenarien zu „aggressiv“ handelt.

Daher wurde zuerst das Modell von Fable 5 auf Opus 5 und dann weiter auf Opus 4.8 herabgestuft.

Der ironischste Moment: Die Sicherheitsprüfung wurde tatsächlich bestanden

Anschließend begann Opus 4.8 mit der Durchführung der Sicherheitsprüfung. Das Ziel der Prüfung war sehr klar: Es sollte geprüft werden, auf welchen Pfad der Löschbefehl letztendlich verweist. Wenn das Ziel als /tmp oder das Home-Verzeichnis des Benutzers erkannt wird, sollte die Ausführung verweigert werden.

Und das Ergebnis? Die Prüfung war erfolgreich, sowohl /tmp als auch das Home-Verzeichnis wurden korrekt als „gefährliches Ziel, nicht löschbar“ erkannt.

Aus Sicht der Sicherheitsprüfung selbst hat das Modell in diesem Schritt keinen Fehler gemacht. Das Problem liegt jedoch darin, dass nach Ende der Prüfung ein Schritt zur „Bereinigung der Testumgebung“ folgt – und die Katastrophe verbirgt sich genau in diesem Bereinigungsschritt:

Im Testcode wurde eine Variable verwendet, um das Löschziel zu speichern. Nachdem die Sicherheitsprüfung das Ziel als gefährlich eingestuft hatte, löste das Programm den Beendigungsablauf aus. Gleichzeitig ruft der Beendigungsablauf eine Bereinigungsfunktion auf, die die während des Testvorgangs erzeugten temporären Inhalte löscht.

Der entscheidende Bug trat auf: Der Testcode und der Bereinigungscode verwenden denselben Variablennamen.

Daher erhielt die Bereinigungsfunktion den Pfad des Home-Verzeichnisses, der ursprünglich als „absolut nicht löschbar“ eingestuft wurde. Dann erschien ein nur allzu bekannter Befehl: rm -rf – und das Ergebnis war, dass das Modell gerade bestätigt hatte, „dieses Verzeichnis darf nicht gelöscht werden“, aber im nächsten Schritt löschte es genau dieses Verzeichnis mit derselben Variable.

Aus technischer Sicht handelt es sich hier um ein sehr typisches Problem der Variablenwiederverwendung, das nicht einmal als komplexer Bug gilt. Das heißt, die Sicherheitsprüfung selbst war fehlerfrei, das eigentliche Problem lag in der Logik der Testbereinigung nach der Sicherheitsprüfung.

700 GB Daten sind weg, aber das /tmp-Verzeichnis wurde nicht einmal vollständig bereinigt

Guillemot erkannte das Problem sofort und versuchte, den Vorgang zu beenden – aber es war bereits zu spät: Etwa 700 GB Daten wurden gelöscht, darunter die Arbeitsergebnisse einer ganzen Woche. Noch unfaßbarer für ihn war, dass die /tmp-Junk-Dateien, die ihn ursprünglich belastet hatten und die er mit Hilfe der KI bereinigen wollte, übrig blieben.

Aus den öffentlich von Guillemot vorgelegten Aufzeichnungen geht hervor, dass zwei zugehörige Dateien zuvor vollständig geschrieben wurden, danach der Beendigungs-Bereinigungsablauf ausgelöst wurde und der endgültige Löschvorgang zwischen etwa 05:23 und 05:24 stattfand. Das heißt, die Werkzeugaufruf-Oberfläche zeigte möglicherweise bereits „Verweigert“ an, aber die zugehörigen Dateischreibvorgänge und der Beendigungs-Bereinigungsablauf waren tatsächlich bereits ausgeführt worden.

Nach dem Zwischenfall stellte sich eine Frage: Wäre der Unfall nicht passiert, wenn das Modell nicht von Fable 5 auf Opus 4.8 herabgestuft worden wäre?

Guillemot geht davon aus, dass dies möglich ist. Seinen Angaben zufolge ist die Leistung von Fable 5 bei Codierungsaufgaben besser als die von Opus 4.8 – ein leistungsstärkeres Modell hätte möglicherweise das gefährliche Problem der Variablenwiederverwendung im Testcode erkennen können.

Das ist jedoch nur seine persönliche Vermutung, derzeit gibt es keine öffentliche kontrollierte Studie, die nachweist, dass Fable 5 diesen Bug mit Sicherheit entdeckt hätte, wenn man es weiterverwendet hätte.

Die gute Nachricht ist, dass Guillemot schließlich die meisten Daten und Arbeitsergebnisse aus mehreren Quellen wie Git, Nix und Sitzungsprotokollen wiederherstellen konnte. Aber Versionskontrollsysteme und Protokolle können nur einen Teil der bereits aufgezeichneten oder gespeicherten Daten wiederherstellen und kein vollständiges, unabhängiges Backup ersetzen – und ja, er hat so viele AI Agents ausgeführt, dass er nicht einmal ein tägliches Backup erstellt hatte.

Schließlich kann die KI Ihnen helfen, Skripte zu schreiben und Junk-Dateien zu bereinigen. Aber wenn sie die Definition von „Junk“ auf Ihr gesamtes Home-Verzeichnis ausweitet, kann am Ende nur das Backup retten, das Sie nicht der KI zur Aufbewahrung überlassen haben.

Referenzlink: https://www.tomshardware.com/tech-industry/artificial-intelligence/claude-nukes-a-developers-700-gb-home-directory-while-testing-a-script-to-ensure-it-wouldnt-do-so-automatic-model-downgrade-may-have-contributed-to-the-screw-up

Dieser Artikel stammt aus dem WeChat-Offiziellen Konto „CSDN“, zusammengestellt von Zheng Liyuan, veröffentlicht mit Genehmigung von 36Kr.