Permission-aware RAG runs retrieval as the requesting user: a document that user cannot open in the source system is never retrieved, so the model never sees it and cannot leak it. Without it, an assistant that answers from everything it has indexed will eventually hand someone a document they were never allowed to read, phrased helpfully and with a citation.
The demo version of retrieval-augmented generation has one user and one corpus. Index the documents, embed the question, retrieve the nearest chunks, generate an answer. It works, and it assumes something false about every real organisation: that everyone may read everything. In a real company the board papers are in the corpus because someone synced the wrong folder, and the salary review is findable because semantic search does not care which SharePoint site a document came from.
The instinct is to fix this at the generation end, with instructions telling the model what not to reveal. This cannot work. If the restricted content is in the context window, it is available to the answer, and models follow instructions imperfectly under exactly the adversarial pressure that matters. A user who asks nicely enough, oddly enough, or in Base64 will eventually get what the context contains. The control has to sit in the retriever.
Role-aware retrieval carries source-system permissions through the whole pipeline. At indexing time, every chunk keeps the access control metadata of its parent document: who can read it, from which groups, under which classification. At query time, the user's identity resolves to their groups and the vector search runs with a permission filter, so the candidate set is trimmed before ranking.
Two failure modes need engineering attention. Staleness: when a document's permissions change in the source, the index has to hear about it, which argues for event-driven re-indexing over a nightly sweep. Aggregation: a user with legitimate access to many narrow documents can sometimes ask a question whose answer assembles into something above their clearance. That one has no purely technical fix. It is handled with scoped assistants per audience, and audit logs that make the questions visible.
Every production system we build logs who asked, what was retrieved, what was answered, and under which permissions at the time. When compliance asks how you know the assistant keeps restricted content private, you can hand over a report.
The same logging feeds the evaluation harness, where refusal behaviour is tested alongside accuracy: a permission-filtered test set where the right answer for an unauthorised user is a clean refusal, run before every release.
Permissions are usually framed as a constraint, but they are also why the assistant can be trusted with the useful data. Systems that skip permissions get fed sanitised, public corpora, and their answers stay shallow. Systems built with permissions from the start get connected to the documents that matter, because the security team signed off. Ours run that way in production, including in financial services. For the rest of the retrieval layer, see why AI projects fail on retrieval.
Not reliably. If restricted content is in the context window, a determined user can usually get it out, so the filtering has to happen before the model sees anything.
From the source systems, such as SharePoint. Each chunk inherits the access control metadata of its parent document when it is indexed.
Yes. Group membership from the user's identity is matched against the access metadata stored with each chunk. Our AI, data and analytics practice builds this into the pipeline from the start.
Duke Le works in Coder Trove's AI, data and analytics practice.