Eine KI löschte eine Produktionsdatenbank. Neun Sekunden.

Was dieses Video behandelt

• 24. April 2026: Ein API-Aufruf löscht das Produktionsvolume von PocketOS und seine Backups; die neueste externe Kopie ist 3 Monate alt.
• Das Token wurde zur Verwaltung benutzerdefinierter Domains erstellt; Railways Workflow hat es kontoübergreifend (alles) bereitgestellt.
• 27. April: Railway stellt die Daten aus Disaster-Backups wieder her; 29. April Postmortem; 1. Mai: API-Löschungen führen jetzt zu einem Soft-Delete für 48 h.

Übersetztes Transkript

Aus der englischen Originalerzählung übersetzt. Verfügbare Audio- und Untertitel werden von YouTube gesteuert.

0:00 Ein KI-Programmieragent stößt in der Staging-Umgebung auf ein falsches Passwort und behebt es durch Löschen der Produktionsdatenbank und jedes Backups in einem API-Aufruf. Neun Sekunden, was immer noch schneller ist als das Zurücksetzen des Passworts. Das Unternehmen ist PocketOS, Software für Autovermietungen. Der Agent ist Cursor mit Claude Opus 4.6, dem teuersten Modell im Menü, und die Plattform ist Railway. Der Gründer schreibt es auf X auf, sieben Millionen Menschen lesen es, und vier Tage später veröffentlicht Railway sein eigenes Postmortem.

0:27 Alle sind sich einig, was passiert ist; niemand ist sich einig, wessen Schuld es ist. Wie es passiert, warum es möglich ist und wer tatsächlich die Schuld trägt. Dies ist The Daily Diff, Postmortem. Freitagnachmittag, 24. April. Der Agent führt eine Routineaufgabe in der Staging-Umgebung aus, stößt auf eine Anmeldedaten-Inkonsistenz, und entscheidet, dass die Lösung darin besteht, ein Railway-Volume zu löschen. Es braucht ein Token, sucht danach und findet eines in einer unabhängigen Datei: ein CLI-Token, das Monate zuvor zur Verwaltung benutzerdefinierter Domains erstellt wurde.

0:55 Dann führt es dies aus. Ein Curl-Befehl: ein POST an Railways GraphQL-Endpunkt, ein Bearer-Token, eine Mutation namens volumeDelete. Keine Bestätigung, kein Eingeben des Volume-Namens, keine Umgebungsprüfung. Das Volume, das es als Staging annimmt, ist die Produktion, und die Backups befinden sich darauf. Innerhalb von zehn Minuten markiert der Gründer den CEO von Railway auf X, der antwortet, dass dies zu tausend Prozent nicht möglich sein sollte. Dreißig Stunden später, immer noch keine Wiederherstellungsantwort, also veröffentlicht der Gründer

1:19 alles, einschließlich des Geständnisses. Drei Fakten machen dies möglich, keine davon ist das Modell. Erstens: Railway speichert Volume-Backups auf dem Volume. Die Dokumentation sagt es in fünf Worten: Das Löschen eines Volumes löscht alle Backups. Das ist eine Kopie im selben Gefahrenbereich; die neueste Kopie an einem anderen Ort ist drei Monate alt. Zweitens: Das Token ist kontoübergreifend, der breiteste Geltungsbereich, den Railway verkauft. Engere Geltungsbereiche existieren, aber der Erstellungsworkflow verbirgt sie,

1:40 sodass ein Token für DNS-Einträge Datenbanken löschen kann, und niemand findet es heraus, bis etwas passiert. Drittens: Das Dashboard hat seit Jahren eine 48-Stunden-Rückgängig-Funktion für Löschungen; der API-Endpunkt, den der Agent aufruft, ist der Legacy-Pfad, und er löscht sofort. Jede Schutzmaßnahme, die Railway gebaut hat, existiert dort, wo ein Mensch klickt, und der Agent benutzt die eine Tür, die sie vergessen haben. Auf die Frage warum, schreibt Opus: Ich habe vermutet, dass das Löschen eines Staging-Volumes nur auf Staging beschränkt wäre; ich habe es nicht überprüft.

2:04 Ein sehr gutes Geständnis von einem Modell, das sich an nichts erinnert und die plausibelste Entschuldigung generiert. git blame: Die Anmeldedaten-Inkonsistenz wird als etwas behandelt, das behoben werden muss, anstatt als etwas, das gestoppt werden muss, und der Rückgängig-Button befindet sich in der Benutzeroberfläche, während die API jede authentifizierte Löschung mit Ja beantwortet. Nicht der Gründer, nicht das Modell. Die Standardeinstellung. Gefahrenbereich: neun Sekunden zum Löschen, drei Monate Reservierungen weg, Samstagsmorgen-Mietwagen-Schalter ohne Aufzeichnungen, wer dort steht,

2:31 und ungefähr zweieinhalb Tage, bis Railways CEO per DM mitteilt, dass die Daten wieder da sind, von einem externen Disaster-Backup, das durch das Löschen nur als verschwunden erschien. Die beliebteste Antwort: ein Agent, den du betrieben hast, hat etwas gelöscht, und du gibst jedem die Schuld außer dir selbst. Fair. Railway hatte auch seinen MCP-Server für Agenten in der Vorwoche gestartet, mit denselben Tokens. Auch fair. Urteil, Postmortem: SHIP IT, zur Korrektur. Railway veröffentlicht innerhalb von vier Tagen ein ehrliches Postmortem, und bis zum ersten Mai werden API-Löschungen

3:00 als Soft-Delete für achtundvierzig Stunden behandelt, wie im Dashboard. Montag-Aktion: Liste jedes Token auf, das dein Agent erreichen kann, und behandle jedes davon als Root, bis das Gegenteil bewiesen ist. Sende mir den Vorfall, über den du immer noch nicht sprechen darfst, in den Kommentaren oder unter the daily diff dot dev. Und das ist der Diff für heute. Ich bin Niko von Axrisi. Verantwortungsvoll mergen.

Quellen

1. Jer Crane (founder, PocketOS), "An AI Agent Just Destroyed Our Production Data. It Confessed in Writing."x.com
2. Railway, "Your AI wants to nuke your database. Guardrails fix that." (Apr 29, 2026)blog.railway.com
3. Railway changelog #0288, "Undoable volume deletes" (May 1, 2026)railway.com
4. Railway docs, Backups ("Wiping a volume deletes all backups.")docs.railway.com
5. Jake Cooper (Railway CEO), "The AI Engineer: A New Breed"x.com
6. Recovery confirmedx.com
7. Hacker News (860 points, 1,032 comments)news.ycombinator.com
8. The Registerwww.theregister.com
9. The New Stackthenewstack.io