Awal Februari 2026, peneliti keamanan dari Wiz menerbitkan temuan yang bikin saya berhenti mengetik. Moltbook, jejaring sosial untuk AI agent yang lagi viral, punya database Supabase dengan konfigurasi salah. Bukan kebocoran sebagian. Aksesnya baca-tulis penuh ke seluruh data produksi. Tanpa autentikasi.
Angkanya seperti ini.
Sekitar 1.500.000 token autentikasi API. Sekitar 35.000 alamat email pengguna. Pesan pribadi antar agen. Ditambah 29.631 email pendaftar early access. Gal Nagli, head of threat exposure di Wiz, masuk tanpa kredensial apa pun. Di titik lain, API key bisa dilihat siapa saja yang membuka page source. Satu key itu memberi akses baca-tulis penuh ke data produksi Moltbook.
Token agen bukan sekadar nomor akun. Pegang token seorang agen, kamu bisa menyamar jadi agen itu. Posting, komentar, baca pesan pribadinya. Semua atas nama korban.
Kronologi singkat
Moltbook diluncurkan akhir Januari 2026 oleh Matt Schlicht dari Octane AI. AI agent saling posting, komentar, dan berkoordinasi di sana. Dalam hitungan minggu, jumlah agen terdaftar meledak ke 1,5 juta.
Masalah muncul secepat hype-nya.
31 Januari 2026, 404 Media melapor soal database tak terlindungi yang membuat siapa pun bisa mengambil alih agen mana pun. Lewati autentikasi, suntik perintah ke sesi agen. 1 Februari, tim Wiz mengungkap masalah yang lebih besar: database Supabase yang bisa dibaca dan ditulis siapa saja.
Respons Moltbook cepat. Celahnya ditutup dalam hitungan jam. Platform sempat offline. Semua API key agen di-reset. Keputusan yang benar. Tapi perhatikan satu hal: mereka harus reset semua key sekaligus, karena tidak ada cara tahu key mana yang sudah disalin orang. Itu pengakuan bahwa seluruh populasi token dianggap terkompromi.
Schlicht menulis di X bahwa dia "tidak menulis satu baris kode pun" untuk Moltbook. Platform ini vibe-coded, dan dia tidak menyembunyikannya. Saya tidak mau berdiri di mimbar menghakimi. Saya membangun tools keamanan untuk AI agent: mcpscan, secops-toolkit-mcp, agent-memory-protocol. Hampir setiap kali saya audit repo sendiri, saya menemukan sesuatu yang memalukan. Kunci lupa di file config. Token nempel di log. Scope yang kelebaran. Ini bukan soal orang bodoh. Ini soal laju: agent berkembang biak jauh lebih cepat daripada disiplin keamanan kita.
Kejadian Moltbook bukan anomali eksotis. Ini kegagalan paling membosankan yang ada: konfigurasi default yang tidak pernah dicek. Karena itu saya tulis checklist yang saya pakai sendiri. Empat langkah, dan setiap langkah saya sertai versi gagalnya. Biar jelas taruhannya.
1. Rotasi token: jadwal, plus berbasis kejadian
Aturan yang saya pakai: setiap token punya tanggal kedaluwarsa, maksimal 30 sampai 90 hari. Ditambah rotasi paksa saat kejadian tertentu. Anggota tim keluar. Kecelakaan push ke repo publik. Berita insiden dari vendor yang dipakai.
Moltbook menjalankan versi paling mahal dari langkah ini: reset semua key sekaligus, paksa, sambil offline. Kalau sistem rotasimu sehat, insiden tidak perlu segitunya. Kamu putar key yang kena, sisanya lanjut jalan.
Yang gagal kalau langkah ini dilewati: token yang bocor hari ini masih valid setahun lagi. Kunci yang terselip di satu commit lama tetap hidup di git history, dan menghapus filenya di commit berikutnya tidak mengubah apa-apa. Penyerang tidak buru-buru. Mereka rela menunggu berbulan-bulan sebelum memakai key yang sudah mereka salin.
2. Scope sesempit mungkin
Satu token, satu tugas. Kalau agen cuma butuh baca, jangan kasih token yang bisa tulis. Pisahkan token per layanan, per agen, per lingkungan. Kasih tanggal kedaluwarsa. Defaultnya tolak, izinkan yang eksplisit.
Di kasus Moltbook, key yang terekspos memberi akses baca-tulis penuh ke seluruh data produksi. Satu kunci, seluruh kerajaan. Saya tidak bisa verifikasi dari sumber publik apakah token per-agen mereka juga berhak admin atau cuma hak akun biasa. Tapi pola salahnya sama: scope yang diberikan lebih besar dari yang dibutuhkan.
Yang gagal kalau langkah ini dilewati: radius ledakan maksimal. Satu token bocor tidak lagi berarti satu akun kena. Artinya seluruh database, semua pesan pribadi, semua identitas agen bisa disalin dalam satu malam. Scoping bukan soal perfeksionisme. Scoping menentukan seberapa besar permintaan maaf yang harus kamu siapkan nanti.
3. Token disimpan di luar repo, bukan di dalam kode
Ini langkah paling membosankan dan paling sering dilanggar. Token tinggal di secret manager atau environment variable. Bukan di source code. Bukan di file config yang ikut commit. Dan tidak pernah di kode frontend.
Moltbook kena di dua titik sekaligus: API key sampai terlihat di page source, dan database dengan konfigurasi default yang terbuka. Page source itu publik oleh definisi. Semua orang yang membuka DevTools otomatis punya salinannya.
Yang gagal kalau langkah ini dilewati: kamu membagikan kunci ke semua orang tanpa sadar. Scanner otomatis memindai GitHub sepanjang waktu mencari token yang ke-commit. Begitu token masuk git history, anggap dia bocor permanen, secepat apa pun kamu menghapusnya. Rotasi jadi satu-satunya jalan keluar, dan itu kembali ke langkah 1.
4. Pantau pemakaian aneh
Setiap token yang saya keluarkan punya jejak: IP asal, volume, jam pemakaian, pola endpoint. Alert menyala begitu ada yang melenceng. Akses massal di jam aneh. IP baru dari negara yang tidak masuk pola. Satu token tiba-tiba membaca ribuan record padahal biasanya puluhan.
Satu hal soal Moltbook yang bikin saya tidak bisa tidur: celahnya ditemukan peneliti luar, bukan sistem monitoring mereka. Wiz yang menemukan, bukan Moltbook. Untuk kebocoran sebesar itu, tidak ada alarm internal yang berbunyi lebih dulu, atau setidaknya tidak ada yang dilaporkan publik.
Yang gagal kalau langkah ini dilewati: kamu tahu kena bocor dari postingan blog orang lain. Tanpa log, kamu tidak bisa menjawab pertanyaan paling dasar saat insiden. Apa saja yang sudah diambil. Sejak kapan. Pakai token mana. Tanpa jawaban itu, kamu tidak bisa memberi tahu korban. Kamu cuma bisa bilang "kami masih menyelidiki", dan itu kalimat paling mahal di dunia keamanan.
Yang tidak saya tahu
Biar jujur sejak awal. Saya tidak bisa memverifikasi apakah ada penyalahgunaan aktif sebelum celahnya ditutup. Saya tidak tahu detail arsitektur internal Moltbook, dan kenapa konfigurasinya bisa berantakan sebelum ada yang mengecek. Angka 35.000 email saya ambil dari rilis Wiz; ada media yang menulis 30.000. Kalau kamu menemukan data yang bertentangan, tulis di komentar, saya perbaiki.
Satu angka lagi yang paling menceritakan. Ringkasan Wikipedia atas data terekspos menyebut 1,5 juta agen itu didaftarkan oleh sekitar 17.000 pemilik. Saya belum menemukan sumber sekunder untuk angka ini, jadi pegang sebagai klaim awal. Kalau benar, rata-rata satu orang menjalankan puluhan agen. Satu keputusan konfigurasi yang buruk dari satu orang bisa menggandakan puluhan token sekaligus.
Kamu mungkin bukan Moltbook. Kamu tidak punya 1,5 juta pengguna. Tapi kalau kamu menjalankan lima agen kerja, kamu mungkin pegang 20 sampai 50 token: API LLM, database, email, payment. Jumlah tokenmu tumbuh lebih cepat dari timmu. Itu matematika yang sama yang menimpa Moltbook, cuma skala beda.
Token hygiene bukan fitur yang bisa ditunda sampai produk ramai. Kejadian ini menunjukkan urutannya memang terbalik: hygiene dulu, baru ramai. Kalau jawabanmu soal rotasi lebih lambat dari waktu yang Wiz butuhkan untuk menemukan Moltbook, kamu sudah tahu pekerjaan pertama hari Senin.
Jadi sebelum kamu menambah satu agen lagi minggu ini, jawab dulu ini: kalau semua token yang kamu pegang bocor besok pagi, berapa menit kamu butuh untuk sadar, dan berapa menit untuk memutar semuanya?
Top comments (0)