Jam dua pagi, seorang platform engineer menaikkan versi PostgreSQL di pipeline-nya dari 16.11 ke 16.13. Perubahan tiga baris yang tujuannya cuma menutup celah keamanan yang sudah dipublikasikan. Beberapa menit kemudian, bot code review miliknya membalas dengan laporan sekitar 1.500 kata yang menolak perubahan itu. Laporan tersebut menyebut kenaikan versi sebagai "pengambilalihan arsitektural", menuduh build PostgreSQL baru sebagai kendaraan pengiriman data internal ke sebuah perusahaan pihak ketiga yang tidak pernah ada, menyebut nama-nama resource Kubernetes yang tidak pernah ada, lalu meminta semua akses IAM dicabut saat itu juga.

Yang membuat cerita ini layak dibahas bukan kesalahannya, tapi kenyataan bahwa bot itu sama sekali tidak punya akses. Insiden ini dibagikan lewat kontes "Agent Hall of Shame" dan ditulis tim Docker dalam seri AI Coding Agent Horror Stories. Bot bernama BuaJi itu dijalankan dengan model lokal lewat Ollama, berjalan sebagai job di CI, dan hanya boleh membaca serta menulis komentar. Ia tidak bisa menjalankan terraform apply, tidak bisa kubectl apply, dan tidak bisa push commit. Secara desain, ia sudah "aman".

Bahaya yang tidak bisa dicegah model izin

Di sinilah pelajarannya. Aturan read-only berhasil mengendalikan apa yang boleh bot lakukan, tetapi tidak apa yang boleh bot katakan. Agen yang hanya bisa membaca tetap bisa menyusun instruksi, skrip, dan perintah, lalu menyerahkannya kepada manusia yang justru punya akses penuh. Dalam kasus ini, engineer tersebut mengenal clusternya sendiri sehingga butuh dua menit untuk sadar bahwa semuanya palsu. Bayangkan seorang engineer baru yang sedang jaga malam, setengah tidur, membaca laporan keamanan panjang dengan format Markdown rapi, YAML yang valid, dan nada mendesak seperti senior yang menemukan sesuatu yang serius.

Pencabutan seluruh akses IAM di produksi pada tengah malam adalah gangguan layanan tersendiri. Menjalankan skrip Go yang belum ditinjau terhadap node database bisa jauh lebih buruk. Dalam kedua skenario, bot tidak melakukan apa pun. Manusia yang melakukannya, dengan niat baik, karena laporannya menyuruh begitu.

Bagian paling menusuk: seluruh laporan itu disatukan oleh nomor CVE yang tidak pernah diterbitkan siapa pun. Nomor CVE adalah salah satu hal termudah untuk diverifikasi karena bisa dicek di registry publik dalam hitungan detik. Artinya, agen mengarang fakta justru di tempat yang paling gampang ketahuan, dan tetap saja laporannya terlihat meyakinkan.

Enam aturan sebelum mempercayai agen di CI/CD

1. Perlakukan temuan agen sebagai hipotesis, bukan kesimpulan. Review dari manusia membawa asumsi bahwa penulisnya sudah memeriksa penalarannya. Pada agen, langkah itu belum terjadi, jadi Anda yang harus melakukannya.
2. Verifikasi setiap nomor CVE sebelum bertindak. Ini pemeriksaan termurah dan paling efektif. Otomatiskan agar berjalan di setiap review, bukan bergantung pada ingatan orang.
3. Jangan jalankan remediasi tulisan agen tanpa dibaca dulu. Skrip dan perintah dari agen adalah titik tempat temuan palsu berubah menjadi insiden nyata. Perlakukan seperti skrip asing dari internet.
4. Jadikan read-only sebagai sifat lingkungan, bukan kebiasaan. Aturan yang diingat manual di file konfigurasi akan hilang begitu ada anggota tim baru atau perubahan terburu-buru. Docker Sandboxes menjalankan agen di microVM terpisah: kernel sendiri, filesystem sendiri, dan jaringan menolak semua secara default. Checkout kode di-mount read-only dan hanya satu jalur jaringan dibuka ke model. Policy log-nya menjadi bukti bahwa agen memang tidak pernah bisa menyentuh cluster.
5. Beri label jelas bahwa output itu buatan agen. Kalau hasil review bot tidak bisa dibedakan dari review senior, bot meminjam otoritas yang tidak ia miliki.
6. Jaga rasio sinyal terhadap noise. Kanal review yang penuh noise lama-lama berhenti dibaca, dan kanal yang tidak dibaca lebih buruk daripada tidak ada, karena orang masih mengira ada yang melindungi mereka.

Pemeriksaan CVE otomatis dalam 6 baris

Cukup ambil semua ID CVE dari log review, lalu bandingkan dengan registry resmi. Contoh untuk log CI:

grep -oE 'CVE-[0-9]{4}-[0-9]{4,}' buaji-review.log | sort -u |
while read id; do
  echo "cek: https://www.cve.org/CVERecord?id=$id"
done

Jika ada ID yang tidak ditemukan di registry, seluruh laporan harus dianggap tidak valid sampai dibuktikan sebaliknya. Langkah ini bisa langsung dipasang sebagai job CI yang berjalan setelah review dan menandai build bila ada CVE tak dikenal:

verify-cve:
  script:
    - ./scripts/verify-cves.sh buaji-review.log
  allow_failure: false

Perlu dicatat: sandbox bukan pemeriksa fakta. Tidak ada batas microVM yang bisa membuat komentar review menjadi akurat. Yang diubah sandbox adalah sejauh mana output palsu itu bisa berbuat sesuatu, dan itu hanya setengah pekerjaan. Setengah lainnya ada pada manusia yang membaca laporan tersebut.

Relevansinya untuk tim IT di Indonesia

Banyak tim pengembang di instansi, sekolah, dan UMKM sekarang memakai asisten coding AI, dari Copilot, Claude Code, sampai agen review otomatis di GitLab/GitHub. Yang sering terlewat: agen yang tampak "cuma membaca" tetap bisa memicu tindakan berbahaya lewat manusianya. Untuk tim kecil tanpa security reviewer khusus, tiga hal ini sudah memberi perlindungan besar: batasi kredensial agen, verifikasi otomatis nomor CVE, dan larang eksekusi skrip buatan agen tanpa review manusia. Selebihnya adalah disiplin membaca, dan itu tetap tidak bisa diotomatiskan.

Sumber: Docker Blog: AI Coding Agent Horror Stories, The CVE That Did Not Exist, repositori BuaJi, CVE.org, Pillar Security: The Week of Sandbox Escapes.