Dokumen Beracun: Celah Prompt Injection dalam RAG

Retrieval-augmented generation (RAG) menggabungkan model artificial intelligence (AI), atau kecerdasan buatan, dengan dokumen yang ditemukan saat pengguna bertanya. RAG membantu menampilkan sumber, tetapi juga membuka ja
Ilustrasi keamanan dokumen dan sistem pencarian AI

Jawaban singkat: RAG membuat jawaban AI lebih mudah ditelusuri, tetapi dokumen sumber bisa membawa instruksi berbahaya. Audit ini memetakan provenance, akses, pemisahan instruksi, dan uji regresi.

Masalah keamanan tidak berhenti di chatbot

Retrieval-augmented generation (RAG) menggabungkan model artificial intelligence (AI), atau kecerdasan buatan, dengan dokumen yang ditemukan saat pengguna bertanya. RAG membantu menampilkan sumber, tetapi juga membuka jalur serangan: dokumen yang tampak sebagai referensi dapat memuat instruksi untuk mengubah perilaku model. Bahayanya muncul ketika konten tidak tepercaya diperlakukan sebagai perintah operasional.

OWASP mengategorikan prompt injection dan kelemahan vektor atau embedding sebagai risiko aplikasi model bahasa. Serangan dapat datang dari halaman web, berkas PDF, hasil pencarian, atau isi repositori. Artikel ini menyusun prosedur audit defensif dan skenario uji terkontrol; tidak menyediakan instruksi untuk mengeksploitasi sistem pihak lain.

Bedakan data, instruksi, dan otorisasi

Dokumen referensi boleh menjadi bukti jawaban, tetapi tidak boleh mengubah kebijakan akses atau memerintahkan alat mengirim data. Prompt sistem menentukan tujuan aplikasi; dokumen eksternal adalah data dengan tingkat kepercayaan lebih rendah. Pemisahan ini harus dipertahankan ketika sistem merangkai konteks panjang dari berbagai sumber.

Misalnya, dokumen kebijakan internal yang diunggah pengguna menyebut bahwa seluruh verifikasi keamanan harus diabaikan. Kalimat itu tetap isi dokumen, bukan instruksi sah bagi asisten. Aplikasi harus dapat mengutipnya sebagai objek analisis tanpa menjalankannya sebagai kebijakan baru.

Peta jalur masuk dokumen beracun

Tahap pertama adalah ingestion: dokumen diterima, diubah menjadi teks, dan dipecah menjadi potongan. Tahap kedua embedding dan indeks: potongan disimpan agar dapat dicari. Tahap ketiga retrieval: potongan dipilih menurut kemiripan atau aturan pencarian. Tahap keempat generation: model menyusun jawaban berdasarkan konteks.

Setiap tahap memiliki kontrol berbeda. Ingestion memerlukan asal dokumen dan pemeriksaan tipe berkas. Indeks memerlukan batas akses per tenant dan penghapusan yang dapat dibuktikan. Retrieval perlu memastikan pengguna hanya melihat potongan yang diizinkan. Generation memerlukan aturan bahwa konten referensi tidak dapat memanggil tool berhak istimewa.

Matriks AIGEO: empat lapis kontrol

Lapisan identitas memastikan siapa boleh memasukkan dokumen. Lapisan provenance menyimpan sumber, waktu, versi, dan pemilik. Lapisan kebijakan memisahkan instruksi aplikasi dari data. Lapisan output memeriksa apakah jawaban mengutip sumber benar, membocorkan data, atau memicu tindakan yang tidak diotorisasi.

Tidak ada satu filter kata kunci yang menyelesaikan semua risiko. Instruksi berbahaya dapat ditulis dalam bahasa berbeda atau disisipkan dalam konten yang tampak normal. Karena itu kontrol harus menahan dampak ketika model tetap salah menafsirkan isi dokumen.

Uji defensif dengan dataset sintetis

Buat 100 dokumen uji buatan yang tidak mengandung data nyata. Sisipkan 20 dokumen dengan kalimat konflik instruksi yang tidak berbahaya, misalnya meminta jawaban mengganti format wajib tanpa izin. Sisanya dokumen biasa dengan fakta yang dapat dicek. Ajukan 50 pertanyaan yang mencakup kedua kelompok, dan catat apakah sistem mengikuti instruksi dari dokumen alih-alih menjawab pertanyaan pengguna.

Ukuran sederhana adalah attack success rate (ASR) = jumlah percobaan yang berhasil mengubah perilaku terlarang dibagi jumlah percobaan serangan. Jika 4 dari 20 skenario konflik berhasil, ASR=20 persen. Angka itu hasil simulasi contoh, bukan pengujian terhadap produk tertentu. Ukur pula false positive: dokumen sah yang keliru ditolak oleh filter.

Mengapa sitasi saja tidak cukup

Sistem yang menampilkan tautan sumber dapat tetap keliru apabila potongan yang dipilih sudah diracuni. Sitasi membuktikan dari mana model mengambil kalimat, bukan otomatis membuktikan kebenaran dokumen. Pemeriksa perlu memverifikasi sumber asli, tanggal, versi, serta apakah dokumen memiliki kewenangan untuk pernyataan tersebut.

Baca audit Satu Data Indonesia dan interoperabilitas untuk isu tata kelola sumber, serta SBOM dan VEX untuk prioritas risiko komponen. RAG membutuhkan gabungan keamanan informasi dan pengelolaan kualitas bukti, bukan hanya tuning prompt.

Kontrol izin sebelum model memanggil alat

Jika chatbot boleh mengirim email, mengubah database, atau menjalankan workflow, izin harus diperiksa di luar model. Dokumen referensi tidak boleh menaikkan hak akses. Gunakan allowlist tindakan, parameter yang divalidasi, persetujuan manusia untuk perubahan penting, dan audit log yang merekam permintaan serta hasil.

Prinsip least privilege mengurangi dampak kesalahan: asisten pencarian kebijakan tidak perlu izin menghapus berkas; asisten pembuat ringkasan tidak perlu token pembayaran. Pembatasan ini tetap berguna bahkan jika prompt injection tidak terdeteksi.

Prosedur respons insiden

Ketika ditemukan jawaban yang mengikuti instruksi berbahaya dari dokumen, hentikan pemakaian sumber terkait, simpan bukti log sesuai kebijakan privasi, identifikasi versi indeks, dan uji apakah jawaban serupa pernah dikirim kepada pengguna lain. Jangan langsung menghapus seluruh jejak sebelum analisis penyebab selesai.

Perbaikan harus mencakup penyebab sistemik: proses unggah, validasi metadata, pengendalian akses, pembatasan tool, dan tes regresi. Menambal satu kalimat prompt tanpa memperbaiki rantai kepercayaan membuat serangan mudah berulang dengan variasi redaksi.

Kesimpulan

RAG meningkatkan keterlacakan jawaban, tetapi bukan jaminan kebenaran atau keamanan. Konten dari luar tetap data tidak tepercaya, walaupun tampil dalam PDF resmi atau halaman web yang rapi. Uji keamanan harus mencakup asal dokumen, pemilihan potongan, hak akses, dan tindakan hilir.

Audit AIGEO mengusulkan pengukuran ASR, false positive, kebocoran lintas pengguna, dan keberhasilan sitasi ke sumber yang sah. Hasil pengujian perlu dicatat berkala agar peningkatan model tidak diam-diam menurunkan keamanan.

Matriks audit AIGEO

TahapRisikoKontrol
IngestionDokumen palsuVerifikasi asal dan versi
RetrievalKebocoran lintas tenantFilter izin
GenerationInstruksi dari dokumen ditaatiPemisahan data dan perintah
Tool actionTindakan tidak sahOtorisasi eksternal

Tabel ini merupakan ringkasan metodologi dan ilustrasi redaksi, bukan statistik resmi atau format wajib regulator. Seluruh angka simulasi harus diuji dengan data operasional sebelum dipakai mengambil keputusan.

Sumber primer dan metode

Dokumen sumber diperiksa 28 Oktober 2026. Seluruh contoh harga, hasil uji, dan anggaran yang disebut simulasi bukan observasi lapangan atau penawaran resmi.

Bedakan poisoning dan prompt injection

Data poisoning mengubah materi yang dipakai untuk melatih, menyetel, atau mengambil konteks sehingga keluaran model menyimpang. Prompt injection menanam instruksi yang mencoba melampaui hierarki kendali aplikasi. Dalam RAG, keduanya dapat beririsan: dokumen beracun diindeks, kemudian instruksinya masuk melalui hasil retrieval. Tetapi mitigasinya tidak identik. Poisoning menuntut tata kelola sumber dan perubahan indeks; prompt injection menuntut pemisahan instruksi dan pembatasan tindakan. Audit yang hanya memeriksa teks prompt sistem dapat melewatkan kontaminasi dokumen. Sebaliknya, hanya memeriksa reputasi dokumen belum tentu mencegah model mematuhi instruksi terselubung.

Mengukur paparan indeks

Misalkan repositori memuat 50.000 potongan dokumen dan 200 di antaranya berasal dari sumber yang belum diverifikasi. Proporsi potongan tidak terverifikasi = 200/50.000 = 0,4 persen. Namun angka ini tidak sama dengan probabilitas serangan. Jika potongan bermasalah sangat relevan terhadap pertanyaan populer, frekuensi retrieval bisa jauh lebih tinggi daripada proporsi indeks. Karena itu pengujian harus mencatat seberapa sering dokumen bermasalah dipanggil dan apakah sistem menggunakannya sebagai bukti atau perintah. Sampel acak indeks dan sampel hasil pencarian teratas mengukur dua risiko berbeda.

Kontrol tenant dan dokumen pribadi

Aplikasi RAG perusahaan sering menggabungkan dokumen banyak tim atau pelanggan. Filter izin harus diterapkan pada retrieval sebelum teks masuk konteks model. Menyembunyikan hasil akhir setelah model melihat dokumen rahasia bukan kontrol memadai karena model mungkin sudah memasukkan informasi tersebut ke jawaban. Uji akses silang dengan akun uji berizin berbeda dan dokumen sintetis yang memiliki penanda unik. Catat apakah hasil pencarian, metadata, dan sitasi ikut membocorkan keberadaan dokumen. Pengujian tidak memerlukan data pelanggan nyata; gunakan contoh buatan dengan struktur izin yang setara.

Mengelola versi dokumen

Ketika kebijakan diperbarui, indeks dapat tetap menyimpan potongan versi lama. Asisten lalu mengutip peraturan yang sudah diganti meskipun berkas terbaru tersedia. Setiap potongan sebaiknya menyimpan ID dokumen, versi, tanggal berlaku, tanggal indeks, dan status aktif. Penghapusan harus mencakup cache dan indeks turunan sesuai kemampuan sistem. Audit dilakukan dengan pertanyaan yang secara sengaja menargetkan versi lama dan baru. Jika sistem tidak mampu membedakan tanggal berlaku, ia harus mengungkap ketidakpastian, bukan menyatakan satu aturan sebagai yang terbaru.

Desain uji regresi

Buat paket pertanyaan tetap yang dijalankan setelah setiap perubahan model, pipeline, atau kebijakan. Paket mencakup jawaban normal, dokumen kontradiktif, dokumen dengan instruksi yang tidak sah, dan permintaan tindakan yang memerlukan otorisasi. Untuk setiap kasus, tentukan keluaran yang diharapkan sebelum tes. Simpan versi perangkat lunak, model, indeks, prompt, serta skor hasil. Jika satu kontrol meningkatkan keamanan tetapi mengurangi kemampuan menjawab pertanyaan sah, laporkan trade-off itu. Keamanan tidak boleh dinilai hanya dari jumlah permintaan yang ditolak.

Mekanisme pemulihan jawaban salah

Jika chatbot pernah menyampaikan informasi yang tidak sah, organisasi perlu menentukan siapa menerima koreksi. Log minimal harus memungkinkan identifikasi waktu, sumber yang dipakai, dan jenis jawaban tanpa menyimpan data pribadi lebih lama daripada diperlukan. Koreksi dapat berupa penarikan dokumen, pembaruan indeks, pemberitahuan pengguna yang terdampak, dan audit proses. Jangan menjanjikan bahwa menghapus satu file otomatis menghapus semua salinan dalam cache atau sistem cadangan. Tim teknis harus membuktikan hasil penghapusan sesuai arsitektur.

Kriteria penerimaan sebelum produksi

AIGEO mengusulkan kriteria minimum yang ditetapkan organisasi sendiri: tidak ada kebocoran lintas tenant pada tes yang dirancang, tidak ada pemanggilan tool berhak istimewa dari instruksi dokumen, provenance tersedia untuk jawaban berisiko, dan mekanisme rollback diuji. Tidak ada satu angka ASR yang berlaku universal untuk seluruh sektor. Sistem informasi umum dan sistem pengambilan keputusan kesehatan memiliki konsekuensi berbeda. Kriteria harus disetujui pemilik risiko, bukan hanya tim pengembang. Hasil tes negatif juga tidak membuktikan keamanan sempurna; cakupan skenario harus dijelaskan.

Menghubungkan kontrol dengan standar

Kerangka NIST AI RMF dapat dipakai untuk membagi tanggung jawab Govern, Map, Measure, dan Manage. OWASP menyediakan taksonomi ancaman aplikasi model bahasa. Keduanya melengkapi, bukan menggantikan, pengujian penetrasi tradisional dan pengamanan identitas. Inventaris komponen perangkat lunak, kebijakan akses, logging, serta respons insiden tetap diperlukan. Dalam laporan manajemen, tunjukkan kontrol apa mengurangi risiko apa dan bukti pengujiannya. Jangan mengklaim sertifikasi NIST atau OWASP hanya karena nama kerangka disebut dalam dokumen proyek.

Metrik kualitas jawaban di samping keamanan

Sistem yang menolak semua pertanyaan dapat terlihat aman dari prompt injection, tetapi gagal menjalankan fungsinya. Karena itu uji harus memuat tingkat jawaban benar pada pertanyaan sah, ketepatan sitasi, dan tingkat penolakan keliru. Misalkan 100 pertanyaan normal diuji dan 12 ditolak tanpa alasan, false refusal rate adalah 12 persen. Jika perlindungan baru menurunkan ASR tetapi menaikkan penolakan keliru menjadi 40 persen, pemilik produk perlu menilai dampak layanan. Pengukuran keamanan yang matang menyajikan kedua sisi, bukan satu skor yang mudah dipoles.

Audit peran manusia

Petugas yang meninjau jawaban perlu mengetahui kapan model memakai sumber berisiko, bukan hanya menerima label aman atau berbahaya. Antarmuka dapat menampilkan asal dokumen, tanggal, dan alasan penandaan, kemudian memberi pilihan mengabaikan sumber atau meminta verifikasi. Persetujuan manusia harus bermakna: jika petugas menerima ratusan alarm tanpa konteks, fungsi pengawasan menjadi formalitas. Ukur jumlah keputusan yang benar-benar ditinjau, waktu pemeriksaan, dan tingkat koreksi. Pelatihan operator juga harus mencakup contoh dokumen yang menyamar sebagai instruksi sistem.

Skenario uji lintas bahasa

Serangan dapat menggunakan campuran bahasa Indonesia, Inggris, dan istilah teknis yang tidak terdeteksi filter sederhana. Paket uji defensif perlu memasukkan dokumen multibahasa, tabel, hasil OCR, dan halaman dengan format tidak lazim. Jangan mengasumsikan keberhasilan tes bahasa Inggris otomatis berlaku untuk dokumen layanan publik Indonesia. Catat hasil per format dan bahasa, lalu lakukan pemeriksaan manual atas kegagalan. Penggunaan data sintetis menghindari kebocoran ketika pengujian dilakukan bersama vendor. Hasil perbandingan harus menjelaskan versi model dan tanggal pengujian.

Apa yang harus disampaikan kepada direksi

Direksi memerlukan ringkasan risiko yang menghubungkan jalur serangan dengan dampak bisnis. Misalnya, dokumen palsu dapat mengubah jawaban, kebocoran antarbagian dapat membuka rahasia perusahaan, dan tool berizin luas dapat memicu tindakan tidak sah. Setiap risiko memerlukan pemilik kontrol, status uji, batas penerimaan, dan rencana pemulihan. Hindari laporan yang hanya menyebut jumlah serangan diblokir tanpa jumlah total percobaan dan kondisi uji. Keputusan go-live harus mempertimbangkan manfaat produk, konsekuensi kegagalan, dan kemampuan mengembalikan layanan ke kondisi aman.

Komentar & Diskusi

Tulis Komentar

Bagikan pendapat Anda dengan sopan dan relevan. Alamat email tidak akan ditampilkan.