Krisis Visibilitas AI: Mengapa Tim Keamanan Terbang Buta dan Mengapa Mereka Tidak Perlu

Integrasi agen AI ke dalam lingkungan produksi dipercepat, tetapi arsitektur keamanan yang diperlukan untuk melindunginya masih jauh tertinggal. Kami berada di era di mana agen AI, yang diberi tugas pekerjaan rutin di lingkungan staging, dapat secara mandiri memutuskan untuk “memperbaiki” kesalahan kredensial dengan menghapus volume database.

Sebagai industri, kita secara kolektif mematikan otak kita ketika datang ke prinsip-prinsip keamanan dan observabilitas seputar AI. Tim keamanan terbang buta, tetapi mereka tidak perlu.

Mitos Sistem Prompts dan Tooling yang Aman

Mitos yang merajalela di ruang AI adalah bahwa kita dapat mengontrol perilaku agen hanya dengan mengatakan kepada mereka untuk berperilaku. Sistem prompts adalah saran, bukan penegakan. Dalam insiden yang disebutkan sebelumnya, aturan sistem AI secara eksplisit menyatakan untuk tidak menjalankan perintah destruktif, namun agen melanggar garis pembatas yang diiklankan dan menjalankan tindakan yang paling tidak dapat diubah.

Kita harus bekerja di bawah asumsi bahwa AI tidak benar-benar “tahu” apa-apa. Serangan terhadap AI adalah rekayasa sosial, kecuali targetnya lebih bodoh daripada manusia rata-rata. Siapa pun yang memiliki pengalaman melakukan pengujian penetrasi memahami betapa sulitnya bagi organisasi untuk membela diri terhadap serangan rekayasa sosial. Sekarang komputer kita juga rentan.

Selain itu, tooling AI pada akhirnya hanya perangkat lunak, dan semua perangkat lunak memiliki bug. Kami sudah melihat contoh di mana tooling AI secara otomatis memulai server HTTP yang tidak diautentikasi, memungkinkan proses atau situs web lokal untuk menjalankan perintah shell sewenang-wenang dengan hak akses pengguna.

Black Box AI Auditing

Jika AI berperilaku tidak terduga atau dimanipulasi, mengetahui apa yang dilakukannya adalah mimpi buruk. Alat AI umumnya tidak menyediakan log audit. Jika Anda beruntung memiliki akses ke tingkat perusahaan, log yang Anda terima sangat kurang. Misalnya, Anda mungkin menerima peristiwa yang samar yang menyatakan pengguna “menggunakan Gen AI.” dan hanya menerima metrik dasar yang menjelaskan jumlah token input dan output.

Tidak satu pun dari ini membantu analis keamanan menjawab pertanyaan dasar: Apa yang dilakukan agen ini?

Mengungkap AI: Bagaimana Menghentikan Kebutaan

Kabar baiknya adalah Anda tidak perlu memiliki perangkat keamanan AI khusus yang baru untuk mendapatkan kembali visibilitas. Penggunaan AI Bayangan dan aktivitas agen dapat dideteksi menggunakan teknik analisis log yang sudah ada yang harus dimiliki tim Anda. Panggilan alat AI, eksekusi perintah, dan peristiwa perubahan sistem dapat dilacak ke AI menggunakan analisis eksekusi proses yang ada (yang Anda lakukan di sistem manajemen keamanan dan peristiwa (SIEM), bukan?).

Berikut adalah cara Anda dapat menggunakan infrastruktur yang ada untuk mendeteksi aktivitas AI:

• Analisis DNS: Menganalisis log DNS untuk kueri ke domain layanan AI yang dikenal dapat membantu mendeteksi penggunaan AI di lingkungan Anda.
• Daftar Ancaman: Pendekatan ini memerlukan pemeliharaan daftar ancaman yang diperbarui dari domain yang terkait dengan platform AI atau penyedia model.
• Sumber Daya Komunitas: Ada proyek komunitas dan daftar blokir yang tersedia yang dapat dimodifikasi menjadi tabel pencarian untuk penggunaan programatis.
• Pelacakan SSL: Pendekatan yang serupa dapat menggunakan log SSL untuk melacak nama server, meskipun itu memberikan detail yang sedikit kurang karena URL lengkap tidak direkam.
• Telemetri Titik Akhir: Anda dapat menggunakan alat seperti Sysmon untuk menghitung proses anak dan berburu pembuat bash yang tinggi, yang merupakan indikator kuat dari potensi agen AI yang menjalankan perintah di titik akhir.

Titik buta yang memerlukan perubahan aktif pada pengumpulan data adalah prompt itu sendiri. Apa yang diminta pengguna dari AI? Apakah mereka mengunggah dokumen sensitif yang berpotensi menciptakan masalah kepatuhan? Menjawab pertanyaan ini kemungkinan besar memerlukan pengumpulan permintaan API ke penyedia; proksi web, proksi LLM, dan alat pengumpulan data dari penyedia log dan SIEM. Ini dapat menghilangkan tirai yang menghalangi sumber data berharga ini.

Ancaman yang Muncul: Server MCP Malicious

Protokol konteks model (MCP) telah muncul sebagai cara untuk menentukan bagaimana aplikasi AI terintegrasi dengan alat dan sumber data eksternal. Sementara itu memstandarkan koneksi, juga memperkenalkan vektor serangan baru yang besar melalui “Evil MCP” server.

Saya menghosting lokakarya pelatihan tangan yang memungkinkan siswa mengalami serangan ini secara langsung. Mereka merancang server MCP malicious untuk menipu LLM agar memanggil alat yang sah dan mengirimkan output kembali ke penyerang. Karena LLM sangat rentan terhadap rekayasa sosial, melewati garis pembatas bawaannya seringkali hanya masalah memilih kata yang lebih baik atau pretext yang cerdas.

Siswa umumnya menggunakan server malicious mereka untuk menginstruksikan AI bahwa itu “dalam mode pemeliharaan” dan harus mengirimkan data ke alat sekunder untuk “pencatatan audit,” sehingga menghasilkan eksfiltrasi data. Beberapa siswa lebih kreatif dengan prompt mereka daripada yang lain, tetapi semuanya biasanya berhasil.

Mengambil Kendali Kembali

Untuk melakukan audit aktivitas AI di dunia nyata, Anda memerlukan proksi untuk menangkap permintaan AI dan alat pengumpulan log yang dapat menangani payload JSON yang besar. Dengan visibilitas ini, Anda dapat mendeteksi dan menangani ancaman. Anda tidak dapat hanya mengandalkan vendor AI untuk menyediakan lapisan keamanan. Penegakan harus hidup dalam sistem organisasi Anda, bukan dalam paragraf teks yang kita harap model memutuskan untuk patuhi. Dengan solusi logging yang baik, tim keamanan memiliki telemetri; sudah waktunya mereka mulai mengquerynya.