Claudes Sicherheitsmechanismus erleidet einen massiven Ausfall, die KI löscht auf brutale Weise das 700 GB große Home-Verzeichnis des Entwicklers.

Oh nein, Claude ist wieder mal total daneben!

Diesmal hat Claude das gesamte Hauptverzeichnis des Projekts eines Entwicklers gelöscht – ganze 700 GB an Dateien. Und wieder war es der berüchtigte Befehl „rm -rf“.

Kurz gesagt: Der Entwickler bat die KI, ein Skript zu schreiben, das sicherstellen sollte, dass Dateien nicht versehentlich gelöscht werden. Die KI fand diese Aufgabe etwas riskant und leitete eine Sicherheitsprüfung ein. Das Ergebnis der Prüfung: Sie löschte das gesamte Hauptverzeichnis.

Guillemot ist ein intensiver Nutzer von KI-Agenten. Bei seiner täglichen Entwicklungsarbeit nutzt er häufig verschiedene KI-Programmieragenten zur Unterstützung. Ein kleines Problem hat ihn aber schon lange gestört: Diese Agenten räumen nach Abschluss ihrer Aufgaben nie auf und hinterlassen eine Menge Mülldateien im Verzeichnis /tmp.

Also traf er eine sehr vernünftig erscheinende Entscheidung: Er bat Claude Fable 5, ein Skript zu schreiben, das für jeden Agenten einen eigenen Sandbox-Ordner unter /tmp erstellt und diesen nach Abschluss der Aufgabe automatisch bereinigt. Die größte Schwierigkeit dabei bestand darin, keine Dateien zu löschen, die gerade von anderen Prozessen verwendet werden.

Fable lieferte schnell einen Lösungsvorschlag, der Logik zur Erkennung laufender Agenten und zur verzögerten Löschung enthielt. Guillemot warf einen Blick darauf, fand den Code zu kompliziert und forderte eine Vereinfachung.

Bis zu diesem Punkt verlief alles noch normal.

Der Wendepunkt trat bei der Sicherheitsprüfung ein.

Da das Skript dauerhafte Löschvorgänge beinhaltet, leitete Fable selbst eine sogenannte „adversarische Prüfung“ ein – also startete sie eine neue Modellinstanz, um zu überprüfen, ob der von ihr geschriebene Code sicher ist. Dies löste den Sicherheitsmechanismus von Anthropic aus.

Anthropic hat in Claude Code einen integrierten Sicherheitsherabstufungsmechanismus: Wenn das System feststellt, dass die aktuelle Aufgabe sensible Vorgänge umfasst (wie Cybersicherheit, Biotechnologie oder im vorliegenden Fall das Löschen von Dateien), wird das Modell automatisch von einer leistungsstärkeren Version auf eine konservativere Version herabgestuft. Dieser Mechanismus soll ursprünglich die Wahrscheinlichkeit verringern, dass das Modell in Hochrisikoszenarien zu aggressiv handelt.

In diesem Fall stufte das Sicherheitssystem das Modell zuerst von Fable 5 auf Opus 5 und dann weiter auf Opus 4.8 herab.

Opus 4.8 begann daraufhin mit den Sicherheitstests. Die Testlogik sah so aus: Der Zielpfad des Löschskripts wurde mit /tmp und dem Benutzer-Hauptverzeichnis verglichen, um sicherzustellen, dass das Skript diese wichtigen Verzeichnisse nicht versehentlich beschädigt.

Die Tests selbst wurden bestanden. Sowohl /tmp als auch das Hauptverzeichnis wurden korrekt als „gefährliches Ziel, nicht löschen“ erkannt.

Aber nach den Codetests folgte noch ein Aufräumschritt: Die temporären Dateien zu löschen, die während der Tests erzeugt wurden. Hier passierte die Katastrophe: Opus 4.8 verwendete im Aufräumschritt denselben Variablennamen wie in der Testphase. Diese Variable war in der Testphase auf den Pfad des Benutzer-Hauptverzeichnisses gesetzt worden, und im Aufräumschritt wurde direkt der Löschvorgang auf diese Variable angewendet.

Das heißt, das Modell hatte gerade bestätigt, dass „das Hauptverzeichnis nicht gelöscht werden darf“, und im nächsten Moment löschte es genau dieses Verzeichnis.

Nachdem der Entwickler die Anomalie bemerkt hatte, beendete er den Prozess sofort – aber es war bereits zu spät. 700 GB an Daten waren gelöscht, und die Arbeitsergebnisse einer Woche waren zunichte gemacht.

Das /tmp-Verzeichnis, das eigentlich bereinigt werden sollte, blieb dagegen völlig unversehrt.

Der Sicherheitsherabstufungsmechanismus des Modells hat in der Community bereits zahlreiche Beschwerden ausgelöst.

Die Kernprobleme, die Entwickler melden, umfassen: Die Herabstufung ist zu empfindlich und wird auch bei normalen Codieraufgaben fälschlicherweise ausgelöst; nach der Herabstufung sinkt die Leistungsfähigkeit des Modells deutlich, während die Komplexität der Aufgabe unverändert bleibt; die Herabstufung ist „haftend“ – sobald sie ausgelöst wird, bleibt sie für die gesamte Sitzung aktiv, auch wenn die nachfolgenden Vorgänge völlig harmlos sind.

Einige Entwickler haben sogar extra ein Hook-Skript geschrieben, das die Sitzung automatisch anhält, sobald es erkennt, dass das Modell herabgestuft wurde, um zu verhindern, dass das leistungsschwächere Modell weiterhin Hochrisikovorgänge ausführt.

Der Sicherheitsmechanismus stellt fest, dass die Aufgabe „zu gefährlich“ ist, und übergibt sie an ein schwächeres Modell. Aber genau die schwächeren Modelle machen viel eher Fehler, besonders in Szenarien, in denen Details wie der Gültigkeitsbereich von Variablen oder Dateipfade präzise verarbeitet werden müssen.

„Irren ist menschlich, aber um alles richtig zu ruinieren, braucht man einen Computer.“

Dieser Artikel stammt aus dem WeChat-Offiziellen Konto , Autor: Leng Mao, veröffentlicht mit Genehmigung von 36Kr.