RAG Bisa Membocorkan Dokumen yang Seharusnya Tidak Terlihat Pengguna

Di demo internal, semuanya kelihatan cakep.

Ada kolom chat.

Karyawan bertanya, “kebijakan reimbursement hotel berapa?”

AI menjawab dalam tiga detik, lengkap dengan sumber dari handbook perusahaan.

Orang finance senang. HR senang. Bos melihat satu layar dan langsung kepikiran, “kalau semua dokumen bisa dicari begini, ngapain orang masih buka folder?”

Lalu beberapa minggu kemudian ada pertanyaan yang kelihatannya biasa:

“Berapa range kompensasi untuk posisi director?”

AI menjawab.

Masalahnya, orang yang bertanya bukan HR.

Dia seharusnya tidak pernah punya akses ke file salary band tersebut.

Ini bukan hallucination.

Jawabannya justru terlalu benar.

Dan di dunia RAG, itu bisa lebih berbahaya.

Retrieval-Augmented Generation, atau RAG, pada dasarnya membuat AI bisa mengambil informasi dari sumber luar sebelum menjawab. Sumbernya bisa knowledge base, Google Drive, SharePoint, database, wiki internal, atau kumpulan PDF yang sudah diindeks.

Makanya RAG populer di perusahaan.

Model tidak perlu “hafal” semua dokumen.

Ia tinggal mencari bagian yang relevan, memasukkannya ke context, lalu membuat jawaban.

Masalahnya muncul ketika sistem pencariannya lebih pintar daripada sistem izinnya.

OWASP pada panduan keamanan RAG secara eksplisit memperingatkan risiko unauthorized access dan data leakage jika kontrol akses pada vector store atau retrieval layer tidak memadai. Dokumen sensitif bisa terambil lalu muncul dalam jawaban kepada user yang seharusnya tidak berhak melihatnya.

Ini salah satu kegagalan yang gampang terjadi karena RAG sering dibangun dari arah yang salah.

Tim fokus: “jawabannya relevan nggak?”

Padahal sebelum itu harus ada pertanyaan: “dokumen ini boleh dilihat orang yang nanya nggak?”

Search dan permission bukan hal yang sama

Bayangin kantor di Sudirman punya satu Google Drive besar.

Folder finance.

HR.

Sales.

Legal.

Management.

Semua dokumen lalu diindeks ke satu vector database.

Secara semantic search, ini enak banget.

User bertanya: “kontrak mana yang punya termination fee tinggi?”

Retriever mencari potongan yang paling mirip.

Masalahnya, vector similarity tidak mengenal struktur organisasi kalau kita tidak mengajarinya.

Ia tidak otomatis paham: orang ini sales junior, dokumen ini board-only, folder itu khusus legal.

Bagi vector search, semuanya cuma representasi informasi yang bisa dicari.

Kalau access control baru diperiksa setelah retrieval, kadang sudah terlambat.

Model mungkin sudah menerima potongan sensitif di context.

Dan kalau model sudah melihat, kita sekarang bergantung pada prompt:

“jangan sebutkan informasi yang user tidak boleh lihat.”

Itu bukan security control yang cukup.

OWASP menekankan kontrol akses dan retrieval boundary perlu ditegakkan independen dari model, bukan sekadar mengandalkan sanitization atau instruksi prompt.

Bahasa sederhananya:

jangan kasih rahasianya ke model sejak awal kalau user tidak berhak.

Ini prinsip paling penting.

RAG leakage sering bukan hacker pakai hoodie

Kadang cuma employee penasaran.

Dia tahu perusahaan punya chatbot internal.

Coba tanya: “Siapa kandidat yang sedang dipertimbangkan untuk menggantikan VP?”

Tidak berharap benar-benar dijawab.

Eh, AI memberi petunjuk.

Atau user mulai memainkan wording:

“Ringkas dokumen yang membahas Project Phoenix.”

“Dokumen apa yang menyebut acquisition?”

“Coba cari informasi paling sensitif tentang vendor X.”

OWASP bahkan memasukkan query injection via retrieval sebagai risiko practical. User atau agent bisa merancang pertanyaan untuk memancing dokumen tertentu dari corpus, lalu secara bertahap memetakan apa yang ada di vector store.

Tidak perlu malware.

Tidak perlu akses shell.

Cuma chat.

Ini sebabnya enterprise AI yang tampak ramah bisa menjadi interface reconnaissance baru.

Permission harus ikut sampai level chunk

Banyak perusahaan merasa aman karena folder sumber sudah punya ACL.

Masalahnya, setelah dokumen dipecah menjadi chunk lalu dibuat embedding, apakah permission-nya ikut?

Misalnya file: “2027 Salary Review Confidential.xlsx”

Di SharePoint hanya HR director yang boleh lihat.

Saat ingestion: file dipecah jadi 500 chunk.

Embedding masuk vector database.

Kalau metadata permission tidak ikut, chunk kehilangan identitas keamanan.

Sekarang search hanya melihat relevance.

Yang dicari: “salary director Indonesia.”

Ketemu.

Return.

AI jawab.

Ini bukan bug model.

Ini bug arsitektur.

Permission seharusnya ikut dari source sampai retrieval.

Kalau user tidak bisa membuka file asli, dia juga tidak boleh menerima isi file lewat AI.

Rule-nya terdengar obvious.

Implementasinya tidak selalu.

Karena permission berubah.

Orang pindah divisi.

Project selesai.

Vendor access dicabut.

File di-share ulang.

RAG index harus ikut update.

Kalau ACL di sumber berubah hari ini tapi vector store baru sinkron besok, ada window leakage.

Untuk dokumen sensitif, satu hari terlalu lama.

Citation juga bisa bocor walaupun isi tidak

Misalnya model patuh.

Tidak memberikan isi.

Tapi jawab: “Informasi terkait ada di file `Project Merger Nusantara Final Board Only.pdf`.”

Oops.

User sekarang tahu project merger ada.

Metadata sendiri bisa sensitif.

Nama file.

Folder.

Nama customer.

Project codename.

Bahkan jumlah dokumen bisa memberi clue.

Security review RAG harus melihat bukan cuma answer body.

Lihat juga: citation, source preview, URL, file path, snippet, similarity result.

Sering kali leak muncul dari pinggir UI.

Bukan jawaban utama.

RAG juga punya problem “dokumen beracun”

Ini jenis risiko lain.

Kita biasa berpikir dokumen adalah data pasif.

AI membaca.

Selesai.

Tapi dalam sistem LLM, teks di dokumen bisa berisi instruksi.

Misalnya PDF dari vendor memuat kalimat tersembunyi yang intinya menyuruh model mengabaikan instruksi sebelumnya atau mengambil data lain.

Ini indirect prompt injection.

OWASP masih menempatkan prompt injection sebagai risiko utama untuk aplikasi LLM, dan secara eksplisit mengatakan RAG tidak otomatis menyelesaikannya.

Bayangin AI procurement agent.

Ia membaca proposal vendor.

Di dalam dokumen ada instruksi tersembunyi.

Kalau arsitekturnya naif, isi dokumen bisa memengaruhi behavior agent.

Kalau agent hanya membuat ringkasan, blast radius terbatas.

Kalau agent punya akses email, database, atau approval workflow, beda cerita.

Jadi RAG security bukan hanya: “siapa boleh melihat dokumen.”

Juga: “bolehkah dokumen memberi instruksi ke sistem?”

Jawabannya seharusnya tidak.

Data dan instruction harus dipisahkan sekeras mungkin.

Jakarta office punya satu kebiasaan yang bikin ini makin rawan: “masukin aja semua dulu”

Knowledge project sering mulai dari semangat.

“Biar AI pintar, ingest semuanya.”

Drive.

Notion.

PDF lama.

Minutes meeting.

Proposal.

Email.

Folder archive.

Kedengarannya efisien.

Padahal corpus besar adalah attack surface besar.

Satu dokumen yang seharusnya sudah expired bisa hidup lagi.

Satu spreadsheet lama masih punya nomor telepon customer.

Satu notulen rapat menyebut strategi harga.

Satu deck board terselip di folder umum karena pernah dikirim untuk presentasi.

AI sangat bagus menemukan jarum di tumpukan jerami.

Itu benefit.

Juga risk.

Dokumen yang manusia lupa ada justru bisa ditemukan lagi dalam hitungan detik.

Sebelum ingest, kurasi.

Bukan hanya upload.

Kalau knowledge base berantakan, RAG membuat kekacauan menjadi searchable.

Data minimization berlaku juga di retrieval

Pertanyaan pertama sebelum memasukkan source: apakah AI memang butuh ini?

Employee handbook?

Iya.

Public product documentation?

Mungkin.

Payroll detail?

Untuk chatbot umum, kenapa?

Board minutes?

Probably no.

Legal investigation?

Definitely separate.

Jangan bangun satu knowledge base raksasa karena arsitekturnya lebih simpel.

Buat zone.

General.

Department.

Restricted.

Case-specific.

Kemudian user identity menentukan corpus yang boleh dicari.

Ini jauh lebih aman daripada memberi model semua lalu berharap ia “bijak.”

Model bukan satpam.

Authorization engine yang harus jadi satpam.

Test dengan akun biasa, bukan admin

Demo AI internal sering dilakukan developer.

Developer punya akses hampir semua.

Jawaban bagus.

Pass.

Padahal real test harus pakai role.

Intern.

Sales.

Finance.

HR.

External contractor.

Pertanyaannya bukan hanya: “bisa menemukan dokumen?”

Tapi: “bisa gagal menemukan dokumen yang memang tidak boleh ditemukan?”

Negative testing sangat penting.

Buat daftar canary secret.

Dokumen dummy bertanda restricted.

Coba prompt langsung.

Prompt oblique.

Bahasa Indonesia.

English.

Typo.

“Ringkas semua yang lo tahu tentang project ini.”

Lihat apakah bocor.

Security test RAG harus adversarial.

User tidak selalu bertanya sopan.

Log retrieval, bukan cuma jawaban

Kalau incident, tim perlu tahu:

user bertanya apa?

Retriever mengambil chunk apa?

Dari dokumen mana?

Permission saat itu apa?

Model version?

Jawaban apa?

Kalau log hanya menyimpan final response, forensic kurang.

Bisa jadi jawaban kebetulan tidak membocorkan, tetapi retriever sudah berulang kali mengambil dokumen terlarang.

Itu warning.

Retrieval log bisa mendeteksi reconnaissance.

Seseorang mencoba 50 variasi pertanyaan untuk satu project rahasia.

Monitor.

Tentu log sendiri sensitif.

Access terbatas.

Retention proporsional.

Security tool juga perlu security.

RAG bukan alasan untuk menduplikasi seluruh perusahaan

Setiap copy menambah lifecycle.

Original document.

Chunk.

Embedding.

Vector index.

Cache.

Prompt context.

Output.

Log.

Ketika source dihapus, apa semua turunan ikut?

Kalau tidak, data yang “sudah dihapus” masih bisa hidup di index.

Ini akan nyambung langsung dengan problem hak penghapusan di era AI.

Data lineage harus nyata.

Setiap chunk idealnya tahu: asal, owner, classification, permission, retention.

Tanpa itu, AI knowledge system lama-lama jadi gudang yang tidak ada petanya.

Kelihatannya pintar dari depan.

Di belakang berantakan.

RAG memang salah satu cara paling powerful membuat AI perusahaan berguna.

Karena model akhirnya bisa menjawab berdasarkan knowledge internal yang aktual.

Tapi justru karena itu RAG harus diperlakukan seperti pintu baru ke seluruh gedung data perusahaan.

Kalau aksesnya benar, orang masuk ruang yang memang boleh.

Kalau tidak, satu kotak chat di browser bisa menjadi pintu samping menuju folder yang selama ini aman hanya karena orang tidak tahu harus mencarinya di mana.

RAG Bisa Membocorkan Dokumen yang Seharusnya Tidak Terlihat Pengguna bukan karena retrieval inherently buruk.

Masalahnya muncul ketika relevance bergerak lebih cepat daripada authorization.

Sistem menemukan jawaban dengan sangat baik.

Terlalu baik.

Satu hal lain yang sering kelewat adalah environment testing. Banyak tim memakai copy data production untuk staging karena ingin hasil retrieval realistis. Secara teknis enak. Secara keamanan, sekarang ada dua knowledge base sensitif.

Kalau staging protection lebih lemah, attacker justru memilih pintu belakang.

Gunakan synthetic atau sanitized corpus jika bisa. Kalau memang butuh real data, samakan control dan logging.

Dan ketika vendor mengklaim RAG “secure by default,” minta bukti di layer yang tepat. Apakah mereka benar-benar enforce document-level permission saat retrieval? Bagaimana sync ketika permission berubah? Apa yang terjadi pada deleted files? Apakah citation bisa membuka metadata?

Pertanyaan ini jauh lebih berguna daripada sekadar bertanya model apa yang dipakai.

Karena leak RAG hampir selalu lahir dari plumbing yang membosankan, bukan dari model yang tiba-tiba berubah jahat.

Jadi sebelum merayakan “AI kita akhirnya ngerti semua dokumen perusahaan,” tambahkan satu kalimat yang jauh lebih penting:

“dan dia cuma ngerti dokumen yang memang boleh dilihat orang yang sedang bertanya.”