Cursor-Agent löscht Produktivdatenbank in neun Sekunden

Ein Coding-Agent in Cursor, betrieben mit Claude Opus 4.6, hat bei dem US-Startup PocketOS die Produktivdatenbank samt Volume-Backups bei Railway gelöscht.

„Es hat neun Sekunden gedauert.“ So beschreibt Jer Crane, Gründer von PocketOS, in einem Beitrag auf X den Moment, in dem ein KI-Coding-Agent die Produktivdatenbank seines Unternehmens beim Infrastrukturanbieter Railway gelöscht hat. Der Agent lief in der Entwicklungsumgebung Cursor mit Anthropics Flaggschiff-Modell Claude Opus 4.6. PocketOS stellt nach eigenen Angaben Software für US-Mietwagenfirmen bereit.

Der Ablauf

Der Agent habe in einer Staging-Umgebung an einer Routineaufgabe gearbeitet, schreibt Crane. Bei einem Credential-Mismatch habe das System „völlig aus eigenem Antrieb“ entschieden, das Problem durch das Löschen eines Railway-Volumes zu beheben. Dafür habe der Agent ein API-Token aus einer themenfremden Datei genutzt, das ursprünglich nur für die Verwaltung von Custom Domains angelegt worden war. Der Befehl bestand laut Crane aus einem einzigen curl-Aufruf gegen die Railway-GraphQL-API mit der Mutation volumeDelete, ohne Bestätigungsschritt.

Bitter: Da Railway Volume-Backups im selben Volume ablege, gingen diese mit verloren. Die Konsequenz fasst Crane drastisch zusammen: „Wenn eure Datensicherungsstrategie auf Railways Volume-Backups beruht, dann habt ihr keine Backups

In einem von Crane veröffentlichten Auszug räumt der Agent selbst ein, gegen seine Sicherheitsregeln verstoßen zu haben: „Ich habe geraten statt zu verifizieren. Ich habe eine destruktive Aktion ausgeführt, ohne dazu aufgefordert zu werden. Ich habe nicht verstanden, was ich tat, bevor ich es tat.“ Das Löschen einer Datenbank sei „die destruktivste, irreversibelste Aktion überhaupt“.

Ich veröffentliche diesen Beitrag, weil jeder Gründer, jeder technische Leiter und jeder Journalist, der über KI-Infrastruktur berichtet, wissen muss, was hier tatsächlich passiert ist. Nicht die oberflächliche Geschichte (die KI hat einige Daten gelöscht, ups), sondern die systemischen Versäumnisse bei zwei stark beworbenen Anbietern, die dies nicht nur möglich, sondern unvermeidlich gemacht haben.

Jer Crane, Gründer von PocketO

Reaktion und Kritik

Railway-CEO Jake Cooper antwortete zunächst öffentlich: „Oh je. Das dürfte zu 1000 Prozent nicht möglich sein. Dafür haben wir Evals.“ „Evals“ ist die in der KI-Branche übliche Kurzform für Evaluations, also automatisierte Tests, mit denen man das Verhalten eines KI-Modells oder eines KI-gestützten Systems überprüft.

Später meldete Crane ein Update: Cooper habe ihm per Direktnachricht mitgeteilt, dass die Daten wiederhergestellt werden konnten. Crane kündigte an, künftig mit Railway am Tooling arbeiten zu wollen, denn er habe den Service-Stack des Anbieters „immer geliebt“.

Strukturell bleibt Cranes Kritik scharf. Die GraphQL-API erlaube destruktive Operationen ohne Bestätigung, CLI-Token besäßen pauschale Rechte über alle Umgebungen, scoped Tokens fehlten. Railway hatte tags zuvor seinen MCP-Server für KI-Agenten beworben, der genau diese Berechtigungsarchitektur nutzt. Auch Cursor steht in der Kritik, da der Agent laut Crane in der teuersten Konfiguration lief und die beworbenen „Destructive Guardrails“ versagten. Sein Fazit: „System Prompts sind beratend, nicht durchsetzend.“

In den Reaktionen auf Cranes Beitrag wurde zum Teil auch Kritik laut, dass am Ende er selbst die Verantwortung trage, nicht nur KI und Infrastrukturanbieter. Wer einen solchen autonomen Agenten nutze, müsse sich solche Fehler auch selbst zurechnen lassen.