RAG Access Control: Keep Document Permissions Intact
A practical design and acceptance checklist for knowledge assistants that must respect tenant boundaries, document permissions, and revoked access.
A company knowledge assistant can answer accurately and still reveal a document the reader was never allowed to open. Retrieval augmented generation RAG supplies external material to a language model; if retrieval crosses a permission boundary, the answer can carry that material into a different audience. OWASP identifies unauthorized retrieval and cross context leakage as risks in vector based RAG systems. OWASP: Vector and Embedding Weaknesses https://genai.owasp.org/llmrisk/llm082025 vector and embedding weaknesses/ For a business buying an internal assistant, RAG access control should be an acceptance requirement. Ask the supplier to demonstrate which documents each user can retrieve, how quickly revoked access takes effect, and what happens to saved answers. A polished response with a valid citation does not answer those questions. The architecture below is our proposed design for an internal knowledge assistant. The examples and tests are hypothetical, not results from a client deployment. Apply permissions before documents enter the model context Consider a support assistant with access to product manuals and account specific implementation notes. In this hypothetical system, a support engineer may read one customer's notes but not another's. Both sets of notes contain the same product names, so relevance alone cannot decide which material belongs in the answer. We recommend a retrieval service that receives the authenticated user's identity, resolves the permitted account and document scope, and enforces that scope before passing text to a reranker or model. If permission resolution fails, stop the protected search. Do not fall back to searching the whole collection. This follows OWASP's recommendations to deny access by default and validate authorization on every request. OWASP also distinguishes authentication from authorization: signing in establishes identity but does not grant access to every resource. OWASP: Authorization Cheat Sheet https://cheatsheetseries.owasp.org/cheatsheets/Authorization Cheat Sheet.html Treat a model generated search query as search input. Build its authorization constraints separately in trusted application code. In the proposed support workflow, a query mentioning a different customer would never change the caller's permitted account scope. Separate tenant isolation from document permissions Tenant isolation limits retrieval to the correct organization or customer. Document permissions determine what a particular user may read within that boundary. Design both when one tenant contains teams with different access rights. Pinecone documents one namespace per tenant as a multitenancy pattern. Reads and writes target a namespace, allowing the application to direct a customer's operations to its own data. This is a concrete storage arrangement to evaluate, rather than a complete user authorization policy. Pinecone: Implement multitenancy https://docs.pinecone.io/guides/index data/implement multitenancy For our proposed assistant, the server would derive the namespace from the authenticated account membership. Within it, retrieval would enforce document access for the user and their groups. The browser would not supply an unrestricted namespace selector. Azure AI Search illustrates a different building block. Its security filter pattern stores user or group identifiers on documents and applies a matching filter to queries. Microsoft explicitly says those identifiers are strings used for filtering; the pattern itself does not authenticate or authorize the principal. The application must supply the correct identity context and apply the filter consistently. Microsoft: Security filters https://learn.microsoft.com/en us/azure/search/search security trimming for azure search When comparing implementations, ask who builds the query constraints and whether any alternate search, export, or document fetch route can omit them. A filter in the main chat endpoint leaves those other routes to be checked. Preserve source permissions through ingestion Before choosing a vector database, inventory the source systems. For each one, document how access is granted, where group membership lives, and how deletions and permission changes are reported. Use a small corpus with deliberately different access rules during the pilot. Our recommended ingestion record includes a source document ID, tenant ID, content version, permission reference or access list, and the time those permissions were last verified. Every derived chunk should retain enough information to resolve its source and access policy. Quarantine documents with missing or unrecognized permission metadata until an owner resolves them. For example, splitting a restricted implementation note into twelve chunks should not create twelve independently public records. Treat summaries and extracted tables as derived material with explicit access rules too. This is our application of OWASP's guidance to classify combined knowledge sources and enforce fine grained access in vector stores. OWASP: Vector and Embedding Weaknesses https://genai.owasp.org/llmrisk/llm082025 vector and embedding weaknesses/ Managed features deserve the same source by source review. As checked on September 14, 2026, Microsoft's document level access overview labels its built in identity based support as preview and describes source specific approaches. It also warns of a timing lag before changed access restrictions are recognized. Verify support for the exact connector, API version, and permission model in the proposed deployment. Microsoft: Document level access control https://learn.microsoft.com/en us/azure/search/search document level access overview Define what happens after access is revoked Ask for a measurable revocation requirement. “Permissions stay synchronized” is too vague to test. The project brief should name the maximum acceptable delay, the systems included, and the behavior while permission data is stale. For a sensitive corpus, we recommend checking current authorization again before releasing retrieved content. If the source cannot support that check, agree on a bounded synchronization window and a fail closed policy when freshness cannot be established. This is a design tradeoff to validate with the source system, not a guarantee provided by RAG. Apply the same reasoning to cached answers. In our proposed design, each cached response would retain references to its source documents and the authorization context used to generate it. Before reuse, verify that the current reader still has access to every contributing source. A question string alone would not be an acceptable cache key for protected answers. Revisit saved conversations as well. Decide whether the product will hide, regenerate, or otherwise restrict historical answers after access changes. Already downloaded information cannot be recalled by updating an index, so describe the policy's practical limits to the buyer. These recommendations extend request level authorization to the assistant's additional ways of returning content. OWASP: Authorization Cheat Sheet https://cheatsheetseries.owasp.org/cheatsheets/Authorization Cheat Sheet.html Test retrieval evidence as well as the final answer Use synthetic documents containing unique, harmless markers. Give different test users deliberately overlapping permissions. The following are proposed acceptance tests, not reported performance results. 1. Cross tenant search: Put a highly relevant marked document in another tenant. Verify that its text never reaches the reranker, model context, answer, or citation preview. 2. Restricted document: Give two users in the same tenant different document access. Repeat the same question and inspect the retrieved document IDs for each. 3. Revocation: Remove a user's access after a successful answer. Test fresh retrieval, cached responses, saved conversations, and citation links against the agreed revocation deadline. 4. Missing metadata: Ingest a document without a usable permission record. Verify that the protected retrieval path excludes it and records a diagnosable reason. 5. Alternate route: Request a document directly by a known ID. Confirm that the fetch endpoint applies authorization independently of the chat search. 6. Dependency failure: Interrupt permission lookup. Verify that the assistant reports it cannot access the necessary material instead of broadening the search. Keep test evidence focused on document IDs, policy decisions, and component boundaries. Use protected test fixtures when inspecting model inputs; avoid copying confidential production passages into routine debugging logs. OWASP recommends retrieval monitoring, and its authorization guidance calls for unit and integration tests. OWASP: Vector and Embedding Weaknesses https://genai.owasp.org/llmrisk/llm082025 vector and embedding weaknesses/ OWASP: Authorization Cheat Sheet https://cheatsheetseries.owasp.org/cheatsheets/Authorization Cheat Sheet.html If you are planning a knowledge assistant, bring one source system, two representative user roles, and your required revocation window to a project discussion with Singularity Forge https://singularityforge.ai/ contact . We can scope a retrieval prototype around that permission model and define the evidence needed before expanding its document access.