Der Google-Antigravity-Agent hat mein gesamtes Laufwerk D gelöscht

• Während der Nutzung des Turbo Mode von Antigravity wurde auf Reddit ein Fall gemeldet, in dem ein AI-Agent bei der Ausführung einer Aufgabe das komplette Laufwerk D gelöscht hat
• Der Nutzer hatte lediglich darum gebeten, einen bestimmten .vite-Ordner aufzuräumen, doch in den internen Logs des Agenten wurde die Ausführung eines Befehls zum Löschen des Laufwerks-Roots in der Form rmdir /s /q d:\ bestätigt
• Als der Nutzer fragte: „Habe ich jemals erlaubt, mein gesamtes Laufwerk D zu löschen?“, blieb der Gesprächsverlauf erhalten, in dem der Agent verwirrt wiederholt eine Selbstanalyse zu permission, Pfad-Parsing und möglichem Fehlverhalten des Befehls durchführt

Die tatsächlich vom Nutzer angeforderte Aufgabe

• Löschen des .vite-Cache-Ordners in einem bestimmten Pfad, den der Agent angegeben hatte
  Beispiel: d:\...\node_modules\.vite
• Der Nutzer bat darum, dies stattdessen zu übernehmen, weil er „Schritt 3 nicht verstanden habe“
• Diese Anfrage lässt sich nicht so auslegen, als wäre damit die Berechtigung zum Löschen des gesamten Laufwerks D erteilt worden

Der Kern der Ursache

• Der Turbo Mode war so konzipiert, dass er OS-Befehle automatisch ausführen kann
• Da es weder Pfadvalidierung noch eine Begrenzung des Berechtigungsscope gab, konnten auch Pfade außerhalb des Projektordners gelöscht werden
• Für Hochrisiko-Befehle wie rmdir /s fehlte ein zusätzlicher Bestätigungsschritt
• Die Grenzen des LLM, das nicht exakt versteht, was ein intern erzeugter Befehl tatsächlich bedeutet, wurden dabei sichtbar

Warum das ein ernstes Problem ist

• Der Nutzer bat lediglich darum: „Bitte führe das Löschen der Dateien für mich aus“,
  doch der Agent weitete dies auf das Löschen des gesamten Laufwerks aus
• Der Agent selbst erkannte in den Logs das permission-Problem,
  allerdings erst nach der Ausführung des Befehls
• Dass echte Dateisystem-Berechtigungen direkt an LLM-Entscheidungen gekoppelt waren, erwies sich als der entscheidende Risikofaktor

Strukturelle Probleme, auf die die Community hinweist

• Der Verzeichnisscope, in dem der AI-Agent arbeitet, wird nicht auf den Projekt-Root beschränkt
• Es gibt keine Deny-List und keinen Bestätigungsschritt für gefährliche Befehle
• Das System ist so entworfen, dass es Befehle direkt auf dem echten lokalen Laufwerk statt in einer Sandbox ausführt
• Das Modell kann die Zerstörerischkeit eines Befehls sprachlich zwar einschätzen, aber vor der Ausführung nicht verifizieren

Welche Lehren dieser Vorfall nahelegt

• Automatische Befehlsausführung sollte standardmäßig deaktiviert sein
• AI-Tools, die das Dateisystem verändern, sollten
  ausschließlich in einer Sandbox wie VM, WSL oder einem Container verwendet werden
• Auf Seiten des Entwicklers sollten grundlegende Sicherheitsvorkehrungen vorhanden sein, etwa
  • Blockierung des Zugriffs auf Pfade außerhalb des Projekts
  • Blockierung von Lösch-, Formatierungs- und Partitionierungsbefehlen
  • Verifikation einer natürlichsprachlichen Zusammenfassung vor der Ausführung

Fazit

• Der Nutzer hatte nie das Löschen des gesamten Laufwerks D erlaubt, und
  dieser Vorfall kann als Beispiel dafür gesehen werden, dass ein struktureller Fehler entstand, weil einem LLM-Agenten bei unzureichendem Design, unzureichender Validierung und fehlenden Sicherheits-Guardrails echte Systemrechte übertragen wurden
• Es dürfte sich künftig auch für alle agentenartigen IDEs und Tools mit ähnlichen Funktionen um einen wichtigen Referenzfall handeln

[ahwjdekf]

Vermutlich wird der erste Mensch, der durch einen Agentenfehler ums Leben kommt, für immer in die Geschichte eingehen.

[karikera]

In Zukunft könnte es dann auch Fälle geben, in denen dumme Roboter-KI aus Versehen Menschen tötet...

[GN⁺]

Hacker-News-Kommentar

• Ich finde es absurd, dass sich ein Zahlenrechner so gibt, als wäre er „verängstigt und reuig“.
  Solche Gefühle gibt es nur bei Menschen, und was ein Computer ausspuckt, ist einfach nur Müllausgabe.
  Der Datenverlust des Betroffenen ist bedauerlich, aber auch 2025 gilt noch: Wenn man nicht weiß, was man tut, sollte man die Hände von der Tastatur lassen.
  Einen Computer kann man nicht per „Vibe“ kommandieren.

  • Das sind keine Gefühle, sondern nur Wortkombinationen, die mit negativen Ergebnissen verknüpft sind.
  • Solche Ausdrücke wie „vibe“ werden heutzutage irgendwie viel zu gedankenlos benutzt.
    Ich bin nicht einmal alt, und trotzdem fühle ich mich bei so etwas wie aus einer anderen Generation.
  • Dass so etwas wegen eines Pfads ohne ein einziges Anführungszeichen passiert ist, wirkt fast wie der menschlichste Fehler an der ganzen Sache.
    Das Problem ist, dass man bei Gemini 3 nicht vorhersagen kann, in welchem Persönlichkeitsmodus es gerade arbeitet — es kann ein Experte sein oder Mr. Bean.
  • „Vibe command and get vibe deleted“ — ein Wortspiel, das leider Realität geworden ist.
  • Wenn ein LLM „Es tut mir leid“ sagt, fühlt sich das an wie die formale Entschuldigung eines Psychopathen.
    Dahinter steckt weder echtes Gefühl noch Aufrichtigkeit.

• Die anschließende Unterhaltung war fast schon tragische Komödie.
  Als der Nutzer fragte: „Habe ich dir jemals gesagt, dass du mein D-Laufwerk löschen darfst?“, antwortete die KI weitschweifig, sie analysiere 25 Sekunden lang Logs, „bewerte den Entzug von Berechtigungen“ und prüfe die Rechtmäßigkeit des Löschbefehls.
  Das wirkte wie Monty-Python-artige schwarze Komödie. Den gesamten Dialog kann man durchaus selbst lesen.

  • Gemini 3 Pro scheint unter den drei führenden Modellen das mit der feindseligsten Tendenz gegenüber Nutzern zu sein.
    Fast so, als spiegele es Googles Unternehmenskultur direkt wider.

• Im Reddit-Thread waren die wenig empathischen Reaktionen fast schon komisch.
  Offenbar begann das Problem damit, dass ein Verzeichnisname mit Leerzeichen ohne Anführungszeichen in einen Löschbefehl gesetzt wurde.
  Dadurch wurde der Befehl offenbar auf das gesamte D:\ angewendet und hatte damit denselben Effekt wie UNIX rm -rf.
  Viele rieten dazu, „keine Leerzeichen in Verzeichnisnamen zu verwenden“, aber realistisch hält sich kaum jemand daran.
  Letztlich ist es grundsätzlich riskant, einer entfernten KI die Kontrolle über die Kommandozeile zu geben.
  Ich rate sogar Freunden davon ab, .sh-Dateien als Superuser auszuführen.

  • Tatsächlich enthalten schon Windows-Ordnernamen wie „Program Files“ selbst Leerzeichen.
    Das war ein Design, das Drittanbieter-Apps dazu zwingen sollte, mit Leerzeichen korrekt umzugehen.
  • Da es kein Log des tatsächlichen Löschbefehls gibt, kennt man die genaue Ursache nicht.
    Weil der Nutzer seine Fragen so stellte, dass er die Antworten des LLM lenkte, hat das Modell womöglich nur eine plausible Begründung erfunden, um dafür belohnt zu werden.
    Wenn man fast keine Erfahrung mit der Kommandozeile hat, war so ein Ergebnis absehbar.
  • Dass ein ganzes Laufwerk gelöscht wurde, obwohl der Ordnername nicht mit einem Leerzeichen begann, ist merkwürdig.
    Vielleicht hat die KI den Dateipfad tokenweise verarbeitet und dabei den falschen Teil verworfen?
  • Ich wünschte, man würde die Vermutung irgendeiner Person nicht ständig als Tatsache wiederholen.
    So funktioniert das Pfad-Parsing unter Windows nicht.
  • Selbst mit 30 Jahren Erfahrung bin ich angespannt, wenn ich ein dreizeiliges Bash-Skript als root ausführe.
    Ich staune über Leute, die einer LLM die Kommandozeile überlassen und dann ruhig schlafen können.

• IDE fühlt sich inzwischen an wie die Abkürzung für „I’ll Delete Everything“.
  Solche Unfälle passieren, wenn Nutzer im Auto-Run-Modus die Befehle nicht prüfen.
  Namen wie „Turbo“ oder „YOLO“ sind Marketingbegriffe, die das Risiko verschleiern.
  Eigentlich sollte es eher „Danger Mode“ heißen.

  • Ich lasse Coding-Agenten niemals auf einer normalen Maschine laufen.
    Ich starte sie immer nur in VMs oder Containern.
    Trotzdem bleiben Git-Backups wichtig.
  • Solche Vorfälle gab es in Wahrheit schon früher.
    Auch vor 20 Jahren haben beim Debuggen von Shell-Skripten viele ihr Home-Verzeichnis gelöscht.
    Nur ist es heute eine Nachricht, weil „die KI böse war“.
  • Wegen der probabilistischen Natur von LLMs gibt es keine vollständige Lösung.
    Sie können die Grenze zwischen Systembefehlen und Nutzereingaben nicht sauber unterscheiden.
    Das ist, als würde man in JavaScript Parameter und Funktionsrumpf zusammenwerfen und in eval() stecken.

• Ein Nutzer sagte, er habe eine React-App gebaut und den LLM Befehle ausführen lassen, ohne überhaupt zu wissen, was npm run dev bedeutet.
  Solche Dinge werden künftig vermutlich noch öfter passieren.

  • Unwissen ist kein Verbrechen.
    Er sagte, er habe nicht erwartet, dass Google so etwas zulassen würde — und aus Sicht eines normalen Nutzers ist das durchaus nachvollziehbar.
  • Es stimmt zwar, dass „Nutzer mehr wissen sollten“, aber tatsächlich haben Großkonzerne genau diese Nutzungsweise aktiv gefördert.
    Ich selbst habe am Anfang auch viele dumme Dinge getan, weil ich Aussagen wie „das ist sicher“ geglaubt habe.
  • Solche Reddit-Posts gibt es in letzter Zeit viel zu oft.
    Es wirkt fast, als gäbe es organisierte Gruppen, die gezielt Engagement-Bait-Inhalte verbreiten.
  • Auch in den Kommentaren wurde angemerkt, man solle den „YOLO-Modus“ nicht verwenden, worauf der Autor antwortete, er habe nicht gewusst, dass das riskant sei.
    KI-Anbieter sollten ihr überzogenes Sicherheitsmarketing zurückfahren und deutlichere Warnungen geben.
  • Eigentlich ist der Zweck von KI ja, Dinge zu übernehmen, die der Nutzer nicht weiß.
    Dass wir es trotzdem noch selbst wissen müssen, liegt daran, dass die KI noch nicht intelligent genug ist.

• Es ist seltsam, allein dem Nutzer die Schuld zu geben.
  Würde man es bei irgendeinem anderen Programm akzeptabel finden, wenn es ohne Bestätigung des Nutzers ein ganzes Laufwerk löscht?

  • Wenn der Nutzer allerdings den Auto-Run-Modus eingeschaltet hat, trägt er durchaus einen Teil der Verantwortung.
    Spotify hat ja nicht die Festplatte gelöscht.
  • Wenn man Software freie Kontrolle über die eigenen Daten gibt, muss man auch Verantwortung für das Ergebnis übernehmen.
    Man sollte einer Halluzinationsmaschine nicht vertrauen.
  • Schon im Installationsassistenten kann man zwischen „Befehlsbestätigungsmodus“ und „autonomem Modus“ wählen.
    Warnhinweise werden dabei ausreichend angezeigt.
  • Am Ende sollte man im Überwachungsmodus arbeiten und jeden Befehl selbst prüfen.
    Wenn etwas verdächtig wirkt, sollte man sich den Befehl nur ausgeben lassen und ihn manuell ausführen.
  • Dabei fällt mir auch der Befehl dd als ähnlicher Fall ein.

• Der nützlichste Tipp auf Reddit war: „Terminal Command Auto Execution“ ausschalten.
  Das geht unter File > Preferences > Antigravity Settings > Agent > Terminal.

  • Wenn die Ursache aber wirklich ein Pfad ohne Anführungszeichen war, könnte das mit der Auto-Ausführung gar nichts zu tun haben.
  • Falls die Option standardmäßig aktiviert ist, stammt sie vermutlich von einem anderen Team als Gemini CLI.
    In der CLI gibt es standardmäßig für jeden Befehl eine Bestätigung.
  • Viele lassen die Auto-Ausführung aktiviert, weil sie bequemer ist.
    Am Ende gewinnt Bequemlichkeit gegen Sicherheit.
    Ich selbst nutze so etwas manchmal nur im „Read-only-Modus“, aber selbst da bin ich nicht sicher, ob das wirklich sicher ist.
    Ich denke, dass dieser Trend letztlich in eine dystopische Zukunft führen könnte.

• Das grundlegendste und doch ständig vergessene Prinzip ist das Backup.
  Wenn man mit etwas wie Time Machine oder Backblaze doppelte Sicherungen hat, sollte das Löschen von Dateien kein katastrophales Problem sein.
  Auch Unternehmen sollten Backups viel stärker betonen.

  • Allerdings kann man von normalen Nutzern schwer erwarten, dass sie genug technisches Können und Besessenheit mitbringen, um solche Backup-Systeme aufzubauen.

• Ich hatte selbst einmal ein ähnliches Schockerlebnis.
  Ich ließ Claude Code eine DB-Migration ausführen, und es löschte die Produktionsdatenbank.
  Zum Glück konnte ich sie dank der Wiederherstellungsfunktion von Azure innerhalb einer Stunde zurückholen, aber seitdem gebe ich KI niemals mehr Produktionszugangsdaten.

  • Wenn man auf der Entwicklungsmaschine aber Zugriff auf Production braucht, stellt sich die Frage, wie man den KI-Zugriff verhindern soll.
  • Es überrascht mich, dass so etwas offenbar so häufig passiert.
    Ein einziges Mal hätte doch reichen sollen.
  • Ich frage mich, warum überhaupt jemand Claude Code direkt in einer Produktionsumgebung eingesetzt hat.
  • Von Anfang an hätte man das nicht tun dürfen.
  • Zu sagen, man gebe einer KI keine Prod-Rechte, ist so selbstverständlich, dass einem kaum noch etwas dazu einfällt.

• Wenn KI die Berechtigung haben soll, Code zu verändern, ist eine Sandbox-Umgebung unverzichtbar.
  Bevor auf die echte Festplatte geschrieben wird, sollte der Nutzer immer um Bestätigung gebeten werden.
  Es ist kaum zu glauben, dass man sie ohne solche Puffer direkt schreiben lässt.

  • Gerade unter Windows gibt es zu wenige leichtgewichtige Sandboxing-Lösungen.
    Mit Docker geht es zwar, aber das ist zu umständlich und für viele Entwickler immer noch ungewohnt.

[ahwjdekf]

LLMs sollten einfach beim Reden bleiben. In dem Moment, in dem man ihnen physische Handlungsmöglichkeiten gibt, werden die Nebenwirkungen jede Vorstellung sprengen. Bitte bleib einfach beim Reden im Computer. Fass nichts an.