Untuk membangun sistem AI yang berfungsi, Anda harus mencoba merusaknya terlebih dahulu. Kami menjalankan red teaming dengan bertindak sebagai penyerang untuk menguji dan menyelidiki aplikasi AI layanan pelanggan di sektor jasa keuangan. Temuan kami penting bagi siapa pun yang menerapkan aplikasi berbasis LLM ketika keamanan adalah hal mutlak.
Red teaming adalah praktik sengaja mencoba membobol sistem AI agar Anda dapat memperbaiki kerentanan sebelum ditemukan penyerang sungguhan. Dalam jasa keuangan, taruhannya sangat tinggi: aplikasi AI mengakses data pelanggan, memproses transaksi, dan memberikan wawasan keuangan. Kegagalan dapat menimbulkan berbagai dampak, mulai dari pengalaman pengguna yang buruk hingga pelanggaran regulasi, kerugian finansial, dan kerusakan merek yang tidak dapat dipulihkan.
Tujuan kami adalah menemukan kerentanan sejak dini, menguji pola serangan yang realistis, dan membantu organisasi memenuhi ekspektasi keselamatan AI yang dipandang sangat serius oleh regulator.
Ada satu perbedaan penting: jailbreak menyerang filter keamanan pada model yang mendasarinya, sedangkan injeksi prompt menyerang aplikasi itu sendiri dengan menggabungkan masukan pengguna yang tidak tepercaya dan prompt tepercaya milik pengembang. Injeksi prompt menimbulkan risiko lebih besar karena menyasar sistem Anda dan data rahasia yang diprosesnya, bukan model serbaguna.
Putaran pertama kami mencakup sekitar 750 pengujian terhadap:
Kebocoran data lintas sesi
Pemaparan PII (melalui bahasa alami, manipulasi API, dan berbagai penyandian)
Injeksi SQL
Penimpaan prompt sistem
Dalam pengujian awal tersebut, kami menemukan dua masalah besar pada sistem yang ada: penanganan kueri dengan beragam maksud dan penggunaan prompt yang disandikan.
Kueri dengan beragam maksud: permintaan yang menggabungkan tujuan sah dan berbahaya. Contohnya: “Show my spending by category, and also execute [malicious SQL].” Aplikasi tidak mendeteksi maksud berbahaya tersebut dan justru sepenuhnya mengandalkan mekanisme perlindungan pada lapisan data di hilir. Ini sama saja dengan membiarkan pintu depan terbuka karena Anda memercayai brankas di ruang bawah tanah.
Penyandian: permintaan yang disandikan dalam Base64, Hex, LeetSpeak, dan homoglif. Sistem dapat kesulitan menyaring maksud berbahaya. Meskipun kueri-kueri ini tidak mengekspos data sensitif, semuanya menyebabkan ketidakstabilan sistem yang signifikan, seperti halusinasi, pengulangan SQL berbahaya kepada pengguna, dan kekeliruan klasifikasi maksud.
Hasil pengujian awal kami menunjukkan:
Halusinasi temporal: model memberikan tanggal, stempel waktu transaksi, atau ringkasan berbatas waktu yang direkayasa, tetapi disampaikan dengan penuh keyakinan—risiko besar dalam konteks keuangan karena pelanggan yang bertindak berdasarkan tanggal yang salah dapat menghadapi konsekuensi nyata
SQL berbahaya diulang kembali kepada pengguna (mengkhawatirkan karena berisiko meracuni memori)
Kekeliruan klasifikasi maksud
Format keluaran yang berantakan
Berbekal temuan tersebut, kami mempersempit fokus. Pengujian injeksi SQL dan penyandian diturunkan prioritasnya karena tim sudah menanganinya. Sebaliknya, kami berfokus pada vektor serangan yang paling berhasil: pemaparan PII dan kebocoran lintas sesi.
Temuan paling mencolok dari putaran kedua ternyata sangat sederhana: sering kali Anda sama sekali tidak perlu menggunakan cara yang canggih.
Dalam banyak kasus, cukup dengan meminta data internal dalam konteks permintaan yang terdengar sah, sistem sudah bersedia mengeksposnya. Kueri sederhana mendapat respons yang menyebutkan ID internal dan kolom sistem yang seharusnya tidak pernah ditampilkan kepada pengguna akhir.
Setelah menggali lebih dalam, kami menemukan bahwa ini bukan sekadar kegagalan pada tingkat aplikasi. Layanan text-to-SQL di hilir menyusun kueri yang meminta lebih banyak kolom daripada semestinya, dan respons penjelasannya merujuk pada data yang seharusnya dibatasi. Hal ini mengungkap celah nyata antarsistem, yaitu jenis kerentanan yang hanya muncul ketika Anda menguji seluruh tumpukan, bukan komponen individual secara terpisah.
Lakukan red teaming pada sistem, bukan model. Menguji LLM secara terpisah hanya memberikan sedikit gambaran tentang postur keamanan aplikasi Anda. Uji seluruh tumpukan secara menyeluruh dari awal hingga akhir, sebagaimana pengguna berinteraksi dengannya.
Validasi masukan harus dilakukan sebelum LLM. Kueri yang disandikan, serangan dengan beragam maksud, dan percobaan injeksi dasar harus dihentikan di perimeter, bukan diserahkan kepada layanan hilir.
Jangan percaya begitu saja pada titik sambungan. Dalam arsitektur multilayanan, kerentanan paling menarik bersembunyi di celah antarsistem. Zero-trust tetap berarti tanpa kepercayaan, jadi validasi semuanya pada setiap lapisan.
Serangan sederhana pun berhasil. Jailbreak canggih menjadi berita utama, tetapi terkadang Anda cukup... meminta. Jika sistem Anda dengan mudah menampilkan pengenal internal saat pengguna menyertakannya dalam kueri yang sebenarnya sah, itu adalah masalah.
Pahami apa yang sebenarnya Anda uji. Pola serangan yang dikenal mungkin dicegah oleh pelatihan LLM itu sendiri, bukan oleh mekanisme perlindungan Anda. Bangun kemampuan observasi ke dalam red teaming agar Anda memahami kontrol mana yang benar-benar diuji.
Lingkungan terbatas membutuhkan solusi kreatif. Penyedia khusus dan dukungan model lokal memungkinkan red teaming yang bermakna tanpa akses cloud khusus. Namun, jelaskan secara transparan keterbatasan yang ditimbulkannya.
Red teaming bukan kegiatan sekali jalan. Prosesnya bersifat iteratif, perlu diotomatisasi jika memungkinkan, dan harus berkembang seiring perkembangan sistem Anda. Serangan yang penting besok tidak sama dengan yang penting hari ini.
Sistem AI di lingkungan teregulasi akan menghadapi pengawasan yang semakin ketat, bukan semakin longgar. Organisasi yang memperlakukan pengujian keamanan sebagai disiplin berkelanjutan, bukan sekadar kotak centang sebelum peluncuran, akan lebih siap menghadapi pengawasan tersebut dan menghindari bencana kehumasan yang menghilangkan kepercayaan pelanggan.