Agent AI bisa menemukan dokumen, tetapi belum tentu boleh membacanya

Seorang staf penjualan meminta agent AI merangkum riwayat kerja sama pelanggan. Jawabannya rapi, lengkap dengan kutipan dokumen. Masalahnya, salah satu kutipan berasal dari catatan negosiasi yang hanya boleh dibaca pemilik usaha. Sistem menemukan informasi yang relevan, lalu memberikannya kepada orang yang tidak berhak.

Contoh itu hipotetis, tetapi persoalan desainnya konkret. Ketika perusahaan menghubungkan AI dengan arsip bersama, kualitas pencarian dan hak membaca harus diperiksa terpisah. Jawaban yang akurat tetap bisa menjadi kebocoran data.

RAG, atau retrieval-augmented generation, mengambil informasi dari sumber lain untuk membantu model menyusun jawaban. Dalam aplikasi bisnis, sumber itu bisa berupa panduan layanan, kontrak, atau catatan pelanggan. Menurut saya, batas awalnya sederhana: agent hanya boleh menerima dokumen yang memang boleh dibaca pengguna untuk pekerjaan tersebut. Menuliskan larangan membocorkan rahasia di prompt saja tidak cukup.

Periksa izin sebelum dokumen masuk ke konteks

Bayangkan usaha jasa dengan dua perusahaan pelanggan. Masing-masing memiliki kontrak, daftar harga khusus, dan catatan dukungan. Keduanya mungkin memakai istilah produk yang sama. Mesin pencari berbasis kemiripan dapat menganggap dokumen pelanggan lain sangat relevan, meskipun dokumen itu tidak boleh digunakan.

Karena itu, alur yang saya sarankan adalah memverifikasi pengguna, menentukan ruang data yang boleh diakses, lalu melakukan pencarian dengan pembatasan tersebut. Hanya hasil yang lolos pemeriksaan izin yang diteruskan ke model. Jika mesin pencari menghasilkan kandidat lebih dulu, lapisan aplikasi tetap harus menyaringnya sebelum konten dikirim ke model atau komponen lain yang tidak berwenang.

Mengambil seluruh dokumen lalu meminta model mengabaikan bagian rahasia menempatkan kontrol pada tahap yang terlambat. Informasi itu sudah masuk ke konteks pemrosesan. Menyembunyikan kutipan dari tampilan akhir juga tidak membatalkan akses yang telanjur terjadi.

Identitas pengguna tidak berasal dari kalimat percakapan

Pernyataan “saya pemilik perusahaan” di kolom chat bukan bukti identitas. Aplikasi perlu mengambil identitas dari sesi yang telah diautentikasi dan membaca hak akses dari sumber yang dipercaya. Permintaan pengguna boleh menjelaskan kebutuhan, tetapi tidak boleh menentukan sendiri keanggotaan grup atau perusahaan yang dibukakan aksesnya.

Dokumentasi Microsoft tentang security trimming di Azure AI Search memberi batas yang berguna. Pola filter keamanan menggunakan identitas berupa string untuk menyertakan atau mengecualikan dokumen. String tersebut sendiri bukan mekanisme autentikasi atau otorisasi. Aplikasi harus memastikan identitas dan daftar hak yang dipakai filter memang benar.

Implikasinya, jangan menyerahkan penyusunan batas akses sepenuhnya kepada model. Backend sebaiknya menambahkan pembatas wajib dari identitas terverifikasi, terlepas dari pertanyaan yang disusun agent. Jika identitas atau ruang akses tidak tersedia, hentikan pencarian sensitif dan minta pengguna masuk melalui alur resmi, bukan memperluas pencarian agar jawaban tetap muncul.

Potongan dokumen harus membawa izin yang sama

Banyak sistem memecah dokumen panjang menjadi potongan kecil agar pencarian lebih tepat. Pembatasan di tingkat berkas mudah hilang jika proses pemecahan hanya menyimpan teks dan representasi pencariannya.

Setiap potongan perlu membawa informasi yang cukup untuk memeriksa hak aksesnya: asal dokumen, ruang pelanggan, dan aturan pembaca yang berlaku. Judul, ringkasan otomatis, serta lampiran juga perlu diperhatikan. Judul seperti “Rencana diskon khusus pelanggan” bisa mengungkap informasi meskipun isi berkas disembunyikan.

Sebagai rekomendasi desain, tetapkan perlakuan yang aman ketika metadata izin tidak lengkap. Dokumen tanpa informasi hak baca jangan otomatis dianggap terbuka. Sediakan tempat pemeriksaan terpisah agar staf dapat memperbaiki metadata tanpa membiarkan agent memakainya lebih dulu.

Jangan mengartikan opsi untuk tidak menampilkan sebuah field sebagai perlindungan seluruh dokumen. Dokumentasi Microsoft menegaskan bahwa pengaturan field agar tidak dikembalikan dalam hasil bukan mekanisme keamanan tingkat field; pola yang dijelaskan tetap memerlukan filter keamanan pada setiap kueri.

Kontrol database membantu, dengan batas yang perlu dipahami

Untuk data terstruktur, pembatasan dapat ditempatkan lebih dekat ke penyimpanan. PostgreSQL mendukung row-level security untuk membatasi baris yang dapat dibaca atau diubah melalui kebijakan. Dokumentasinya menjelaskan bahwa ketika row security diaktifkan tetapi tidak ada kebijakan yang mengizinkan, akses normal menggunakan prinsip default-deny.

Namun, memasang kebijakan belum membuktikan semua jalur aplikasi terlindungi. Superuser dan role dengan atribut BYPASSRLS melewati mekanisme tersebut. Pemilik tabel biasanya juga melewatinya, kecuali diberi pengaturan yang sesuai. Karena itu, pengujian perlu memakai role yang benar-benar digunakan aplikasi, bukan hanya akun administrator saat menyiapkan contoh.

Batas lainnya: kebijakan di database asal tidak otomatis ikut melindungi salinan teks yang sudah dipindahkan ke indeks pencarian terpisah. Tim perlu memeriksa izin di jalur pengindeksan dan pengambilan dokumen juga. Pilih kontrol sesuai tempat data dibaca; jangan menganggap satu fitur database menutup seluruh perjalanan informasi.

Hak akses berubah setelah dokumen diindeks

Seorang staf bisa berpindah divisi. Kontrak bisa menjadi lebih terbatas. Pelanggan bisa meminta akun tertentu ditutup. Indeks yang hanya menyalin izin saat unggahan pertama akan tertinggal dari perubahan tersebut.

Sebelum mengaktifkan pencarian, tentukan cara memperbarui izin serta batas keterlambatan yang diterima. Untuk dokumen yang sangat sensitif, pertimbangkan pemeriksaan tambahan terhadap sumber otorisasi yang mutakhir sebelum mengirim isinya ke model. Ini rekomendasi arsitektur, bukan jaminan bawaan setiap produk RAG.

Cache dan riwayat percakapan juga termasuk ruang pemeriksaan. Jawaban yang pernah dibuat untuk pemilik tidak boleh diberikan kepada staf hanya karena pertanyaannya sama. Pemisahan cache perlu mempertimbangkan ruang akses, bukan teks pertanyaan saja. Saat izin dicabut, tentukan pula perlakuan terhadap hasil tersimpan dan percakapan yang masih aktif. Pembaruan indeks saja belum menyelesaikan semuanya.

Uji akses yang ditolak, bukan hanya jawaban yang berhasil

Mulailah dengan dokumen sintetis untuk dua pelanggan rekaan dan beberapa peran staf. Beri setiap dokumen frasa penanda yang berbeda. Cara ini membantu tim melihat apakah konten terlarang masuk ke hasil pencarian, konteks model, atau jawaban akhir tanpa menggunakan data pelanggan sebenarnya.

Kasus pengujian sebaiknya mencakup:

• Pengguna sah meminta dokumen milik pelanggan lain, termasuk dengan menyebut judul persisnya.
• Pengguna menulis bahwa ia administrator atau meminta agent menghapus pembatas pencarian.
• Dokumen baru masuk tanpa metadata izin, atau potongannya kehilangan informasi pelanggan.
• Hak pengguna dicabut setelah pencarian sebelumnya tersimpan di cache.
• Alat pencarian gagal menentukan izin dan harus menolak, bukan menjalankan pencarian terbuka.

Nilai hasil di beberapa titik, bukan hanya pada kalimat jawaban. Agent mungkin tidak mengutip dokumen terlarang, tetapi isi dokumen sudah telanjur dikirim ke model. Catatan pengujian perlu menunjukkan hasil retrieval dan konteks yang diteruskan, dengan perlindungan akses untuk catatan itu sendiri.

Untuk usaha kecil, cakupan awal bisa dibatasi pada panduan layanan yang memang boleh dibaca seluruh staf. Tambahkan kontrak dan arsip pelanggan setelah pemisahan akses terbukti berjalan. Lebih baik staf mendapat penjelasan bahwa dokumen belum tersedia baginya daripada menerima jawaban lengkap dari arsip orang lain.

Sumber

• Microsoft Learn: Security filters for trimming results in Azure AI Search, untuk pola filter dokumen, batas identitas string, dan kewajiban menerapkan filter pada kueri.
• PostgreSQL 18: Row Security Policies, untuk kebijakan tingkat baris, default-deny, serta pengecualian role dan pemilik tabel.

Contoh usaha, urutan implementasi, dan skenario pengujian dalam artikel ini merupakan rekomendasi desain, bukan laporan penerapan pada suatu perusahaan.