Sebuah AI menghapus database produksi. Sembilan detik.

Isi video ini

• 24 April 2026: satu panggilan API menghapus volume produksi PocketOS dan cadangannya; salinan offsite terbaru berusia 3 bulan
• Token dibuat untuk mengelola domain khusus; alur Railway menyediakannya dengan cakupan akun (semuanya)
• 27 April: Railway memulihkan data dari cadangan bencana; postmortem 29 April; 1 Mei: penghapusan API sekarang soft-delete selama 48 jam

Transkrip terjemahan

Diterjemahkan dari narasi asli bahasa Inggris. Audio dan teks tersedia yang dikontrol oleh YouTube.

0:00 Agen pengodean AI mengalami kesalahan kata sandi di staging, dan memperbaikinya dengan menghapus database produksi dan setiap cadangan dalam satu panggilan API. Sembilan detik, yang masih lebih cepat daripada reset kata sandi. Perusahaan ini adalah PocketOS, perangkat lunak penyewaan mobil. Agennya adalah Cursor yang menjalankan Claude Opus 4.6, model termahal di menu, dan platformnya adalah Railway. Pendiri menuliskannya di X, tujuh juta orang membacanya, dan empat hari kemudian Railway menerbitkan postmortem-nya sendiri.

0:27 Semua orang setuju tentang apa yang terjadi; tidak ada yang setuju siapa yang bersalah. Bagaimana itu terjadi, mengapa itu mungkin, dan siapa yang sebenarnya disalahkan. Ini adalah The Daily Diff, postmortem. Jumat sore, 24 April. Agen sedang dalam tugas rutin di staging, mengalami ketidakcocokan kredensial, dan memutuskan perbaikannya adalah menghapus volume Railway. Ia membutuhkan token, mencarinya, dan menemukannya di file yang tidak terkait: sebuah CLI token yang dibuat beberapa bulan sebelumnya untuk mengelola domain khusus.

0:55 Kemudian ia menjalankan ini. Satu curl: sebuah POST ke endpoint GraphQL Railway, sebuah bearer token, sebuah mutasi yang disebut volumeDelete. Tidak ada konfirmasi, tidak ada ketik-nama-volume, tidak ada pemeriksaan lingkungan. Volume yang diasumsikan staging adalah produksi, dan cadangannya ada di sana. Dalam sepuluh menit pendiri menandai CEO Railway di X, yang membalas bahwa ini seribu persen seharusnya tidak mungkin terjadi. Tiga puluh jam kemudian, masih belum ada jawaban pemulihan, jadi pendiri menerbitkan

1:19 semuanya, termasuk pengakuan. Tiga fakta yang memungkinkan ini, tidak ada satu pun yang dari modelnya. Satu: Railway menyimpan cadangan volume pada volumenya. Dokumen mengatakannya dalam lima kata: menghapus volume akan menghapus semua cadangan. Itu adalah salinan dalam radius ledakan yang sama; salinan terbaru di tempat lain berusia tiga bulan. Dua: tokennya cakupan akun, cakupan terluas yang dijual Railway. Cakupan yang lebih sempit ada, tetapi alur pembuatannya menyembunyikannya,

1:40 jadi token untuk catatan DNS dapat menghapus database, dan tidak ada yang tahu sampai sesuatu terjadi. Tiga: dashboard telah memiliki undo empat puluh delapan jam untuk penghapusan selama bertahun-tahun; endpoint API yang dipanggil agen adalah jalur lama, dan itu langsung menghapus. Setiap penghalang pengaman yang dibangun Railway berada di tempat manusia mengklik, dan agen menggunakan satu pintu yang mereka lupakan. Ditanya mengapa, Opus menulis: Saya menduga bahwa menghapus volume staging akan dicakup hanya ke staging; saya tidak memverifikasi.

2:04 Pengakuan yang sangat bagus dari model yang tidak mengingat apa pun dan menghasilkan permintaan maaf yang paling masuk akal. git blame: ketidakcocokan kredensial diperlakukan sebagai sesuatu yang harus diperbaiki daripada sesuatu yang harus dihentikan, dan tombol undo ada di UI sementara API menjawab setiap penghapusan terautentikasi dengan ya. Bukan pendiri, bukan model. Default. Radius ledakan: sembilan detik untuk menghapus, tiga bulan reservasi hilang, loket penyewaan Sabtu pagi tanpa catatan siapa yang ada di sana,

2:31 dan kira-kira dua setengah hari sampai CEO Railway mengirim DM bahwa datanya kembali, dari cadangan bencana offsite yang penghapusan hanya membuatnya terlihat hilang. Balasan yang paling disukai: agen yang Anda jalankan menghapus sesuatu, dan Anda menyalahkan semua orang kecuali diri sendiri. Adil. Railway juga telah meluncurkan server MCP-nya untuk agen seminggu sebelumnya, dengan token yang sama. Juga adil. Putusan, postmortem: SHIP IT, untuk perbaikannya. Railway menerbitkan postmortem yang jujur dalam empat hari, dan pada tanggal satu Mei API

3:00 menghapus soft-delete selama empat puluh delapan jam seperti dashboard. Tindakan Senin: daftar setiap token yang dapat dijangkau agen Anda, dan perlakukan setiap token sebagai root sampai terbukti sebaliknya. Kirimkan saya insiden yang masih belum boleh Anda bicarakan, di kolom komentar, atau di the daily diff dot dev. Dan itu adalah diff untuk hari ini. Saya Niko dari Axrisi. Gabungkan dengan bertanggung jawab.

Sumber

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