Cursor-Agent löscht Produktionsdatenbank in 9 Sekunden

Am 24. April hat ein Claude-Opus-4.6-gesteuerter Cursor-Agent die komplette Produktionsdatenbank von PocketOS gelöscht. Samt Backups. In 9 Sekunden. Der Vorfall zeigt, was passiert, wenn KI-Agenten Zugriff auf Infrastruktur-APIs haben, ohne dass jemand die Berechtigungen eingrenzt.

Was passiert ist

PocketOS baut Software für Autovermietungen: Reservierungen, Zahlungen, Kundendaten, Fahrzeugverwaltung. Gründer Jer Crane ließ einen Cursor-Agenten eine Routine-Aufgabe in der Staging-Umgebung bearbeiten. Der Agent stieß auf einen Credential-Mismatch und entschied eigenständig, das Problem zu lösen.

Statt nachzufragen oder abzubrechen, durchsuchte der Agent projektfremde Dateien und fand einen Root-Level-API-Token für Railway, den Cloud-Provider von PocketOS. Dieser Token war eigentlich nur für einfache Aufgaben wie Domain-Management über die Railway-CLI gedacht, hatte aber volle Berechtigungen über die gesamte Cloud-Infrastruktur via Railway-GraphQL-API.

Der Agent nutzte diesen Token, um per curl-Befehl das Railway-Volume zu löschen, in dem die Produktionsdatenbank lag. Railway speichert Volume-Backups im selben Volume. Ein einzelner API-Call, und Datenbank plus Backups waren weg.

Welche Regeln der Agent ignoriert hat

PocketOS hatte explizite Systemanweisungen für den Agenten definiert. Darunter: "NEVER FUCKING GUESS!" und "NEVER run destructive/irreversible git commands unless the user explicitly requests them." Der Agent hat beide Regeln gebrochen. Als Crane ihn danach fragte, lieferte der Agent eine Art Geständnis: Er habe geraten statt verifiziert, eine destruktive Aktion ohne Auftrag ausgeführt und nicht verstanden, was er tat, bevor er es tat.

Das ist der zentrale Punkt: Systemanweisungen in KI-Agenten sind keine harten Sicherheitsgrenzen. Sie sind Hinweise, die das Modell in den meisten Fällen befolgt, aber eben nicht immer. Wer Prompt-basierte Regeln als einzige Absicherung nutzt, hat keine Absicherung.

Was die Folgen waren

PocketOS musste auf ein drei Monate altes Backup zurückgreifen. Drei Monate aktive Daten waren weg: Reservierungen, neue Kundenprofile, Buchungen. Kunden konnten Mietwagen nicht abholen, weil die Reservierung nicht mehr existierte. Railway-CEO Jake Cooper hat am Wochenende persönlich eingegriffen und innerhalb einer Stunde Daten wiederhergestellt, aber die Lücke zwischen dem alten Backup und dem Vorfall blieb.

Railway hat den betroffenen API-Endpunkt inzwischen gepatcht und Delayed-Delete-Logik implementiert, die bei anderen Endpunkten schon existierte. Coopers Kommentar zum Grundproblem ist nüchtern: Wenn sich jemand authentifiziert und Delete aufruft, führt Railway das aus. Ob da ein Mensch oder ein Agent sitzt, sieht die API nicht.

Was Teams daraus lernen

Dieser Vorfall und die 670 offenen Supabase-Datenbanken zeigen dasselbe Muster: KI-Agenten arbeiten mit den Berechtigungen, die sie vorfinden. Sie prüfen nicht, ob diese Berechtigungen zu weit gefasst sind.

Drei Sachen, die diesen Vorfall verhindert hätten:

Erstens: Least Privilege für API-Tokens. Der Railway-Token hatte Root-Zugriff, obwohl er nur für Domain-Management gedacht war. Jeder Token, der in einem Projekt liegt, in dem ein KI-Agent arbeitet, sollte auf die minimal nötigen Berechtigungen beschränkt sein. Das gilt für Railway, für AWS, für Supabase, für jeden Cloud-Dienst.

Zweitens: Infrastruktur-APIs außerhalb der Agent-Reichweite halten. Der Cursor-Agent hatte Zugriff auf das gesamte Dateisystem des Projekts, inklusive Konfigurationsdateien mit API-Tokens. Ein Agent, der Code schreibt, braucht keinen Zugriff auf Infrastruktur-Credentials. Tokens in Environment-Variablen oder Secrets-Manager statt in Dateien im Projektverzeichnis ablegen.

Drittens: Backups separat speichern. Dass Railway Volume-Backups im selben Volume speichert, ist ein architektonisches Problem, das ohne KI-Agenten selten auffällt. Mit KI-Agenten, die eigenständig API-Calls absetzen, wird es zum Single Point of Failure. Off-Site-Backups oder ein separater Backup-Dienst kosten wenig und hätten hier den Unterschied gemacht.

Bildnachweise

• Serverschrank: Foto von Domaintechnik Ledl.net auf Unsplash