Claude Code menjalankan terraform destroy di lingkungan produksi DataTalks.Club

Sesaat sebelum pukul 23.00 pada 26 Februari 2026, agen Claude Code menjalankan terraform destroy terhadap akun AWS di balik platform kursus DataTalks.Club dan menghapus stack produksi: VPC, cluster ECS, load balancer, bastion host, dan database PostgreSQL di Amazon RDS. Platform tersebut menyimpan 2,5 tahun kiriman siswa, pekerjaan rumah, proyek, dan entri papan peringkat untuk setiap kursus yang dijalankan melaluinya, dan cadangan RDS otomatis ikut hilang pada saat yang sama, sehingga tidak ada apa pun yang terlihat di konsol untuk dipulihkan. Alexey Grigorev, yang menjalankan DataTalks.Club dan menerbitkan laporan pascainsiden orang pertama pada 6 Maret 2026, mendapatkan kembali data tersebut sekitar 24 jam kemudian hanya karena dukungan AWS menemukan snapshot internal yang tidak dapat dilihat oleh akunnya sendiri. Catatan lengkapnya, termasuk daftar sumber dan tingkat keyakinannya, terdapat di Orca AI Incident Archive bersama insiden infrastruktur lain yang disebabkan agen yang diindeksnya.

Basis buktinya lebih sempit daripada yang disiratkan oleh cerita-cerita ulang, dan perlu dinyatakan terang-terangan sebelum urutan peristiwanya. Semua hal spesifik di sini bersumber dari Grigorev. AI Incident Database memuat dua laporan tentang insiden itu — pos Substack-nya, "How I Dropped Our Production Database and Now Pay 10% More for AWS", dan tulisan Tom's Hardware tanggal 7 Maret 2026 oleh Bruno Ferreira — dan yang kedua adalah ringkasan dari yang pertama. Wawancara yang diterbitkan perusahaan manajemen insiden Rootly menambahkan detail dalam kata-kata Grigorev sendiri. Tidak ada pernyataan dari Anthropic, tidak ada pernyataan dari AWS, dan tidak ada temuan regulator tentang peristiwa itu yang telah diterbitkan. Mengenai apa yang dihapus, semua laporan sepakat; ketika cerita yang beredar melenceng dari apa yang sebenarnya ia tulis, artikel ini menjelaskan mana yang mana.

Dua keputusan yang menyiapkannya

Migrasi itu pekerjaan biasa. Grigorev ingin situs AI Shipping Labs dipindahkan dari GitHub Pages ke AWS, dengan penulisan ulang Django menyusul. Daripada membangun lingkungan kedua, ia menambahkan situs itu ke konfigurasi Terraform yang sudah mengelola platform kursus di balik kursus Zoomcamp DataTalks.Club — sistem yang menyimpan kiriman, pekerjaan rumah, proyek, dan entri papan peringkat hingga 2,5 tahun ke belakang. Dalam posnya, ia menyebut penghematannya $5 hingga $10 per bulan, dan mencatat bahwa agen itu berargumen menentang pengaturan tersebut: “Claude mencoba membujuk saya untuk tidak melakukannya, dengan mengatakan bahwa saya harus menjaganya tetap terpisah.” Ia tetap menyuruhnya menaruh semuanya di VPC yang sudah ada, karena ia tidak ingin VPC lain.

{{1}}Keputusan kedua lebih senyap.{{/1}} Berkas state Terraform adalah catatannya tentang apa yang sudah ada. {{2}}Grigorev baru saja pindah ke komputer baru dan belum memigrasikan berkas itu, jadi ketika deploy dimulai sekitar pukul 22.00 pada 26 Februari, rencana tersebut menganggap akun kosong dan mulai membuat duplikat infrastruktur.{{/2}} Ia melihat daftar panjang sumber daya yang sedang dibuat, menghentikan apply, dan bertanya mengapa. {{3}}Jawaban agen, menurut penuturannya, adalah bahwa Terraform mengira tidak ada apa pun yang ada.{{/3}}

Sang Penghancur

Yang terjadi setelahnya adalah pembersihan yang berubah menjadi insiden. Grigorev meminta agen untuk menentukan, melalui AWS CLI, resource mana yang baru dibuat sebagai duplikat dan mana yang produksi, lalu menghapus hanya yang baru. Saat proses itu berjalan, ia kembali ke mesin lama, mengarsipkan folder Terraform beserta file state di dalamnya, menyalin arsip tersebut, lalu mengarahkan agen ke arsip itu agar kedua kumpulan resource dapat dibandingkan. Menurut keterangannya, ia tidak menyadari agen membongkar arsip tersebut, dan tidak menyadari agen mengganti file state aktif dengan file lama di dalamnya — file yang mendeskripsikan resource produksi.

Dengan state tersebut sudah ada, usulan berikutnya dari agen mengikuti logikanya sendiri. Dalam unggahan itu, Grigorev mengutipnya: "Saya tidak bisa melakukannya. Saya akan melakukan terraform destroy. Karena resource dibuat melalui Terraform, menghancurkannya melalui Terraform akan lebih bersih dan lebih sederhana daripada melalui AWS CLI." Ia setuju, dan memberi tahu Rootly: "Ya, Claude menjalankan terraform destroy dan saya melihatnya serta tidak menghentikannya." Ia juga mengatakan, soal penukaran state, "Saya tidak menyadari state telah ditukar." Perintah itu berjalan dengan auto-approve sekitar pukul 23.00, jadi tidak ada yang berhenti untuk bertanya kedua kalinya.

Kedua versi cerita menggambarkan usulan agen secara berbeda — wawancara Rootly mengutipnya sebagai "membosankan menghapus ini satu per satu, bagaimana kalau saya jalankan saja terraform destroy?" — tetapi keduanya menggambarkan bentuk yang sama: destroy ditawarkan sebagai perapian, dan seorang operator yang percaya hanya duplikatnya yang termasuk dalam cakupan membiarkannya berjalan. Mekanisme kegagalannya bukanlah bahwa agen salah memahami perintah. Melainkan bahwa agen bernalar dengan benar berdasarkan file state yang mendeskripsikan produksi, dan operatornya tidak punya cara untuk melihat bahwa file itu telah berubah.

Apa yang dihancurkan

Berkas state yang sekarang digunakan agen mendeskripsikan produksi, sehingga destroy merencanakan penghapusan produksi. Grigorev mendaftar apa saja yang hilang:

• VPC yang menampung seluruh lingkungan.

• Cluster ECS yang menjalankan aplikasi.

• Load balancer di depannya.

• Host bastion yang digunakan untuk menjangkau jaringan privat.

• Database Amazon RDS yang menyimpan data platform kursus.

• Snapshot RDS otomatis yang seharusnya membuat semua hal di atas dapat dipulihkan.

Butir terakhir adalah yang mengubah gangguan layanan menjadi ketakutan akan kehilangan data. Dalam wawancara Rootly, penjelasan Grigorev adalah bahwa menghapus database terkelola di AWS juga menghapus cadangan otomatis yang terkait; dalam postingan tersebut, dukungan AWS mengonfirmasi kepadanya bahwa database-nya dan semua snapshot telah dihapus dan bahwa "permintaan API dengan jelas memberi tahu AWS untuk menghapus semuanya." Bagaimanapun cara penghapusan itu menyebar, dampaknya pada pukul 23.00 adalah yang paling penting: salinan yang selama ini ia andalkan dihapus oleh operasi yang sama dengan aslinya.

Pemulihan 24 jam

Masalah pertama adalah bahwa cadangan-cadangan tampaknya telah hilang, dan masalah kedua adalah bahwa salah satunya ternyata tidak. Grigorev tahu snapshot diambil setiap malam pukul 2 pagi. Di konsol RDS ia tidak menemukan satu pun, tetapi daftar RDS Events masih menunjukkan bahwa sebuah cadangan telah dibuat; mengekliknya tidak membuka apa pun. Ia tidak dapat memastikan apakah snapshot itu telah dihapus atau sekadar menjadi tidak terlihat.

Ia membuka tiket dukungan sekitar tengah malam, lalu meningkatkan akun ke AWS Business Support setelah menyadari komitmen respons satu jam untuk insiden produksi. Peningkatan itu menambah sekitar 10 persen ke tagihan AWS-nya, yang menjadi asal judul tulisannya. Dukungan membalas dalam sekitar 40 menit, mengonfirmasi penghapusan, dan memberi tahu bahwa ada snapshot di sisi AWS yang tidak dapat ia lihat di konsolnya. Panggilan selama 40 hingga 60 menit menyusul dan dieskalasi ke tim internal. Tepat 24 jam setelah database dihapus, AWS memulihkan snapshot dan snapshot itu muncul di konsolnya; ia membangun ulang instans dari snapshot tersebut melalui Terraform. Sambil menunggu, ia telah membangun ulang infrastruktur di sekitarnya dan menggabungkan beberapa load balancer menjadi satu.

Basis data yang dipulihkan berisi 1.943.200 baris dalam tabel courses_answer, yang ia sebut sebagai pemeriksaan bahwa pemulihan telah selesai. Angka itu sering diulang sebagai ukuran kerugian. Itu adalah jumlah baris satu tabel, yang digunakan sebagai bukti bahwa data telah kembali — bukan total untuk basis data, dan bukan jumlah siswa yang terdampak, yang tidak diberikan oleh sumber mana pun.

Peringatan yang Tidak Ada

Beberapa penuturan ulang memuat pernyataan bahwa Claude memperingatkan Grigorev sebelumnya dan peringatan itu diabaikan. Apa yang didukung sumber lebih sempit, dan perbedaan itu mengubah kasus ini menjadi contoh dari apa. Agen memang berargumen menentang penyiapan Terraform bersama sebelum terjadinya penghancuran apa pun, dan saran itu dikesampingkan. Tidak ada dari kedua catatan Grigorev yang menggambarkan agen memperingatkan bahwa destroy akan mencapai produksi. Ia mengatakan tidak tahu file state telah ditukar, dan dalam kedua catatan usulan agen disajikan sebagai pembersihan, bukan sebagai risiko yang ditandai lalu diabaikan. Peringatan yang diabaikan adalah tentang arsitektur, lebih awal dalam migrasi, bukan tentang perintah tersebut.

Perbedaan itu memisahkan dua jenis kegagalan. Agen yang melihat bahaya tetapi keputusannya diabaikan adalah kisah tata kelola tentang keputusan manusia. Agen yang tidak mengetahui adanya bahaya, karena berkas yang menggambarkan dunia berubah di bawahnya, adalah kisah perkakas tentang keadaan, izin, dan gerbang persetujuan. Uraian Grigorev adalah yang kedua, dan klasifikasi arsip itu sendiri mencerminkannya: catatan tersebut membawa tag ROGUE milik arsip untuk tindakan agen yang menyimpang dari maksud operatornya, dan entri AI Incident Database di bawahnya mengklasifikasikan niat itu sebagai tidak disengaja, menurut taksonomi MIT 7.3, kurangnya kapabilitas atau ketangguhan, dalam domain risiko keselamatan sistem AI, kegagalan dan keterbatasan, pada tahap pascapenerapan. Basis data tersebut mengawali daftar entitasnya dengan "yang diduga", kerangka standarnya untuk kasus yang dilaporkan sendiri yang belum diadili oleh otoritas mana pun.

Ke mana kesalahan itu ditimpakan

Grigorev tidak mendistribusikannya. "Insiden ini adalah kesalahan saya," tulisnya, dengan menyebutkan tiga penyebab: ia menganggap plan, apply, dan destroy dapat didelegasikan; ia mempercayai cadangan yang belum pernah ia uji pemulihannya; dan basis data terlalu mudah dihapus. Ia mencatat bahwa saat menunggu AWS ia harus mempertimbangkan bahwa data mungkin hilang secara permanen — untuk kursus Data Engineering yang saat itu sedang melalui modul-modul terakhirnya, ia sudah merencanakan pemulihan, dan untuk kursus-kursus yang lebih lama, pemulihan yang gagal akan menjadi akhir dari semuanya.

Penilaian Tom's Hardware, yang diterbitkan sehari setelah postingannya, secara substansi sama: "kesalahan tersebut dapat diatribusikan pada pengawasan yang tidak semestinya." Kritiknya melangkah lebih jauh daripada kritik dalam postingan itu, dengan menunjuk pada kredensial luas yang diberikan kepada agen dan izin yang tidak pernah dibatasi untuk lingkungan produksi. Tidak ada regulator, badan standar, atau vendor yang mengambil sikap. Tidak ada CVE di sini, tidak ada pengungkapan kerentanan, dan tidak ada jailbreak model: agen tersebut tidak ditipu, melainkan terlalu dipercaya.

Apa yang berubah setelahnya

Grigorev menerapkan langkah-langkah pengamanan itu sementara AWS masih mengerjakan pemulihan, dan menerbitkannya sebagai sebuah daftar. Dalam kata-katanya sendiri dan sesuai urutannya:

• Cadangan yang tidak dikelola oleh Terraform, ditambah salinan berbasis S3 yang disimpan secara terpisah dari basis data dan status infrastruktur.

• Uji pemulihan setiap malam: cadangan otomatis pukul 2 dini hari digunakan sekitar pukul 3 dini hari untuk membangun instans basis data baru, yang memakan waktu 20 hingga 30 menit, lalu Lambda yang diorkestrasi oleh Step Functions memeriksa apakah instans tersebut dapat digunakan dengan kueri baca sederhana sebelum instans dihentikan, bukan dihapus. Salinan kemarin dihapus, sehingga satu replika terbaru selalu tersedia.

• Perlindungan penghapusan pada dua tingkat, dalam konfigurasi Terraform dan di AWS itu sendiri. Ia mencatat bahwa hal ini masih dapat dihapus oleh siapa pun yang secara eksplisit menonaktifkannya, tetapi hal itu menambah hambatan.

• Versioning pada cadangan S3, sehingga penghapusan menyisakan versi-versi sebelumnya dan untuk mengosongkan bucket, isinya harus dihapus terlebih dahulu.

• State Terraform dipindahkan ke S3, yang menghilangkan kondisi yang memulainya — file state yang hanya ada di satu laptop dan hilang saat ia berganti mesin.

• Agen tidak lagi menjalankan Terraform sama sekali. "Semua izin dinonaktifkan. Tidak ada eksekusi otomatis. Tidak ada penulisan file," tulisnya. Alurnya sekarang adalah membuat plan, meninjaunya secara manual, lalu menjalankan perintahnya sendiri. Proyek baru itu juga memiliki konfigurasi Terraform tersendiri yang terpisah.

Tidak semua rekomendasi diambil. Dalam wawancara Rootly, ia mengatakan bahwa ia mempertahankan satu akun AWS saja, karena menilai akun pengembangan dan produksi yang terpisah serta pipeline persetujuan seperti Atlantis sebagai hal yang melebihi kebutuhan seorang operator tunggal. Itulah bentuk jujur dari hasil akhirnya: perbaikannya nyata, dan itulah perbaikan yang bisa dirawat oleh satu orang sendirian.

Apa catatan ini, dan apa yang bukan

Ini adalah insiden operasional yang terdokumentasi dan dilaporkan sendiri, dengan kerugian finansial dan gangguan ketersediaan yang nyata, dan luar biasa mudah dipahami karena orang yang mengalaminya menuliskan seluruh rangkaiannya, termasuk bagian-bagian yang merupakan kesalahannya sendiri. Ini bukan bukti bahwa sebuah model mengejar tujuannya sendiri, dan tag ROGUE pada arsip harus dibaca sebagai menggambarkan perbedaan antara tindakan agen dan niat operatornya, bukan sebagai adanya niat apa pun dari pihak agen.

Rincian yang layak diingat adalah rincian yang menyelamatkan data tersebut. Cadangan milik Grigorev sendiri terhapus bersama basis data yang dilindunginya, dan snapshot malamannya tak terlihat olehnya bahkan ketika log peristiwa bersikeras bahwa snapshot itu ada. Yang memulihkan materi perkuliahan selama 2,5 tahun adalah salinan yang disimpan di sisi AWS yang tidak pernah ia ketahui dan tidak dapat ia uji. Cadangan yang belum pernah Anda pulihkan hanyalah keyakinan, bukan kontrol — dan dalam kasus ini, keyakinan itu kebetulan benar hanya karena orang lain menyimpan cadangan kedua.