AI Red Teaming Dijelaskan: Apa yang Diuji oleh Tim Merah, dan Apa yang Ditinggalkannya

Sebagian besar penugasan red teaming AI dinilai berdasarkan artefak yang salah. Satu minggu kerja menghasilkan dek slide, dek itu menyatakan asisten dapat dibujuk untuk menulis email phishing, dan setelah itu tidak ada yang bisa mengatakan apakah perilaku tersebut dapat direproduksi, seberapa buruk itu, atau kontrol mana yang akan menghentikannya. Disiplin ini memiliki keluaran nyata, dan itu bukan dek: melainkan sekumpulan temuan yang bertahan saat dijalankan ulang, masing-masing terkait dengan batas yang telah dilanggar dan bukti yang melanggarnya. Itu juga bentuk catatan arsip insiden AI yang menyimpan — 400 entri yang mencakup Desember 2024 hingga Oktober 2026, diambil dari 743 sumber berbeda, dan putusan untuk masing-masing entri tentang apakah ada orang yang benar-benar dirugikan.

Kebingungan itu dapat dimaklumi, karena "red teaming" digunakan untuk dua pekerjaan yang hanya berbagi kosakata dan hampir tidak memiliki kesamaan lain. Ini adalah panduan untuk keduanya, untuk bukti yang semestinya dihasilkan masing-masing, dan untuk empat titik di mana red teaming AI benar-benar berbeda dari versi jaringan yang sebagian besar tim keamanan sudah tahu cara menjalankannya.

Pertanyaan kerangka kerja: siapa yang memiliki pengujian

Sebelum membahas cakupan, ada pertanyaan tentang siapa yang menjalankan latihan dan terhadap apa. Microsoft menerbitkan salah satu posisi publik yang lebih lengkap tentang ini, dan layak dibaca sebagai peta, bukan sebagai halaman produk. Hub AI Red Team-nya memisahkan konsep AI red teaming dari cara melakukannya, lalu menyusun praktiknya dalam urutan yang sendirinya merupakan sebuah argumen: ikhtisar, lalu panduan untuk membangun tim red LLM, lalu materi referensi — bug bar untuk triase serangan terhadap sistem pembelajaran mesin, taksonomi kegagalan pembelajaran mesin, model tanggung jawab bersama, dan panduan pemodelan ancaman bagi pengembang.

Baca urutannya dan metodologinya akan tampak dengan sendirinya. Sebuah taksonomi menentukan apa yang dianggap sebagai kegagalan. Sebuah bug bar menentukan kegagalan mana yang layak diperbaiki. Sebuah model tanggung jawab bersama menentukan siapa yang bertanggung jawab atasnya setelah ditemukan. Pemodelan ancaman menentukan ke mana harus mencari berikutnya. Tanpa keempat hal itu, tim red team hanya menghasilkan anekdot dengan kolom keparahan yang ditempelkan, dan kolom keparahan itu adalah apa pun yang penguji rasakan sore itu.

Kerangka otomasi terbuka Microsoft, PyRIT, ditempatkan di rak yang sama, dan penempatan itulah bagian yang berguna. Kit orkestrasi bukanlah metodologi; ia adalah alat yang Anda arahkan ke target setelah taksonomi dan ambang bug ada. Tim yang memulai dengan kerangka kerja cenderung berakhir dengan korpus prompt besar dan tanpa cara untuk memeringkat hasil.

Dua tim merah, dua pertanyaan berbeda

Pembedaan paling berguna di bidang ini adalah pembedaan yang hampir tidak pernah dituliskan oleh siapa pun: red team yang menguji sebuah model dan red team yang menguji sebuah system menjawab pertanyaan yang berbeda, dengan unit yang diuji berbeda, keluaran berbeda, dan pemilik berbeda. Mencampuradukkan keduanya adalah cara sebuah jailbreak dilaporkan sebagai temuan keamanan, dan cara bug eskalasi hak istimewa yang nyata diajukan sebagai keluhan kualitas model.

Evaluasi keamanan tingkat model adalah masalah pengukuran. Anda bertanya apakah sebuah model akan menghasilkan suatu kategori konten, dan cara jujur untuk menjawabnya adalah sampel yang cukup besar untuk dapat mengatakan sesuatu tentang laju. Unit yang diuji adalah model di balik API tipis, metodenya adalah prompt adversarial — jailbreak, serangan persona, tekanan multi-putaran — dan yang dihasilkan adalah transkrip ditambah penilaian bahaya. Ketika bobot berubah atau lapisan keamanan vendor bergeser, seluruh hasilnya menjadi usang. Itulah sebabnya jenis pengujian ini biasanya dijalankan oleh pembangun model atau oleh evaluator independen, dan mengapa temuannya jarang dipetakan ke perbaikan spesifik di aplikasi Anda.

Emulasi adversary tingkat sistem adalah masalah rekayasa. Anda mempertanyakan apakah seorang penyerang dapat membuat sistem yang telah di-deploy bertindak — membaca file yang seharusnya tidak boleh dibaca, memanggil alat yang seharusnya tidak boleh dipanggil, membelanjakan uang yang seharusnya tidak boleh dibelanjakan. Unit yang diuji adalah agen beserta alat, retrieval, dan kredensial yang terpasang padanya. Metodenya adalah metode yang sudah familier, diarahkan ulang: injeksi melalui konten hasil retrieval alih-alih melalui giliran pengguna, penyalahgunaan alat, rantai hak istimewa yang dirakit dari izin-izin yang secara individual wajar, jalur data yang bocor melintasi batas tenant. Outputnya adalah temuan dengan reproduksi, batas yang terlampaui, dan pemilik yang dapat mengubah konfigurasi besok.

Keduanya menghasilkan artefak yang tidak kompatibel, dan ketidakkompatibelan itu bersifat diagnostik, bukan menjengkelkan. {{1}}Hasil tingkat model tidak dapat "diperbaiki" oleh tim Anda kecuali dengan mengganti model.{{/1}} {{2}}Hasil tingkat sistem sama sekali tidak dapat diperbaiki oleh vendor.{{/2}} Jika sebuah laporan tidak menyebutkan yang mana dari keduanya, Anda tidak dapat menetapkan item mana pun darinya.

Seperti apa permukaan serangan setelah model memiliki alat

Permukaan yang masih diuji oleh sebagian besar tim adalah prompt. Permukaan itu juga yang paling tidak menarik, karena itulah yang paling banyak dihabiskan upaya vendor model untuk memperkuatnya dan yang paling sedikit memberi daya ungkit bagi penyerang. Permukaan yang benar-benar memberi hasil adalah permukaan yang ditambahkan oleh aplikasi: alat yang dapat dipanggil agen, indeks retrieval yang dibacanya, memori yang dibawanya antargiliran, dan saluran keluaran itu sendiri.

Alat adalah tempat model bahasa menjadi aktor, dan pertanyaan yang menarik tidak pernah "bisakah ia memanggil alat itu" melainkan "apa hak istimewa paling rendah yang bisa dimiliki alat ini". Alat pencarian tiket yang menerima kueri teks bebas biasanya bisa dibujuk untuk menerima pengenal pelanggan lain. Pengambilan adalah saluran konten ke dalam konteks model, yang berarti siapa pun yang dapat menulis ke korpus — drive bersama, makro dukungan, halaman web yang dijangkau pengambil — sedang menulis ke prompt. Memori mengubah satu giliran menjadi persistensi: instruksi yang ditanam pada giliran kedua masih ada pada giliran keempat puluh. Keluaran adalah tempat teks model mendarat di suatu tempat yang menafsirkannya, dan rendering, markdown, pratinjau tautan, serta pipeline yang berdekatan dengan shell semuanya menafsirkan teks.

Sebuah engagement yang hanya menguji prompt akan melaporkan hasil yang bersih dan justru benar tentang hal yang salah.

Mengapa transkrip bukan temuan

Sebuah temuan memerlukan tiga properti yang tidak dimiliki oleh tangkapan layar jendela obrolan. Yang pertama adalah reproduksibilitas: jalankan lagi dari keadaan bersih dan hal itu terjadi lagi. Model bersifat non-deterministik, jadi reproduksibilitas adalah laju, bukan boolean — "sembilan dari sepuluh percobaan" adalah temuan, "hal itu terjadi sekali" adalah rumor. Yang kedua adalah batas yang terlewati: sebutkan hal yang seharusnya tidak terjadi dalam istilah aplikasi itu sendiri, bukan istilah model. Bukan "model itu kasar", melainkan "agen membaca dokumen milik tenant B". Yang ketiga adalah tingkat keparahan yang tertelusur ke dampak alih-alih ke intuisi penguji, yang memang menjadi fungsi bug bar.

Semua hal lainnya — transkrip, prompt, penalaran model — adalah bukti yang mendukung ketiga hal tersebut. Itu bukan temuan itu sendiri, dan inilah sebabnya korpus berisi dua ribu prompt jailbreak nilainya lebih rendah daripada lima temuan sistem yang dapat direproduksi dengan kontrol bernama yang disertakan.

Empat hal di mana red teaming AI berbeda dari red teaming jaringan

Tim yang datang dari keamanan jaringan atau aplikasi membawa insting yang baik dan empat asumsi yang keliru.

• Tidak ada perimeter untuk dipertahankan. Keterlibatan jaringan memiliki daftar target; keterlibatan agen memiliki jendela konteks yang dirakit pada waktu permintaan dari sumber yang mungkin belum Anda inventarisasi. Cakupan harus dinyatakan sebagai sumber data dan izin alat, bukan nama host.

• Target bersifat non-deterministik. Input yang sama dapat berhasil pada hari Selasa dan gagal pada hari Rabu. Hal ini merusak standar bukti "satu reproduksi bersih" dan memaksa Anda untuk melaporkan tingkat keberhasilan.

• Eksploitasinya adalah bahasa, dan bahasa tidak punya tambalan. Anda dapat memperbaiki pemeriksaan otorisasi yang hilang. Anda tidak dapat menambal "model dapat dibujuk". Mitigasi untuk kelemahan tingkat bahasa adalah kontrol di tempat lain — filter, batas cakupan, batas izin — itulah sebabnya temuan perlu menyebutkan kontrolnya, bukan hanya perilakunya.

• Vendor ada di dalam proses ini. Target Anda berubah ketika orang lain merilis sebuah versi. Hasil pada tingkat model hanya valid untuk build yang Anda uji, dan jika Anda tidak mencatat versi serta tanggalnya, Anda tidak memiliki hasil.

Cara menetapkan cakupan keterlibatan pertama

Penugasan yang berjalan buruk hampir selalu cakupannya ditetapkan sebagai "menguji AI". Cakupan yang bertahan saat berhadapan dengan jadwal lebih mirip seperti ini: satu agen, di lingkungan staging, dengan data yang menyerupai produksi dan izin yang menyerupai produksi; daftar lima batas yang penting (isolasi tenant, akses kredensial, pengeluaran, egress data, cakupan alat); aturan keterlibatan yang menyebutkan apa yang di luar batas; kondisi berhenti yang menyatakan siapa yang dapat menghentikan proses; dan format bukti yang telah ditetapkan dan disepakati sebelum percobaan pertama, sehingga laporan disusun dari artefak, bukan direkonstruksi dari ingatan.

Otorisasi layak mendapat kalimatnya sendiri, karena itulah satu hal yang dilewatkan tim ketika targetnya adalah produk mereka sendiri dan alatnya milik orang lain. Menguji model yang tidak Anda operasikan, di infrastruktur yang tidak Anda miliki, dengan prompt yang dirancang untuk menembus lapisan keamanan, adalah aktivitas yang berbeda dari menguji deployment Anda sendiri — dan cakupan tertulis adalah yang membedakan keduanya. Gerbang verifikasi yang dijalankan oleh tier siber kami sendiri ada untuk alasan yang sama: pekerjaan keamanan yang diotorisasi di tingkat model memerlukan pihak yang disebutkan namanya dan bertanggung jawab di kedua sisi.

Apa yang ditambahkan oleh catatan insiden

Sebuah uji tim merah memberi tahu Anda apa yang dilakukan target Anda. Uji itu tidak dapat memberi tahu Anda apa yang terjadi di lapangan, dan di lapanganlah argumen untuk sebuah kontrol benar-benar dibangun. Itulah celah yang diisi oleh buku besar insiden — dan disiplin yang ditimbulkannya adalah bagian yang berguna: catatan tanpa setidaknya satu sumber tidak ada, dan catatan tanpa putusan mengenai adanya bahaya bukanlah insiden.

Baca kedua artefak itu bersama-sama, dan siklusnya menutup. Tim red team menghasilkan temuan yang dapat direproduksi dan menyebutkan kontrol yang seharusnya dapat memblokirnya. Catatan itu memberi tahu Anda apakah ada orang di lapangan yang sudah menabrak batas tersebut, apa dampak buruknya, dan apakah kontrolnya bertahan di tempat lain. Temuan tanpa preseden lapangan adalah hipotesis yang layak diperbaiki; insiden lapangan tanpa temuan yang dapat direproduksi adalah bug yang belum dapat Anda tutup. Tim yang melakukannya dengan benar berhenti memperlakukan "kami melakukan red team pada model" sebagai hasil yang harus diserahkan dan mulai memperlakukannya sebagai salah satu masukan untuk buku besar mereka sendiri.

Yang tersisa adalah catatan penutup yang jujur. AI red teaming tidak menghasilkan jaminan keamanan, dan setiap keterlibatan yang dijual sebagai jaminan semacam itu menjual hal yang salah. Yang dihasilkan adalah seperangkat batas yang kini Anda ketahui telah ditembus, disertai bukti yang dapat Anda jalankan ulang, diurutkan berdasarkan apa yang terjadi ketika batas itu ditembus. Itu sudah cukup untuk mengambil keputusan — dan jauh lebih berharga daripada sekadar dek presentasi.