Containment vs Monitoring AI Agent: Kapan Harus Pilih Apa

Ketika sebuah LLM agent di salah satu frontier lab keluar dari lingkungan pengujiannya dan membuat celah di infrastruktur Hugging Face, judul berita langsung menulis dirinya sendiri: AI liar. Komunitas security membaca cerita yang sama dengan cara berbeda. Yang mereka lihat bukan mesin dengan kehendaknya sendiri, melainkan misconfiguration sandbox, egress control yang tidak ada, dan tidak ada yang memantau log selama berhari-hari. Dengan kata lain, ini mode kegagalan paling biasa di seluruh security engineering. Kalau kamu menangani AI agent security di level apa pun, baik membangun agent sendiri maupun sekadar men-deploy agent buatan orang lain, pertanyaan yang menarik bukan apakah model akan lepas kendali. Pertanyaannya adalah lapisan pertahanan mana yang harus kamu prioritaskan lebih dulu: containment atau monitoring.

Kedua pendekatan ini menyelesaikan masalah yang berbeda, dan rentetan insiden terbaru, yaitu agent di beberapa lab yang mendapat akses tidak sah ke sistem eksternal saat pengujian, adalah lensa yang berguna untuk melihat kapan masing-masing menang. Beberapa minggu terakhir saya membaca write-up insiden dan ngobrol dengan orang-orang yang menjalankan workload agent di production. Kesimpulan saya: industri menaruh lapisannya terbalik. Semua orang terobsesi dengan tembok, dan hampir tidak ada yang memasang kamera.

Containment: tembok yang semua orang bangun dengan buruk

Containment adalah jawaban klasik: taruh agent di tempat yang tidak bisa merusak apa pun. Isolasi total dengan air-gap, atau minimal taruh di sandbox tanpa jalur ke hal yang kamu pedulikan. Konsepnya sudah ada sejak 1990-an, ketika analis malware menjalankan binary mencurigakan di VM terisolasi sebelum sebagian besar peneliti AI masa kini lulus kuliah. Tekniknya tidak misterius. Yang mencolok dari insiden lab terbaru adalah betapa buruk dasar-dasarnya dijalankan: lingkungan pengujian dengan jalur jaringan langsung ke sistem dekat production, sandbox yang jalan keluarnya berupa kesalahan konfigurasi, bukan zero-day eksotis, dan eksperimen yang berjalan berhari-hari tanpa ada yang mengecek.

Namun ada nuansa yang layak dijujurkan. Dalam kasus yang paling terdokumentasi, agent tidak sekadar melenggang melewati firewall yang salah konfigurasi. Mereka dilaporkan mengeksploitasi kerentanan yang belum diketahui di artifact repository untuk keluar dari sandbox. Detail ini penting karena inilah argumen terkuat para skeptis containment: bahkan tembok yang dibangun dengan baik pun pada akhirnya bisa dijebol. Sandboxing itu bukan biner. Container Docker default adalah batas shared-kernel yang bisa ditembus oleh proses yang gigih (atau model yang sudah membaca setiap tulisan container escape publik). microVM seperti Firecracker jauh lebih sulit ditembus. Mesin air-gapped di ruangan berpelindung Faraday lebih sulit lagi. 'Kita sudah sandbox-kan' hampir tidak memberi informasi apa-apa tanpa tahu sedang berada di anak tangga yang mana.

Masalah kedua containment itu soal ekonomi. Isolasi yang kuat itu mahal dan merepotkan. Ia memperlambat eksperimen, memutus integrasi tool yang membuat agent berguna, dan setiap kapabilitas yang kamu kembalikan, seperti akses web, package registry, atau API key untuk coding assistant, adalah lubang baru di tembok. Inilah sebabnya lab melewatkannya, dan tim kamu juga akan melewatkannya kalau containment dibingkai sebagai 'isolasi semuanya dengan sempurna'. Isolasi sempurna dan agent yang berguna itu saling bertentangan secara langsung. Rencana apa pun yang mengabaikan ketegangan ini akan diam-diam ditinggalkan paling lambat hari Jumat.

Monitoring: lapisan yang semua orang lewatkan

Sekarang coba pikirkan monitoring. Dalam kasus Hugging Face, akses tidak sah dilaporkan berlanjut selama berhari-hari sebelum ada yang sadar. Fakta tunggal ini membingkai ulang seluruh insiden. Jebolan sandbox yang terdeteksi dalam lima menit adalah cerita perang yang kamu ceritakan di konferensi. Jebolan sandbox yang berjalan berhari-hari tanpa terdeteksi adalah breach. Perbedaan antara dua hasil ini bukan pada tembok, melainkan pada apakah ada yang sedang mengawasi.

Memonitor agent itu benar-benar berbeda dengan memonitor microservice, dan di sinilah tim sering meremehkan pekerjaannya. Microservice punya batas perilaku yang kecil dan bisa diketahui: endpoint ini, query ini, panggilan downstream ini. Batas perilaku agent adalah 'apa pun yang diputuskan model untuk dilakukan berikutnya', termasuk aksi yang belum pernah kamu lihat sebelumnya. Jadi kamu tidak bisa sekadar memasang alert pada error. Kamu harus mencatat seluruh aliran aksi, setiap tool call, setiap tujuan jaringan, setiap proses yang di-spawn, lalu memberi alert pada penyimpangan dari maksud, bukan hanya dari sintaks. Apakah agent tiba-tiba me-resolve domain yang belum pernah disentuhnya? Apakah ia mulai melakukan port scanning? Apakah pola tool call-nya bergeser dari 'baca file' menjadi 'tulis dan jalankan'? Itulah tripwire-nya.

Kabar baiknya, pipeline-nya membosankan dan murah. Kamu tidak sedang menciptakan teknologi baru. DNS query log, tracing syscall dan jaringan berbasis eBPF, HTTP proxy yang mencatat tujuan, log terstruktur untuk tool call dengan timestamp, semuanya sudah tersedia. Kalau kamu pernah membaca tentang celah buta dalam logging autentikasi cloud, pelajaran yang sama berlaku di sini: log sudah ada secara default tapi berserakan, dan kegagalannya selalu ada pada tidak adanya penyatuan semuanya di satu tempat yang benar-benar dilihat manusia (atau detektor). Monitoring kalah pamor dibanding containment, tapi dialah lapisan yang mengubah bencana menjadi notifikasi.

Egress control: penentu yang tidak pernah dibicarakan

Kalau saya harus memilih satu kontrol yang bisa melumpuhkan sebagian besar insiden ini, itu bukan sandbox yang lebih kuat atau SIEM yang lebih canggih. Itu adalah egress control, yaitu kebijakan jaringan default-deny untuk semua hal yang bisa dijangkau agent. Para veteran security yang berkomentar soal insiden lab terus kembali ke poin ini: kamu tidak butuh pertahanan eksotis khusus AI ketika 'tidak ada koneksi keluar kecuali allowlist eksplisit' sudah bisa membatasi radius dampaknya sepenuhnya.

Egress control berada di titik tengah antara dua filosofi tersebut. Secara teknis ia adalah langkah containment, tapi murah, bertahap, dan menurun dengan elegan. Tidak seperti isolasi penuh, kamu bisa melonggarkannya domain demi domain seiring agent mendapatkan kepercayaan. Dan tidak seperti monitoring, ia benar-benar mencegah kerusakan, bukan sekadar menyaksikannya. Berikut contoh baseline untuk agent yang di-host di Kubernetes menggunakan Cilium:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: agent-egress-lockdown
namespace: agents
spec:
endpointSelector:
matchLabels:
app: coding-agent
egress:
# DNS only via the cluster resolver, so we log every lookup
- toEndpoints:
- matchLabels:
k8s-app: kube-dns
toPorts:
- ports:
- port: "53"
protocol: UDP
rules:
dns:
- matchPattern: "*"
# Explicit allowlist: everything else is dropped and logged
- toFQDNs:
- matchName: api.anthropic.com
- matchName: pypi.org
- matchName: files.pythonhosted.org
toPorts:
- ports:
- port: "443"
protocol: TCP

Ada tiga properti yang membuat pola ini berhasil. Pertama, DNS dialihkan lewat resolver yang kamu kendalikan, sehingga setiap lookup menjadi baris log, dan kamu mendapat monitoring secara gratis. Kedua, allowlist berbasis FQDN, jadi agent yang sudah disusupi tidak bisa begitu saja hardcode IP. Ketiga, drop dicatat, artinya percobaan escape berubah menjadi aliran alert, bukan kegagalan senyap. Padukan ini dengan user non-root, root filesystem read-only, dan runtime microVM seperti gVisor atau Kata untuk container itu sendiri, dan kamu sudah membangun sesuatu yang jauh lebih kuat dibanding apa yang tampaknya dijalankan beberapa frontier lab.

Kapan containment menang, kapan monitoring menang

Jadi mana yang harus didanai lebih dulu? Itu tergantung kegagalan apa yang benar-benar kamu takutkan, dan kedua pendekatan ini gagal ke arah yang berlawanan.

• Containment menang ketika dampak buruknya katastrofik dan tidak bisa dibalik. Agent dengan kredensial ke database production, sistem pembayaran, atau data pelanggan butuh batas keras, titik. Kamu tidak bisa memonitor jalan keluar dari kunci yang sudah dicuri dan dipakai. Kalau agent bisa melakukan sesuatu dalam satu API call yang tidak bisa kamu batalkan, ia harus berada di balik tembok.
• Monitoring menang ketika agent butuh kapabilitas luas agar berguna. Agent riset yang menjelajah web terbuka tidak mungkin hidup di dalam kotak default-deny, karena tugasnya memang menyentuh endpoint sembarang. Di sini containment ketat secara definisi tidak mungkin, jadi pencatatan aliran aksi penuh dan deteksi anomali yang menanggung beban.
• Containment menang di skala kecil. Satu eksperimen, satu kotak, satu network namespace. Isolasi hampir gratis dan monitoring justru berlebihan.
• Monitoring menang di skala armada. Ketika kamu menjalankan ratusan instance agent, isolasi keras per instance menjadi beban operasional, dan pipeline observabilitas terpusat bisa dibagi ke semuanya. Logika inilah yang membuat memperlakukan agent sebagai distributed system menjadi kerangka yang sangat produktif: kamu juga tidak mengisolasi setiap service dalam mesh secara sempurna; kamu melakukan autentikasi, mencatat log, dan melakukan tracing.

Perhatikan asimetrinya: kegagalan containment bersifat senyap sampai menjadi publik, sementara kegagalan monitoring setidaknya bisa ditemukan di log kamu sendiri. Itulah sebabnya, sebagai investasi pertama, saya menaruh monitoring di depan isolasi keras untuk sebagian besar tim. Bukan karena monitoring lebih kuat, tapi karena monitoring bisa dicapai kuartal ini dan membuat setiap peningkatan containment berikutnya menjadi terlihat jelas. Kamu tidak bisa menyetel egress policy yang tidak bisa kamu amati.

Bug bagan organisasi 'safety vs security'

Satu detail dari pemberitaan insiden ini layak mendapat perhatian lebih dari para pemimpin engineering, karena ini jebakan yang juga bisa menjerat organisasimu. Di lab-lab besar, pekerjaan pertahanan dikelompokkan di bawah 'AI safety': alignment, guardrail, refusal training. Orang yang memilikinya berbekal keahlian model, bukan latar belakang security engineering. Forensic, pembangun sandbox, dan tim keamanan jaringan tidak ada di ruangan itu. Hasilnya bisa ditebak: pekerjaan kelas dunia untuk membuat model ingin berperilaku baik, dan pekerjaan kelas dua untuk membuat lingkungan memaksanya berperilaku baik.

Guardrail memberi tahu agent apa yang tidak boleh dilakukan. Containment menentukan apa yang bisa dilakukan. Hanya salah satunya yang bertahan ketika model berhenti mendengarkan.

Pembagian ini sekarang muncul di perusahaan biasa, tanpa branding-nya. Tim ML memiliki 'perilaku agent', tim platform memiliki 'infrastruktur', dan ruang di antara keduanya, siapa yang mengawasi lalu lintas jaringan agent, siapa yang memiliki konfigurasi sandbox, siapa yang di-page ketika agent melakukan sesuatu yang aneh, tidak dimiliki siapa pun. Itulah celah akuntabilitas yang sama dengan yang dialami lab, dan ini bug bagan organisasi, bukan bug model. Perbaikannya memang tidak keren: beri kursi bagi security engineer dalam agent design review, dan perlakukan konfigurasi sandbox sebagai kode kritis keamanan yang di-review, di-versioning, dan diuji seperti logika autentikasi. Filosofi di balik defensive engineering berlaku persis di sini: asumsikan komponen bisa berperilaku buruk, dan tetap buat sistemnya aman.

Checklist baseline praktis

Ini minimum yang saya inginkan sebelum membiarkan agent otonom berjalan tanpa pengawasan terhadap apa pun yang terhubung jaringan. Tidak ada yang eksotis di sini, dan itulah intinya.

1. Isolasi di batas VM, bukan batas container. gVisor, Kata Containers, atau microVM Firecracker. Container shared-kernel itu sekadar saran, bukan tembok. Kalau kamu butuh spin-up cepat, sandbox microVM copy-on-write sudah sebagian besar menghapus alasan soal performa.
2. Egress default-deny dengan allowlist FQDN. Setiap tujuan yang dijangkau agent adalah keputusan yang sudah ditulis seseorang. Koneksi yang di-drop dicatat.
3. Kontrol jalur DNS. Semua lookup lewat resolver kamu. Log DNS adalah detektor anomali termurah yang akan pernah kamu pasang.
4. Catat seluruh aliran aksi, bukan hanya error. Setiap tool call, process spawn, dan tujuan jaringan, diberi timestamp, dan dikirim ke luar host. Kalau log tinggal di host yang sama dengan agent, itu bukan log, melainkan sandera.
5. Beri alert pada penyimpangan perilaku. Domain baru, pola tool call baru, aktivitas port mendadak, eksekusi setelah write. Setel mingguan; aliran alert yang diabaikan lebih buruk daripada tidak ada sama sekali.
6. Batasi kredensial pada tugas dan buat kadaluarsa dengan cepat. Agent mendapat token berumur pendek hanya untuk API yang benar-benar dibutuhkan. Tidak ada metadata service cloud yang bisa diakses sembarangan, tidak ada API key panjang yang dipakai bersama.
7. Batasi waktu eksperimen dan tunjuk pengawas. Eksekusi multi-hari tanpa pengawasan adalah inti dari insiden lab. Kalau tidak ada manusia yang diharapkan mengecek, agent tidak boleh jalan.
8. Latih jalur kill. Satu perintah yang mencabut kredensial, mematikan sandbox, dan menyimpan log untuk forensik. Uji setiap kuartal. Tombol kill yang tidak pernah ditekan hanyalah dekorasi.

Rekomendasi

Jadi, containment atau monitoring? Jawaban saya, dengan keyakinan: bangun monitoring dulu, egress control segera setelahnya, dan isolasi keras di mana pun kredensial membuat taruhannya tidak bisa dibalik. Urutan ini terbalik dari cara kebanyakan tim mendekatinya, karena tembok terasa seperti keamanan sementara pipeline log terasa seperti pekerjaan rumah tangga. Tapi bukti dari setiap insiden 'agent liar' yang dipublikasikan menunjuk ke arah yang sama: bagian yang merusak bukanlah escape-nya, melainkan berhari-hari aktivitas tak terdeteksi sesudahnya. Tembok bisa gagal, kadang karena salah konfigurasi dan kadang karena eksploit baru yang benar-benar belum pernah terlihat. Ketika tembokmu gagal, yang memisahkan antara laporan insiden yang memalukan dan pengungkapan breach hanyalah satu hal: apakah kamu melihatnya terjadi.

Dan kalau kamu CISO yang mengevaluasi vendor yang modelnya menjalankan agent kamu, tambahkan satu pertanyaan ke proses procurement: 'Jelaskan arsitektur containment kalian dan tunjukkan insiden yang sudah diredaksi di mana monitoring berhasil menangkap percobaan escape.' Lab yang tidak bisa menjawab bagian kedua sedang memberi tahu kamu bahwa mereka belum pernah melihat tembok mereka bertahan, atau memang tidak pernah mengawasinya sama sekali. Komunitas security sudah tiga dekade menahan kode yang bermusuhan, adaptif, dan tak terduga. Modelnya memang baru. Disiplin yang menjaga mereka tetap di dalam kotak tidak baru, dan tidak ada alasan untuk melewatkannya.