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, it impresses, and it quietly assumes something false about every real organisation: that everyone is allowed to read everything.
Put that system in front of a company and the assumption fails on day one. The board papers are in the corpus because someone synced the wrong folder. The salary review is findable because semantic search does not care which SharePoint site a document came from. An assistant that answers from everything it has indexed will eventually hand someone a document they were never allowed to open, phrased helpfully and with a citation.
The instinct is to fix this at the generation end, with instructions telling the model what not to reveal. This does not work and 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 fix belongs where the data is selected, not where the answer is written. Retrieval runs as the requesting user, and a document the user cannot open in the source system is a document the retriever never returns. The model cannot leak what it never sees.
In practice, role-aware retrieval means carrying 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 pre-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 rather than a nightly sweep. And 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 question-asking visible.
Every production system we build logs the tuple that matters: who asked, what was retrieved, what was answered, and under which permissions at the time. This is what turns an uncomfortable compliance conversation into a short one. When someone asks how you know the assistant is not leaking, the answer is a report, not a reassurance.
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.
Role-aware retrieval is usually framed as a constraint, but it is also why the assistant can be trusted with the good data. The systems that skip permissions get fed sanitised, public corpora, and their answers have the depth of a brochure. The systems built with permissions from the start get connected to the documents that actually matter, because the security team signed off. Ours run that way in production, including in financial services, where the alternative was never on the table.
Duke Le works in Coder Trove's AI, data and analytics practice.