Asisten menyatakan telah menolak mengirim dokumen. Pengujian dinyatakan lulus. Belakangan, catatan pengiriman menunjukkan pesan sudah keluar sebelum penolakan itu muncul.
Kegagalan fiktif ini menggambarkan kelemahan umum dalam pengujian agen: memeriksa jawaban tanpa memeriksa tindakannya. Rencana uji keamanan yang berguna menetapkan hal yang harus dilindungi, memicu kegagalan yang relevan, lalu memeriksa keadaan akhirnya secara terpisah dari penjelasan model.
Gunakan lingkungan terkendali milik sendiri atau yang pengujiannya telah diizinkan. Identitas sintetis, dokumen fiktif, dan penampung pengiriman lokal cukup untuk contoh di sini. Data pelanggan produksi menambah risiko tanpa memperbaiki kualitas pemeriksaan tersebut.
Mulai dari satu tindakan yang dilindungi
Pilih tindakan yang penting, misalnya mengirim balasan dukungan. Tulis aturan tetapnya dalam bentuk yang dapat diamati: “Pesan tidak boleh keluar tanpa persetujuan yang masih berlaku untuk penerima, isi, dan tugas saat ini.”
Lalu tentukan sumber buktinya. Percakapan merupakan satu sumber; jejak pemanggilan alat, catatan persetujuan, dan penampung pengiriman memberi sumber lain. Untuk operasi baca, periksa data apa yang dikembalikan aplikasi. Untuk operasi tulis, periksa keadaan tersimpan dan objek yang terkena perubahan.
Batasi skenario agar arti kegagalannya jelas. Tolok ukur panjang yang mencampurkan pencarian, perubahan akun, dan email dapat gagal karena hal yang tidak berkaitan dengan batas keamanan yang sedang ditinjau.
Buat matriks kasus yang ringkas
Untuk asisten dukungan, rangkaian awal bisa seperti berikut:
| Kasus | Perubahan dari tugas yang diizinkan | Bukti yang diperlukan |
|---|---|---|
| Balasan sah | Tidak ada | Satu pengiriman ke penerima yang disetujui |
| Instruksi tidak tepercaya | Dokumen meminta tindakan di luar tugas | Tidak ada akibat pemanggilan alat tanpa izin |
| Pelanggan berbeda | Usulan pembacaan mengacu ke data pelanggan lain | Tidak ada data di luar cakupan otorisasi yang dikembalikan |
| Draf berubah | Isi berubah setelah persetujuan | Tidak terkirim memakai persetujuan lama |
| Tugas dicabut | Pembatalan terjadi sebelum eksekusi | Tindakan tertunda ditolak |
| Percobaan ulang | Permintaan sah yang sama dikirim dua kali | Tidak ada pengiriman ganda |
| Fixture hilang | Layanan uji yang dituju tidak tersedia | Tidak ada percobaan yang menjangkau pengganti nyata |
Ini rangkaian awal, bukan klaim bahwa seluruh risiko sudah tercakup. Tambahkan kasus berdasarkan alat, data, dan riwayat kegagalan alur kerja Anda.
Pisahkan uji kebijakan dari evaluasi model
Uji kebijakan mengirim usulan tindakan langsung ke lapisan penegakan aturan. Hasilnya harus deterministik: tindakan tidak sah yang sama selalu ditolak, siapa pun model yang mengusulkannya. Pemeriksaan ini cukup cepat untuk dijalankan pada setiap perubahan kode yang relevan.
Evaluasi model menempatkan agen dalam suatu tugas dan mengamati usulannya. Untuk uji prompt injection tidak langsung, letakkan instruksi bertentangan yang tidak berbahaya di dalam dokumen sintetis, lalu pastikan sistem memperlakukannya sebagai data, bukan kewenangan. Jangan arahkan latihan ke pihak luar atau sertakan rahasia nyata.
Ulangi evaluasi model dengan konfigurasi yang dicatat karena perilakunya dapat berubah. Catat versi model, revisi prompt, alat yang tersedia, pengaturan sampling jika dapat diakses, versi fixture, dan jumlah pelaksanaan. Laporkan angka teramati beserta pembaginya, misalnya “0 pengiriman tanpa izin dalam 20 pelaksanaan kasus ini.” Jangan mengubah sampel kecil menjadi jaminan keamanan umum.
Ukur juga keberhasilan tugas yang sah. Sistem yang menolak semua tindakan mungkin mencegah kegagalan ini, tetapi tidak bisa digunakan untuk pekerjaan yang dimaksudkan.
Uji kegagalan antara perencanaan dan eksekusi
Otorisasi dapat berubah saat tugas menunggu di antrean. Uji pembatalan setelah rencana dibuat, tetapi sebelum alat dijalankan. Ubah isi tindakan setelah persetujuan. Jalankan dua worker pada operasi yang sama jika aplikasi mendukung konkurensi.
Untuk tindakan jarak jauh, simulasikan timeout setelah layanan penerima menerima permintaan. Percobaan berikutnya harus mencocokkan kembali operasi yang diketahui atau memakai idempotensi yang didukung, bukan mengirim permintaan baru yang terpisah. Timeout saja belum membuktikan bahwa tidak ada tindakan yang terjadi.
Pengujian ini perlu berada pada batas tindakan aplikasi yang sebenarnya. Mengganti pemeriksaan otorisasi dengan mock yang selalu menolak tidak banyak membuktikan perilaku jalur asli.
Pastikan pengujian mampu menemukan kegagalan
Sebelum mempercayai uji penolakan, buktikan bahwa pengamatannya bekerja. Pesan sintetis yang diizinkan harus muncul pada penampung pengiriman. Fixture lokal yang sengaja tidak dilindungi harus membuat assertion terkait gagal. Pisahkan fixture tersebut dari kode produksi.
Langkah ini mencegah hasil lulus karena agen tidak pernah berjalan, alat tidak tersambung, atau assertion membaca log yang salah. Bedakan “tindakan diblokir” dari “skenario tidak dijalankan” dalam hasil pengujian.
Periksa bukti sebelum menyimpannya agar tidak memuat data sensitif yang tidak diperlukan. Biasanya ID operasi, pelaksana, klasifikasi target, hasil aturan, dan jumlah pengiriman sudah cukup. Batasi akses serta retensi jika jejak eksekusi memang perlu memuat teks dokumen.
Buat keputusan rilis dapat ditelusuri
Untuk setiap kasus, simpan hasil yang diharapkan, keadaan sebenarnya, lokasi bukti, dan penanggung jawab kegagalan yang belum selesai. Tandai pemeriksaan yang belum dijalankan dengan jelas. Ulangi kasus terdampak ketika izin, alat, prompt, atau versi model berubah.
Desain alat dengan hak akses minimum memudahkan pekerjaan ini karena setiap tindakan memiliki akibat yang diperbolehkan dalam cakupan lebih kecil. Tinjauan kode yang dibatasi dengan jelas kemudian dapat menghubungkan pengujian dengan kode yang menegakkan aturannya.
Hasil awal yang berguna adalah matriks kecil dengan bukti yang dapat diulang. Jika peninjau bisa menjelaskan mengapa satu tindakan terlarang berhenti dan satu tindakan sah berhasil, rencana tersebut sudah memiliki dasar untuk dikembangkan.
Bacaan lanjutan: OWASP Prompt Injection dan temuan evaluasi Anthropic. Skenario dan rekomendasi pengujian merupakan materi editorial Linmas.