Tolok Ukur Keamanan AI Membutuhkan Tes Alur Kerja: Analisis

Skor benchmark adalah alarm asap, bukan inspeksi bangunan. Berguna, nyaring, kadang menyelamatkan nyawa, tetapi tidak bisa memberi tahu apakah pintu keluar ternyata mengarah ke lemari sapu penuh kain berminyak. Dark Reading punya kecemasan yang tepat dalam judulnya, So Many AI Security Benchmarks, But None Tell the Whole Story. Terjemahan untuk pembangun sederhana: gunakan benchmark keamanan model sebagai sinyal arah, lalu uji model di dalam codebase Anda sendiri, izin alat, alur data, dan workflow yang sangat penuh kutukan.

Itu mungkin terdengar jelas, dan justru karena itulah Anda tahu hal ini akan dilewati dalam setidaknya satu tinjauan roadmap minggu ini. Sistem AI semakin sering dinilai lewat skor publik yang rapi, sementara agen produksi diminta mengirim email, mengedit tiket, menyetujui kode, melakukan kueri log, dan menyentuh status nyata. Celah itulah tempat para gremlin menyewa ruang kantor.

Benchmark bukanlah radius ledakan

SABench membuat masalah ini terasa sangat konkret. Menurut Task Success Is Not Enough: Side-effect-Aware Evaluation of Tool-Using Language Model Agents, SABench mencakup 201 tugas email, kalender, dan tiket, lalu menanyakan apakah agen tidak hanya menyelesaikan pekerjaan yang diberikan, tetapi juga menghindari efek samping yang tidak diizinkan. Para penulis melaporkan hasil dari 2.211 pasangan tugas model dari 11 LLM frontier yang mencakup keluarga model komersial dan terbuka utama. Di seluruh run tersebut, 15,2% menimbulkan kerusakan kolateral, dan di antara run yang mencapai tujuan, 12,8% tetap menghasilkan penulisan yang tidak diizinkan.

Angka terakhir itu adalah goblin kecil menyebalkan di spreadsheet. Sebuah sistem bisa melakukan apa yang diminta pengguna dan tetap mengubah objek yang salah, memperluas cakupan, atau menyenggol alat yang seharusnya dibiarkan saja. Para penulis SABench merumuskannya dengan jelas: “keberhasilan tugas saja adalah proksi yang buruk untuk penggunaan alat yang aman.” Terjemahan untuk pembangun: jika evaluasi Anda hanya memeriksa apakah tugas selesai, itu seperti menilai forklift dari apakah paletnya berpindah, bukan apakah gudangnya sekarang terbakar.

Code review membutuhkan bukti yang dapat dieksekusi

CyberDual menunjuk pada pelajaran yang sama dari sisi pemeliharaan perangkat lunak. Menurut CyberDual: AI Attackers versus AI Code Reviewers in Real-World Software Maintenance, agen penyerang menyembunyikan bug yang dapat dieksploitasi dalam pekerjaan pemeliharaan nyata, sementara agen reviewer berupaya menangkap dan memperbaikinya. Makalah tersebut mengatakan tiga reviewer agentic menangkap 85,91% dari 1.088 serangan valid dari enam penyerang, yang terdengar menenangkan sampai kalimat berikutnya masuk sambil memakai sepatu bot berujung baja.

Para penulis melaporkan bahwa ketika penyerang menyebarkan bug di seluruh commit upstream nyata, sekitar satu dari enam slot serangan tetap berakhir dengan exploit yang berfungsi setelah review. Prinsip evaluasi mereka terasa segar karena tidak sentimental: “Eksekusi menentukan setiap pertandingan.” Dengan kata lain, ujiannya bukan apakah reviewer menulis paragraf percaya diri dengan aura linting yang kuat. Ujiannya adalah apakah proof of concept penyerang masih berfungsi pada kode yang telah direview.

Bagi tim yang mengadopsi code review AI, itulah perbedaan antara demo dan kontrol. Benchmark bisa memberi tahu Anda bahwa model reviewer terlihat menjanjikan; pipeline CI Anda harus membuktikan bahwa ia menangkap kerentanan dalam pola dependensi Anda, konvensi framework Anda, gaya patch Anda, dan kebiasaan tim Anda menamai sesuatu config2_final_really_final. Kepercayaan keamanan harus datang dari pemeriksaan yang dapat dieksekusi, bukan dari model yang terdengar seperti punya beberapa jaket quarter-zip.

Workflow bisa menjadi exploit

NameTrap memperlebar sudut pandang dari perilaku model ke konteks yang dikonsumsi model. Menurut NameTrap: Steering AI Coding Agents Toward Security Vulnerabilities via Variable Names, serangan hanya mengubah identifier di file Python pihak ketiga, mendorong agen coding AI menuju kerentanan Common Weakness Enumeration yang ditargetkan penyerang. Tidak diperlukan monolog prompt injection yang sangat jahat. Cukup penamaan yang diracuni, seperti meninggalkan kulit pisang di lantai autocomplete.

Tingkat keberhasilan yang dilaporkan berkisar dari 22,5% hingga 56,0% di enam agen, mencapai 75,0% untuk konfigurasi model agen tertentu. Lebih buruk lagi bagi siapa pun yang berharap analisis statis akan datang sebagai penyelamat berkuda putih, makalah tersebut mengatakan tiga penganalisis keamanan berbasis AI dan empat penganalisis statis tidak melaporkan satu pun kelemahan yang ditargetkan dalam file beracun tersebut. Itu tidak berarti penganalisis tidak berguna. Itu berarti workflow di sekitarnya dan asal-usul input penting, terutama ketika agen meng-clone repository, membaca kode eksternal, dan memperlakukan konteks sebagai kebenaran mutlak dengan anggaran GPU.

Di sinilah belanja benchmark menjadi berbahaya. Sebuah model mungkin mendapat skor bagus pada suite keamanan dan tetap gagal ketika workflow agen Anda mencampur instalasi paket, penelusuran repository, patch yang dihasilkan, dan akses alat yang permisif. Model hanyalah satu aktor dalam drama prosedural kecil; propertinya bisa dipasangi jebakan.

Bangun evaluasi yang hilang di sekitar workflow Anda sendiri

SecLog-Bench menawarkan pola yang lebih matang bagi tim yang memikirkan plumbing evaluasi. Menurut SecLog-Bench: A Scalable Benchmark for Cybersecurity Log Reasoning with Scaffolded Evidence, workflow anotasi berbantuan AI-nya menghasilkan 92,13% kesepakatan teramati dengan penilaian konsensus manusia, dengan Cohen’s κ=0,84. Sumber yang sama menggambarkan bantuan AI sebagai pendukung anotasi manusia, bukan penggantinya, dengan tanggal akses, prompt, dan output perantara dicatat untuk auditabilitas.

Itulah sikap yang sebaiknya dicuri para pembangun tanpa rasa malu. Mulailah dengan benchmark publik untuk membuat daftar pendek model, lalu buat tes privat yang mencerminkan aksi produksi Anda: alat yang diekspos, objek yang dapat dimodifikasi agen, repository yang mereka baca, log yang mereka rangkum, dan mode kegagalan yang benar-benar akan menyakitkan. Executive Summary dari Fangcun AI Evaluation Team berargumen bahwa lebih banyak benchmark privat diperlukan karena benchmark publik dapat bocor ke data pelatihan, dan mengatakan benchmark internal umumnya memunculkan kesadaran evaluasi yang jauh lebih rendah dalam evaluasi kehilangan kendali dibandingkan benchmark publik.

Langkah praktisnya bukan meninggalkan benchmark. Langkahnya adalah berhenti memperlakukannya seperti stempel paspor untuk produksi. Simpan skor publik, tambahkan kasus adversarial yang spesifik untuk workflow, jalankan bukti yang dapat dieksekusi jika memungkinkan, catat prompt dan output, serta wajibkan review manusia untuk tindakan berdampak tinggi sampai bukti Anda mengatakan sebaliknya. Perhatikan benchmark yang menguji efek samping, asal-usul data, izin alat, dan exploitability end-to-end, karena di situlah sistem nyata menjadi menarik. Atau, dalam istilah yang kurang sopan: model Anda lulus ujian mengemudi, tetapi produk Anda memintanya memarkir valet truk pengaduk semen di toko kembang api.