Tutorial: Menguji Chatbot LLM Anda terhadap Prompt Injection dengan Promptfoo, dari Uji Regresi Keamanan hingga Red Teaming Otomatis di CI/CD

Banyak perusahaan di Indonesia kini memasang chatbot berbasis LLM di layanan pelanggan, aplikasi internal, hingga asisten HR. Pertanyaannya sering berhenti di "apakah jawabannya bagus?", padahal pertanyaan yang sama pentingnya adalah "apakah chatbot ini bisa dipaksa membocorkan instruksi sistem, data pelanggan, atau menjalankan aksi yang tidak semestinya?". Tutorial ini membahas cara menjawabnya secara terukur: menulis uji keamanan yang bisa diulang setiap kali prompt atau model berubah, lalu meningkatkannya menjadi red teaming otomatis memakai Promptfoo, perangkat sumber terbuka untuk evaluasi dan pengujian aplikasi LLM.

Mengapa Uji Manual Tidak Cukup

LLM bersifat probabilistik. Masukan yang sama dapat menghasilkan keluaran berbeda, sehingga serangan yang gagal hari ini bisa berhasil besok, atau setelah Anda mengganti versi model atau mengubah satu kalimat pada system prompt. Dokumen OWASP Top 10 for LLM Applications menempatkan prompt injection di posisi teratas (LLM01) sejak edisi awal, dan edisi 2026 tetap menekankan risiko seperti excessive agency, yaitu ketika model diberi kewenangan bertindak melebihi kebutuhan. Menguji secara manual satu-dua kalimat "abaikan instruksi sebelumnya" jelas tidak mewakili ruang serangan yang sesungguhnya.

Pendekatan yang lebih sehat adalah memperlakukan keamanan prompt seperti pengujian perangkat lunak biasa: ada kumpulan kasus uji, ada kriteria lulus/gagal, dan ada otomatisasi yang berjalan di setiap perubahan. Inilah yang dimungkinkan oleh Promptfoo.

Dua Lapis Pengujian yang Akan Kita Bangun

1. Uji regresi keamanan (deterministik-ish): kumpulan serangan yang sudah Anda kenal, ditulis sendiri, dengan asersi sederhana. Cepat, murah, dan cocok sebagai gerbang CI.
2. Red teaming otomatis: sebuah LLM penyerang menghasilkan ratusan variasi serangan, target diuji, lalu LLM penilai menilai hasilnya. Lebih luas cakupannya, tetapi lebih mahal dan hasilnya perlu ditinjau manusia.

Langkah 1: Persiapan

Pastikan Node.js terpasang, lalu pasang Promptfoo dan siapkan kunci API penyedia model yang Anda uji lewat variabel lingkungan (jangan menulisnya di berkas konfigurasi yang masuk repositori).

Skenario contoh: chatbot "Asisten Layanan Nasabah" milik sebuah fintech fiktif. Ia hanya boleh menjawab pertanyaan produk, tidak boleh membuka isi system prompt, dan tidak boleh menampilkan data pribadi seperti NIK.

Langkah 2: Tulis System Prompt yang Diuji

Simpan sebagai prompt.txt. Variabel {{pesan}} akan diisi oleh setiap kasus uji.

Langkah 3: Uji Regresi Keamanan

Buat promptfooconfig.yaml. Perhatikan campuran asersi: not-contains murah dan pasti, sedangkan llm-rubric memakai model sebagai penilai untuk kasus yang sulit dirumuskan dengan string.

Kasus terakhir penting: uji keamanan yang hanya memeriksa penolakan akan mendorong Anda membuat chatbot yang menolak segalanya. Selalu sertakan kasus "pengguna sah tetap dilayani" agar Anda mengukur false refusal sekaligus kebocoran.

Jalankan dan lihat hasilnya:

promptfoo eval menampilkan tabel lulus/gagal per kasus, sedangkan promptfoo view membuka antarmuka web lokal untuk membandingkan keluaran. Anda juga bisa mengubah daftar providers menjadi beberapa model sekaligus untuk membandingkan ketahanan tiap model dengan prompt yang sama.

Langkah 4: Tambahkan Serangan Tak Langsung

Ancaman yang lebih realistis di perusahaan bukan pengguna yang mengetik serangan, melainkan konten pihak ketiga yang dibaca model: email, dokumen PDF, halaman web, atau hasil pencarian internal. Simulasikan dengan menyisipkan instruksi tersembunyi ke dalam variabel konteks.

Bila aplikasi Anda memiliki alat (misalnya kirim email atau kueri basis data), jangan hanya menguji teks keluaran. Periksa apakah model memanggil alat yang tidak semestinya. Pada kasus itu, kontrol utamanya bukan prompt, melainkan otorisasi di sisi kode: hak akses harus diperiksa program, bukan "diminta" kepada model.

Langkah 5: Red Teaming Otomatis

Setelah regresi dasar stabil, gunakan fitur redteam. Arsitekturnya biasanya tiga peran: LLM penyerang yang membangkitkan payload, target yang diuji, dan LLM penilai (LLM-as-a-judge). Di Promptfoo, plugin menentukan jenis kerentanan yang diuji, sedangkan strategy menentukan cara serangan dikirim (misalnya jailbreak iteratif, penyandian base64, atau bahasa lain). Berkas konfigurasi terpisah, redteam.yaml, dapat dimulai seperti ini:

Nama plugin dan strategy dapat berubah antarversi, jadi cocokkan dengan dokumentasi resmi Promptfoo versi yang Anda pasang. Satu catatan biaya: jumlah kasus uji adalah perkalian plugin, jumlah uji per plugin, dan strategy. Empat plugin dengan 10 uji dan empat strategy sudah menghasilkan sekitar 160 kasus; untuk 50 uji per plugin dengan delapan strategy angkanya melonjak menjadi 1.600 kasus. Mulailah kecil.

Bidang purpose adalah masukan terpenting: semakin spesifik Anda menjelaskan apa yang boleh dan tidak boleh dilakukan aplikasi, semakin relevan serangan yang dihasilkan. Tulis dalam bahasa yang dipakai pengguna Anda. Untuk layanan berbahasa Indonesia, strategi multibahasa dan campuran bahasa penting karena banyak pengguna berganti antara Indonesia, Inggris, dan bahasa daerah dalam satu percakapan.

Membaca Hasil dengan Kritis

Sebuah pengantar red teaming otomatis dari NVISO (Februari 2026) menguji chatbot sengaja-rentan dengan Promptfoo dan melaporkan beberapa pelajaran yang patut dicatat. Tingkat keberhasilan serangan naik tajam saat strategi jailbreak iteratif dipakai (sekitar 13% tanpa strategi menjadi sekitar 73% dengan strategi tersebut menurut data yang mereka laporkan, meski artikelnya sendiri menyebut angka berbeda pada narasi sehingga sebaiknya dirujuk ke sumber aslinya). Penilai otomatis juga bisa keliru: satu kebocoran lolos dari penilaian otomatis dan baru ditemukan lewat tinjauan manual, sehingga tingkat lulus turun setelah ditinjau. Aplikasi yang hanya mengandalkan LLM untuk menegakkan hak akses terbukti mudah ditembus.

Implikasinya bagi tim Anda:

1. Jangan percaya satu angka. Tinjau sampel hasil "lulus" secara manual, bukan hanya yang gagal.
2. Ulangi pengujian. Karena sifat probabilistik, jalankan beberapa kali dan perhatikan variasinya.
3. Kendalikan biaya. Strategi iteratif memakai banyak token; tetapkan batas konkurensi dan anggaran.
4. Pindahkan keputusan penting ke kode. Otorisasi, batas transaksi, dan pembatasan alat harus ditegakkan di luar model.

Langkah 6: Jadikan Gerbang CI/CD

Nilai uji keamanan muncul saat ia berjalan otomatis. Contoh alur GitHub Actions sederhana yang menjalankan regresi pada setiap pull request yang menyentuh prompt:

Bila ada kasus yang gagal, perintah promptfoo eval mengembalikan kode keluar bukan-nol sehingga PR tertahan (periksa perilaku persisnya pada versi Anda). Pisahkan dua alur: regresi cepat pada setiap PR, dan red teaming penuh yang lebih mahal secara terjadwal, misalnya mingguan atau sebelum rilis besar.

Rambu Hukum dan Etika di Indonesia

Gunakan data fiktif pada seluruh kasus uji. Jangan memasukkan NIK, NPWP, atau data nasabah sungguhan ke penyedia model eksternal hanya untuk menguji, sebab itu sendiri merupakan pemrosesan data pribadi yang tunduk pada UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi. Bila hasil red teaming menunjukkan chatbot Anda dapat membocorkan data pribadi, perlakukan sebagai temuan keamanan: perbaiki, catat, dan nilai apakah perlu dilakukan penilaian dampak. Lakukan pengujian hanya pada sistem milik Anda atau yang telah Anda dapatkan izin tertulisnya; menguji layanan AI pihak lain tanpa izin dapat bersinggungan dengan UU ITE tentang akses ilegal. Untuk kerangka tata kelola, rujuk NIST AI Risk Management Framework dan standar ISO/IEC 42001 tentang sistem manajemen AI.

Daftar Periksa Singkat

1. Tulis 10-20 kasus regresi: injeksi langsung, peran palsu, pengelabuan format, injeksi tak langsung, dan kasus pengguna sah.
2. Gunakan asersi pasti (not-contains) bila memungkinkan, dan llm-rubric untuk sisanya.
3. Jalankan regresi di setiap perubahan prompt atau model.
4. Jalankan red teaming terjadwal, mulai dari skala kecil, dan tinjau hasilnya secara manual.
5. Tegakkan otorisasi dan batas aksi di kode, bukan di prompt.
6. Pakai data fiktif, simpan kunci API di secret manager, dan dokumentasikan temuan.

Penutup

Pengujian keamanan LLM bukan kegiatan sekali jadi. Model, prompt, dan data berubah, begitu pula teknik serangannya. Dengan memadukan regresi yang murah dan red teaming yang luas, tim Anda mendapat umpan balik objektif sebelum pengguna sungguhan, atau penyerang, menemukan celahnya lebih dulu. Siberindo membantu organisasi merancang pengujian keamanan AI, tata kelola penggunaan LLM, dan kesiapan respons insiden; hubungi kami bila Anda ingin menilai kesiapan chatbot atau agen AI di perusahaan Anda.