RAG Poisoning: Saat Knowledge Base Menjadi Jalur Serangan

Ada asumsi yang sangat nyaman dalam banyak proyek RAG: kalau dokumennya ada di knowledge base internal, berarti dokumennya aman.

Asumsi itu bisa mahal.

Retrieval-Augmented Generation dirancang supaya model tidak hanya mengandalkan pengetahuan dari training. Sistem mencari potongan dokumen yang relevan, memasukkannya ke context, lalu menghasilkan jawaban berdasarkan informasi tersebut. Untuk customer support, legal search, internal knowledge assistant, sales enablement, atau enterprise search, pola ini sangat berguna.

Tetapi knowledge base juga menjadi supply line ke model. Kalau supply line itu diracuni, model bisa menerima informasi salah, instruksi berbahaya, atau konten yang sengaja dibuat supaya sering ter-retrieve.

Inilah inti RAG poisoning.

Bukan cuma “dokumen salah”

Poisoning punya beberapa bentuk.

Yang paling sederhana adalah factual poisoning: penyerang atau proses yang buruk memasukkan data keliru ke knowledge base. Model kemudian menggunakannya sebagai sumber sehingga jawaban terlihat grounded, padahal basisnya sudah rusak.

Bentuk lain adalah retrieval manipulation. Konten dibuat agar sangat cocok dengan query tertentu sehingga sistem lebih sering mengambilnya daripada dokumen yang lebih benar.

Ada juga instruction poisoning. Sebuah dokumen berisi kalimat yang berusaha memengaruhi perilaku model, misalnya menyuruh model mengabaikan policy, membocorkan data, atau memanggil tool tertentu.

Lalu ada vector atau embedding weakness. OWASP secara khusus membahas risiko pada vector dan embedding dalam aplikasi RAG. Ketika representasi, indexing, permission, atau retrieval logic lemah, konten yang seharusnya tidak muncul dapat ikut masuk ke context.

Semua itu punya satu kesamaan: retrieval relevan tidak sama dengan retrieval aman.

“Kan ini dokumen internal” bukan bukti trust

Bayangkan knowledge assistant perusahaan mengambil data dari Google Drive, SharePoint, wiki internal, tiket support, dan dokumen yang di-upload karyawan.

Seorang staf memasukkan file dari vendor tanpa membaca seluruh isinya. File tersebut berisi instruksi tersembunyi yang secara sengaja dibuat untuk agent. Sistem melakukan chunking, membuat embedding, lalu menyimpannya ke vector database.

Beberapa minggu kemudian seseorang bertanya tentang proses procurement. Chunk berbahaya ter-retrieve karena kebetulan sangat relevan secara semantik.

Model sekarang melihat teks itu berdampingan dengan policy internal.

Apakah file tersebut otomatis tepercaya karena sudah berada di index perusahaan? Jelas tidak.

Microsoft pada dokumentasi RAG 2026 secara eksplisit menyarankan retrieved content diperlakukan sebagai untrusted input. NIST dan OWASP juga mengangkat prompt injection, poisoning, serta kelemahan vector/embedding sebagai risiko dalam sistem generative AI.

Artinya, proses ingestion harus dianggap sebagai security boundary.

Poisoning bisa datang dari luar dan dari dalam

Jangan bayangkan attacker selalu hacker anonim dari internet.

Knowledge poisoning dapat muncul dari:

akun karyawan yang dikompromikan,

vendor document,

user-generated content,

sinkronisasi folder yang terlalu luas,

pipeline crawling yang mengambil halaman tidak seharusnya,

misconfiguration permission,

dokumen lama yang sudah tidak berlaku,

atau bahkan proses editorial internal yang buruk.

Ada juga insider threat. Seseorang yang punya hak upload mungkin sengaja menambahkan konten untuk memanipulasi jawaban AI.

Lalu ada kasus non-malicious poisoning: dokumen duplikat, policy lama, spreadsheet salah, atau artikel internal yang ditulis tanpa review. Secara security mungkin bukan serangan, tetapi efeknya ke output bisa mirip: sistem menganggap sumber yang salah sebagai ground truth.

Di sinilah content governance dan cybersecurity bertemu.

RAG punya tiga permukaan yang perlu dijaga

Pertama adalah ingestion.

Apa yang boleh masuk? Dari sumber mana? Siapa pemiliknya? Apakah file pernah dipindai? Apakah ada provenance? Apakah konten berasal dari user eksternal? Apakah format bisa membawa hidden text atau instruction-like content?

Kedua adalah storage dan indexing.

Apakah permission dokumen ikut terbawa ke vector store? Apakah tenant dipisahkan? Apakah satu user bisa membuat konten yang kemudian di-retrieve user lain? Apakah embedding index dapat ditulis oleh service yang terlalu luas haknya?

Ketiga adalah retrieval dan generation.

Apakah sistem menyimpan metadata sumber? Apakah hasil retrieval diberi trust label? Apakah instruction-like text diperlakukan sebagai data? Apakah model punya tool access setelah membaca hasil tersebut? Apakah ada policy sebelum aksi sensitif?

Security RAG gagal ketika tim hanya mengamankan salah satu tahap.

Vector database bukan brankas kebenaran

Ada kecenderungan memperlakukan vector database seperti database biasa yang isinya sudah tervalidasi. Padahal vector index dioptimalkan untuk kemiripan, bukan kebenaran.

Sebuah chunk bisa sangat mirip dengan query tetapi tetap salah, outdated, malicious, atau tidak punya otoritas.

Karena itu relevance score tidak boleh disamakan dengan trust score.

Sistem yang matang bisa memisahkan kedua dimensi.

Relevance menjawab: seberapa cocok konten ini dengan pertanyaan?

Trust menjawab: seberapa layak konten ini memengaruhi jawaban atau aksi?

Freshness menjawab: apakah informasinya masih berlaku?

Authority menjawab: apakah sumbernya punya kewenangan untuk klaim tersebut?

Permission menjawab: apakah user saat ini boleh melihatnya?

Kalau semua itu dijadikan satu angka similarity, desainnya terlalu sederhana untuk use case sensitif.

Praktik mitigasi yang lebih masuk akal

Tidak ada satu teknik yang membuat RAG kebal poisoning. Pendekatannya defense in depth.

Mulai dari source allowlist untuk knowledge base penting. Jangan crawl semua yang bisa dicrawl hanya karena secara teknis mudah.

Pertahankan provenance. Setiap chunk sebaiknya dapat ditelusuri ke dokumen asli, pemilik, waktu ingestion, dan versi.

Gunakan access control yang benar-benar berlaku sampai retrieval. Jangan hanya mengandalkan filter di UI.

Pisahkan collection atau tenant kalau risiko cross-tenant tinggi.

Lakukan validation pada dokumen yang masuk. Untuk sumber sensitif, approval manusia mungkin diperlukan sebelum indexing.

Jaga versioning dan expiry. Policy lama tidak boleh terus menang hanya karena punya kemiripan semantik tinggi.

Deteksi anomali. Dokumen baru yang tiba-tiba muncul untuk banyak query penting layak diperiksa.

Batasi kemampuan agent setelah retrieval. Konten dari knowledge base jangan otomatis mendapat hak memicu tool call.

Dan lakukan red-team testing menggunakan skenario poisoning yang aman di lingkungan non-production.

Bagaimana mendeteksi knowledge base mulai “aneh”

Deteksi poisoning bukan hanya mencari kata-kata mencurigakan.

Beberapa sinyal operasional lebih menarik:

Satu dokumen mendadak muncul pada banyak query yang tidak berkaitan.

Sumber dengan authority rendah mengalahkan policy resmi.

Chunk baru punya pola similarity yang sangat agresif terhadap keyword tertentu.

Jawaban model berubah drastis setelah satu ingestion batch.

Jumlah retrieval dari sumber user-generated content melonjak.

Agent mencoba tool yang tidak relevan setelah membaca dokumen tertentu.

Dokumen yang sama sering terkait dengan refusal bypass atau policy conflict.

Ada perubahan akses atau metadata tanpa proses normal.

Monitoring seperti ini mengubah RAG dari black box menjadi sistem yang bisa diaudit.

Untuk brand, dampaknya bukan cuma security

Knowledge poisoning juga punya dimensi reputasi.

Bayangkan internal sales assistant mulai menyebut pricing yang salah. Customer support bot memberikan kebijakan refund lama. AI procurement assistant menilai vendor berdasarkan dokumen yang dimanipulasi. Brand intelligence tool menganggap rumor sebagai fakta karena rumor tersebut ter-index berulang kali.

Tidak ada data breach, tetapi keputusan bisnis sudah terkontaminasi.

Dalam konteks GEO, problem ini penting karena organisasi semakin ingin konten mereka digunakan sistem AI. Kita mengejar visibility, citation, retrieval, dan machine readability. Tetapi semakin banyak keputusan mengandalkan retrieval, semakin penting pula provenance, authority, dan governance.

Konten yang mudah ditemukan belum tentu layak dipercaya.

Knowledge base perlu diperlakukan seperti sistem produksi

Banyak organisasi masih mengelola knowledge base seperti gudang dokumen: upload, sync, selesai.

Untuk AI, pendekatan itu terlalu santai.

Knowledge base adalah bagian dari runtime intelligence. Ia memengaruhi apa yang “diketahui” model pada saat menjawab. Kalau agent punya kemampuan bertindak, knowledge base juga dapat memengaruhi tindakan.

Artinya perubahan source, connector, permission, chunking, embedding model, ranking logic, dan ingestion policy layak masuk change management.

Tim content perlu tahu bahwa dokumen mereka bisa menjadi machine context.

Tim security perlu tahu bahwa dokumen adalah attack surface.

Tim AI perlu tahu bahwa retrieval score bukan trust.

Tim bisnis perlu tahu bahwa jawaban grounded tetap bisa salah kalau grounding source-nya salah.

RAG membuat AI lebih dekat ke data organisasi. Itu keunggulannya. Tetapi kedekatan itu juga membuka jalur serangan baru.

Pertanyaan penting bukan lagi hanya, “Apakah model hallucinate?”

Pertanyaan berikutnya adalah, “Siapa yang mengontrol apa yang model temukan sebelum ia menjawab?”

Karena ketika knowledge base menjadi bagian dari reasoning pipeline, kualitas dan keamanan knowledge base bukan pekerjaan dokumentasi belakang layar. Ia sudah menjadi bagian dari keamanan aplikasi AI itu sendiri.

Quality gate sebelum sebuah sumber masuk index

Untuk knowledge base yang memengaruhi keputusan penting, ada baiknya organisasi membuat admission control. Bukan semua dokumen harus melewati birokrasi berat, tetapi tier sumber perlu menentukan seberapa ketat gate-nya.

Policy resmi mungkin memerlukan owner, versi, tanggal berlaku, approval, dan expiry. Dokumentasi produk dapat meminta repository resmi dan maintainer yang jelas. Konten eksternal dapat masuk dengan label untrusted serta pembatasan use case. User-generated content mungkin disimpan di collection terpisah dan tidak diberi authority untuk menjawab pertanyaan kebijakan.

Gate juga bisa memeriksa perubahan yang tidak wajar. Misalnya satu dokumen baru berisi ratusan pengulangan keyword populer, banyak imperative sentence yang ditujukan ke “assistant”, atau link eksternal yang tidak relevan dengan domain knowledge. Itu belum membuktikan serangan, tetapi cukup menjadi alasan untuk review.

Hal penting lain adalah rollback. Kalau satu ingestion batch diketahui bermasalah, tim harus bisa mengetahui chunk apa saja yang berasal dari batch tersebut dan menghapus atau menonaktifkannya tanpa membangun ulang seluruh knowledge base secara buta.

Versioning, lineage, dan reversible ingestion terdengar seperti housekeeping. Dalam sistem RAG, semuanya adalah security capability.

Dan ketika organisasi memakai beberapa embedding model atau ranking layer, perubahan model juga perlu dievaluasi. Dokumen yang kemarin jarang ter-retrieve bisa besok muncul jauh lebih sering setelah perubahan embedding atau reranker. Jadi monitoring tidak berhenti pada konten. Retrieval behavior itu sendiri perlu dipantau sebagai bagian dari attack surface.

Satu prinsip operasional terakhir: jangan biarkan ingestion berjalan sebagai proses tanpa owner. Setiap collection penting perlu punya pihak yang bertanggung jawab atas source policy, kualitas, akses, dan deprecation. Kalau tidak ada owner, dokumen lama akan menumpuk, permission berubah tanpa pengawasan, dan investigasi insiden menjadi lambat. RAG yang sehat membutuhkan stewardship, bukan hanya storage. Semakin strategis keputusan yang dipengaruhi knowledge base, semakin jelas pula ownership yang dibutuhkan.