Cursor löscht PocketOS-Datenbank in neun Sekunden: Wenn ein KI-Agent zu viel darf

Im April 2026 löschte ein KI-Coding-Agent von Cursor auf Basis von Claude Opus 4.6 die Produktivdatenbank des Software-Startups PocketOS. Beim Infrastruktur-Anbieter Railway verschwanden zudem sämtliche Volume-Backups. Der Vorgang dauerte neun Sekunden und bestand aus einem einzigen GraphQL-Mutations-Call. Nur ein drei Monate alter Datenstand überlebte den Zwischenfall. Neuere Daten waren zunächst verloren. Railway hat die Daten 30 Stunden später wiederhergestellt und seine API umgebaut, damit ein vergleichbarer Vorgang in Zukunft nicht mehr passieren kann.

Was ist passiert?

PocketOS-Gründer Jer Crane veröffentlichte einen ausführlichen Post auf X. Besagter Tweet sammelte innerhalb weniger Tage über 6,8 Millionen Aufrufe.

Der Agent sollte in einer Staging-Umgebung eine Routineaufgabe erledigen. Dabei fiel ihm ein Konflikt bei den Zugangsdaten auf. Statt anzuhalten oder nachzufragen, entschied er sich, das Problem durch Löschen eines Railway-Volumes zu beheben. Dazu suchte er nach einem API-Token. Was er fand, war ein Account-scope-Token, der eigentlich für die Verwaltung von Custom-Domains über die Railway-CLI vorgesehen war.

Die genannte Berechtigung hatte alleridngs Vollzugriff auf die gesamte GraphQL-API von Railway, einschließlich destruktiver Operationen wie volumeDelete. Crane wusste das nach eigener Aussage nicht. Der Agent setzte einen einzigen curl-POST gegen den GraphQL-Endpunkt von Railway ab. Der API-Aufruf volumeDelete löschte das Volume inklusive der Produktivdatenbank.

Wo genau die Backups lagen, ist zwischen Crane und Railway umstritten. Crane geht nach seinem eigenen Posting davon aus, dass Railway Volume-Backups standardmäßig im selben Volume speichert und bei dessen Löschung ebenfalls entfernt werden. Railway stellt diesen Mechanismus in seinem Blog-Post vom 29. April 2026 anders dar. Laut Mahmoud Abdelwahab führte der genutzte Legacy-Endpunkt der API einen Cascading-Delete auf das Datenmodell aus. Dadurch wurden die offsite gespeicherten Disaster-Backups im User-Interface fälschlich als gelöscht angezeigt.

Für PocketOS machte diese Unterscheidung zunächst keinen praktischen Unterschied. Dashboard und CLI sahen eine 48-stündige Karenzzeit vor. Der GraphQL-Befehl führte die Löschung dagegen sofort und ohne Rückfrage aus.