AI Blue Teaming Dijelaskan: Tiga Lapisan Tempat Sebuah Kontrol Sebenarnya Dapat Berada

Tanyakan kepada tim keamanan di mana guardrail AI mereka berada, dan jawabannya biasanya menyebutkan dokumen kebijakan, prompt sistem, atau fitur vendor. Tidak satu pun dari itu adalah kontrol. Kontrol adalah sesuatu yang memutuskan, pada saat tindakan berlangsung, apakah tindakan itu terjadi — dan bagi agen AI hanya ada tiga tempat yang dapat memutuskan: model, gateway di depannya, dan lingkungan di sekitarnya. Segala hal yang dapat dijanjikan tim blue team secara jujur berasal dari yang kedua dan ketiga. Inilah pertanyaan lapisan, dan ini mendahului setiap keputusan tim blue team lainnya, termasuk apa yang harus dicatat dan siapa yang harus dihubungi. Itu juga sebabnya bukti lapangan penting: arsip insiden AI memuat 400 insiden agen dari 2024-12 hingga 2026-10-17, dan sebagian besar bukan kisah tentang model yang berperilaku buruk. Itu adalah kisah tentang deployment yang tidak memiliki lapisan yang bisa mengatakan tidak.

Blue teaming dalam pengertian AI adalah pekerjaan memasang lapisan-lapisan itu, menyetel apa yang mereka perhatikan, dan memiliki jawaban yang sudah dilatih untuk hari salah satunya terpicu. Ini tidak glamor, tidak menghasilkan skor, dan hanya ini separuh dari pasangan red-team/blue-team yang mengubah angka risiko.

Apa yang diwarisi tim biru, dan apa yang tidak

Blue teaming tradisional bertumpu pada serangkaian asumsi yang secara diam-diam dilanggar oleh penerapan AI. Log diasumsikan lengkap, karena jaringan melihat setiap paket. Aset diasumsikan dapat dienumerasi, karena seseorang harus menyediakannya. Perilaku diasumsikan deterministik, karena sebuah program melakukan hal yang sama dengan input yang sama. Tidak satu pun dari ketiganya bertahan saat bersentuhan dengan agen.

Yang diwarisi tim biru sebagai gantinya adalah sistem tempat keputusan yang paling berdampak terjadi di dalam sebuah permintaan yang oleh lapisan jaringan dianggap sebagai lalu lintas HTTPS biasa ke satu nama host. Prompt, konteks yang diambil, panggilan alat, dan completion — semuanya berada di dalam body permintaan, dan jika tidak ada yang menangkap dan mengurai body tersebut, deployment secara fungsional tidak termonitor terlepas dari seberapa baik perimeter-nya. Tugas pertama tim biru karena itu bukan deteksi; itu adalah membangun sensor. Tanpa visibilitas tingkat permintaan dan tingkat alat, tidak ada yang dapat dideteksi, dan setiap kontrol hilir hanya dekoratif.

Siapa yang benar-benar dapat menegakkan kontrol tersebut?

Begitu ada sensor, pertanyaannya menjadi di mana setiap kontrol diizinkan berada. Cara yang berguna untuk menggambarkan hal ini adalah berdasarkan kepemilikan, bukan berdasarkan teknologi, karena kepemilikanlah yang menentukan apakah suatu kontrol bertahan pada rilis berikutnya.

Lapisan model adalah milik siapa pun yang melatihnya. Anda tidak mengonfigurasinya, Anda tidak dapat melihat isinya, dan perilakunya berubah saat vendor merilis versi baru — yang bisa terjadi pada hari Selasa mana pun. Yang dapat Anda lakukan adalah menyematkan versi dan memperlakukan perubahan versi sebagai perubahan pada postur risiko Anda yang memerlukan pengujian ulang. Yang tidak dapat Anda lakukan adalah mengklaim adanya kontrol di sini. "Model menolak permintaan berbahaya" adalah properti yang Anda andalkan, bukan mekanisme yang Anda operasikan.

Lapisan gateway adalah tempat setiap prompt dan completion melewati komponen yang Anda miliki. Di sinilah batas anggaran dan laju berada, tempat daftar izin dan izin alat ditegakkan, tempat pencatatan permintaan dan respons lengkap secara bawaan, dan tempat sebuah permintaan dapat ditulis ulang, diblokir, atau dialihkan rutenya sebelum ada token yang ditagih. Kontrol gateway juga satu-satunya yang tetap melekat saat Anda mengganti model, yang lebih penting daripada kedengarannya: tim yang menaruh kontrol mereka di dalam prompt kehilangannya sepenuhnya pada hari mereka bermigrasi.

Lapisan lingkungan adalah lapisan yang sepenuhnya milik Anda: kredensial dan cakupannya, egress jaringan, akses file, serta batas sandbox pada waktu jam dinding dan pengeluaran. Di sinilah juga eksekusi yang terkompromi menimbulkan kerusakan. Agen yang telah dibujuk untuk bertindak jahat berbahaya secara proporsional dengan apa yang diizinkan lingkungan untuk dicapai oleh tindakan tersebut — dan lingkungan adalah satu-satunya tempat di mana "hak istimewa minimum" merupakan perubahan konfigurasi, bukan masalah riset.

Uji praktis untuk setiap kontrol AI yang diusulkan adalah satu pertanyaan: lapisan mana dari ketiga lapisan ini yang menegakkannya? Jika jawabannya adalah lapisan model, kontrol itu hanyalah harapan. Jika jawabannya adalah "prompt sistem", itu adalah saran di dalam lapisan model, yang lebih buruk daripada harapan karena disertai dokumentasi yang mengklaim sebaliknya.

Deteksi: apa yang sebenarnya dikeluarkan oleh agen

Deteksi untuk agen berjalan pada kumpulan sinyal yang berbeda dari deteksi untuk manusia. Tidak ada anomali login untuk dikorelasikan. Yang ada sebagai gantinya adalah aliran permintaan dengan struktur yang luar biasa kaya, dan empat keluarga sinyal yang layak untuk memicu peringatan.

• Volume dan bentuk pemanggilan alat. Agen yang tiba-tiba memanggil alat pembaca file empat puluh kali dalam satu tugas, atau yang urutan alatnya berubah dari tiga langkah menjadi tiga puluh, patut diperiksa — bukan karena ia berniat jahat, tetapi karena distribusinya bergeser.

• Asal-usul konten di batas. Teks mana dalam prompt yang berasal dari pengguna, mana dari pengambilan, mana dari hasil alat, dan mana dari memori. Sebagian besar deteksi injeksi prompt pada dasarnya adalah "teks instruksional muncul di saluran yang seharusnya hanya membawa data", dan Anda tidak dapat menghitungnya kecuali gateway memberi label asal-usul saat masuk.

• Tepi egress dan cakupan. Permintaan ke tujuan di luar daftar izinkan, pembacaan jalur di luar cakupan, upaya menggunakan kredensial di luar layanan yang dimaksudkan. Ini adalah sinyal berpresisi tinggi dan murah, karena lingkungan sudah mengetahui apa yang diizinkan.

• Pengeluaran dan latensi sebagai proksi. Loop yang tak terkendali dan kompromi keamanan keduanya tampak seperti kurva biaya yang berubah kemiringan. Peringatan anggaran adalah deteksi yang paling tidak menarik di stack dan termasuk yang paling cepat membayar dirinya sendiri.

Yang sengaja tidak ada dalam daftar itu adalah classifier yang diminta menilai apakah suatu completion berbahaya. Itulah ide deteksi yang pertama kali dijangkau oleh tim dan yang paling cepat usang: ia bergeser seiring model, ia memiliki tingkat false-positive yang melatih analis Anda untuk mengabaikannya, dan ia tidak memberi Anda apa pun untuk dimasukkan ke dalam runbook.

Batasi: tiga tombol yang menghentikan rentetan buruk

Pembatasan untuk agen lebih sederhana daripada kelihatannya, karena tiga pengaturan mencakup hampir semuanya. Anggaran membatasi apa yang dapat dibelanjakan oleh suatu eksekusi, yang membatasi kerusakan finansial sekaligus radius dampak dari sebuah loop. Cakupan membatasi apa yang dapat disentuh oleh suatu eksekusi — alat yang diaktifkan untuk tugas itu, jalur, tenant. Sandbox membatasi berapa lama ia dapat berjalan dan apa yang dapat dijangkau saat berjalan. Ketiganya adalah pengaturan gateway atau lingkungan, yang dengan kata lain dapat ditegakkan.

Prinsip desain yang penting adalah cakupan per tugas, bukan cakupan per agen. Agen dengan kumpulan izin permanen adalah agen yang izinnya akan terus menumpuk sampai seseorang mengauditnya; agen yang menerima kredensial bercakupan tugas selama durasi suatu tugas memiliki batas yang kedaluwarsa dengan sendirinya. Yang kedua lebih banyak kerja untuk dibangun dan jauh lebih murah untuk dipertahankan.

Di sinilah sebuah gateway membuktikan namanya. Kontrol yang berada di depan setiap pemanggilan model — pemanggilan tool dan MCP dinilai sebelum dijalankan, kebijakan konten dan penyamaran data pribadi diterapkan sebelum permintaan ditagih — adalah kontrol yang sama, baik model di belakangnya adalah model yang Anda gunakan kuartal lalu maupun yang dirilis minggu lalu. Kontinuitas itulah produk sebenarnya: bukan filter yang lebih baik, melainkan tempat bagi filter untuk hidup yang tidak ikut berpindah saat modelnya berganti.

Pulihkan: putar ulang, tambal, uji ulang

Pemulihan insiden AI memiliki satu keunggulan dibandingkan pemulihan insiden jaringan: seluruh proses eksekusi biasanya terekam. Prompt, konteks, pemanggilan alat, penyelesaian, waktu — jika gateway mencatatnya, insiden tersebut dapat diputar ulang, yang merupakan titik awal yang lebih kuat daripada yang biasanya diperoleh sebagian besar forensik.

Replay memiliki tiga tujuan secara berurutan. Ini menetapkan apa yang sebenarnya terjadi, bukan apa yang menurut transkrip terjadi setelah beberapa orang merangkumnya. Ini mengidentifikasi kontrol yang seharusnya terpicu, yang merupakan perbedaan antara memperbaiki gejala dan memperbaiki batas. Dan ini menghasilkan kasus regresi: input yang direkam yang sekarang harus diblokir, dijalankan terhadap konfigurasi baru untuk membuktikan bahwa input itu memang diblokir.

Tahap patch adalah tempat tim biru paling sering salah sasaran. Jika temuan adalah perilaku model, semua mitigasi yang tersedia berada di luar model — pengurangan cakupan, filter di gateway, izin yang dihapus dari lingkungan. Jika temuan adalah perilaku sistem, perbaikannya ada di konfigurasi dan uji regresinya murah. Apa pun itu, uji ulang bukan opsional, karena perbaikan dan versi model sama-sama bergerak, dan kontrol yang telah diverifikasi terhadap build bulan lalu adalah klaim tentang bulan lalu.

Merepetisi hari ketika itu menyala

Runbook yang belum pernah dibaca dalam kondisi tertekan hanyalah sebuah dokumen, bukan sebuah kapabilitas. Latihan yang benar-benar berharga bersifat sempit dan spesifik: ambil satu insiden agen yang masuk akal, telusuri dari awal hingga akhir, dan catat waktu setiap langkahnya. Siapa yang menyadarinya? Berapa lama sampai ada manusia yang melihat baris log yang tepat? Siapa yang dapat menghentikan prosesnya — satu orang yang namanya jelas, atau sebuah komite? Siapa yang dapat mencabut kredensial, dan berapa lama pencabutan itu menyebar? Siapa yang memutuskan apakah perlu memberi tahu pihak di luar perusahaan?

Dua dari pertanyaan tersebut secara konsisten menjebak tim. “Siapa yang dapat menghentikan prosesnya” gagal ketika penghentian memerlukan seseorang yang sedang tidur, sehingga jawabannya harus berupa mekanisme, bukan orang — batas anggaran atau kill switch yang dapat ditarik sendiri oleh engineer yang bertugas. “Berapa lama proses pencabutan?” gagal karena kredensial sering kali di-cache di komponen yang tidak ada dalam diagram.

Membaca arsip adalah bentuk latihan termurah yang tersedia, karena memungkinkan Anda mewarisi struktur insiden milik orang lain alih-alih menciptakan sendiri. Ambil beberapa entri yang mirip dengan deployment Anda, dan untuk masing-masing tanyakan tiga pertanyaan di atas. Entri yang tidak dapat Anda jawab adalah celah dalam runbook Anda, dan Anda menemukannya sebelum insiden, bukan sesudahnya.

Asimetri yang layak dinyatakan secara gamblang

Red teaming dan blue teaming bukan aktivitas yang simetris dan tidak semestinya dianggarkan seolah-olah keduanya simetris. Satu pelaksanaan red team dibatasi oleh jadwal dan menghasilkan sekumpulan temuan yang kehilangan relevansi seiring perubahan target. Kontrol blue team bertahan, bersifat kumulatif, dan merupakan satu-satunya hal yang benar-benar berdiri di antara input buruk dan hasil buruk. Satu keterlibatan dapat menemukan sebuah batas; hanya yang lain yang dapat mempertahankannya.

Itu membuat standar jujur bagi sebuah blue team menjadi tidak glamor dan dapat diperiksa. Untuk setiap kontrol yang Anda klaim, Anda harus bisa menyebutkan lapisan yang menegakkannya, baris log yang membuktikan kontrol itu terpicu, peringatan yang memberi tahu Anda saat kontrol itu tidak terpicu, dan orang yang dapat mematikan prosesnya. Empat kalimat. Jika salah satunya hilang, kontrol itu hanyalah dokumen kebijakan, dan dokumen kebijakan tidak membaca body permintaan.