Permission-aware RAG: stop enterprise search from answering across boundaries

An employee asks how a customer exception was handled last year. The assistant gives a precise answer and cites a document. The problem is that the document belongs to a different customer whose commercial terms the employee is not allowed to see.

The answer may be factually correct and still be a serious integration failure. Retrieval-augmented generation, usually shortened to RAG, does not make a knowledge system safe simply by supplying sources.

Permission-aware RAG means checking which documents the requester may use before their content reaches the model. It also means preserving those boundaries in summaries, caches, citations and deletion workflows. Search relevance comes after eligibility.

Start with the source of authority

Identify where document permissions actually live. A file share, CRM, portal and collaboration platform may use different groups and inheritance rules. The retrieval system needs a dependable mapping from the authenticated requester to those rules.

Do not create a second, informal permission system by assigning broad labels during ingestion and never updating them. If access is revoked at the source, the knowledge assistant must stop treating the old grant as current.

For a customer-facing portal, bind the tenant to the authenticated session on the server. Do not let the user or model choose a tenant filter as an ordinary query parameter.

A relevant result is not an eligible result

Search ranking asks which document best matches the question. Authorization asks whether the document may be used at all. Applying an access check only after a generated answer is produced is too late: the model has already received the restricted content.

The retrieval layer should limit the candidate set to authorized material. The implementation can vary, but the boundary must hold before generation and before any intermediate summarization exposed to the model.

Understand the security-filter pattern

Microsoft documents a security-filter pattern for Azure AI Search in which document fields and query filters help restrict results to authorized identities. It is an implementation pattern rather than a replacement for reliable identity and application authorization.

The same design lesson applies beyond that product: store the metadata needed to evaluate access and construct filters from trusted application context. Verify the behaviour of the actual search technology and query mode you deploy.

A vector database that supports metadata filters still needs a correct policy model. If the permission metadata is wrong or stale, a perfectly functioning filter can enforce the wrong decision.

Preserve permissions when documents become chunks

RAG systems often divide documents into smaller passages. Every passage must retain the source identity, version and relevant access metadata. A paragraph separated from its parent document does not become public.

Be careful with generated summaries that combine several sources. If a summary incorporates restricted information, its permissions cannot be broader than the information it contains. A simple default is to avoid mixing access domains in one reusable summary.

Attachments deserve explicit treatment. A broadly visible ticket may contain a restricted attachment or a quoted excerpt from another system. Ingestion should not assume that every piece of content inherits the parent record's visibility.

The table is a proposed engineering checklist. The exact fields depend on the source systems and identity model.

Freshness includes permissions as well as text

Teams often measure how quickly new documents enter the index. They should also measure how quickly deleted documents, changed permissions and corrected content stop being used.

Define separate freshness objectives for content updates and access revocation. A stale product manual may cause a wrong answer. A stale access grant may disclose information. Those failures need different handling and escalation.

Where the source cannot provide timely permission updates, consider checking authorization again at retrieval time. If the check is unavailable, a sensitive workflow may need to refuse the answer or use a smaller collection whose permissions can be verified.

Do not disguise an unavailable check as an empty collection

Tell the user when the system cannot verify access. “No matching information exists” is a different statement and may cause a person to make an incorrect business decision.

Keep the explanation proportionate. The assistant can say it could not confirm access to the necessary material without revealing the title or existence of a restricted document.

Citation access is part of answer quality

An answer should cite sources the requester is permitted to open. A citation that points to a restricted document can leak metadata even if the answer itself appears harmless.

Preserve stable source references and revision information. If a policy changed after the answer was produced, the reviewer needs to know which version supported the earlier answer.

Check whether the cited passage actually supports the claim. A source can be authorized and current but irrelevant. Permission-aware retrieval addresses confidentiality; evidence checks address whether the answer follows from the retrieved material.

These controls complement each other. Neither can stand in for the other.

Design answer caching around the boundary

A cache keyed only by the question can return another user's answer. Include the relevant authorization scope and source version information, or restrict caching to material that is genuinely shared across the permitted audience.

Cache invalidation must respond to permission changes and source deletion, not only elapsed time. If a confidential document is withdrawn, waiting for a convenient cache expiry may leave its answer available.

Avoid placing full prompts or generated answers in broadly accessible infrastructure logs. A carefully restricted retrieval service can still leak through a less restricted observability tool.

Test with users who should get different answers

A useful test set includes the same question asked by different identities. One employee can access the source; another cannot. A customer administrator may see more than an ordinary user in the same tenant.

Also test a person whose access changed recently. Query before revocation, revoke access and query again. Check the search results, generated answer, cache and citation target.

Include documents with similar titles across tenants. A relevant-looking title is not a reliable identity. Use stable source IDs and tenant context to prevent accidental cross-customer matching.

Evaluate denial without teaching the system secrets

The expected response for an unauthorized user should not reveal the restricted answer in the explanation. Do not use a verbose refusal that repeats the confidential document title or summarizes the information being withheld.

A practical evaluator can compare the result with an allowed response policy and inspect whether restricted markers appear. It should also verify that the retrieval service did not send restricted passages to the model, even if the final answer happened to omit them.

A hypothetical knowledge portal

Imagine a service provider maintaining general troubleshooting guidance and customer-specific operating procedures. General guidance is available to the service team. Customer procedures are limited to the staff assigned to that account.

The first release indexes only the general collection. This establishes search quality and the citation workflow without introducing customer boundaries.

The next release adds one customer collection with explicit identity mapping and a revocation test. The application filters retrieval before generation and records the source versions used in each reviewed answer.

A manager then requests cross-customer trend analysis. That is a new use case, not an automatic extension of the assistant's access. It may require aggregated data prepared through a separate approved process rather than unrestricted retrieval across all documents.

Choose the technology after the policy

A modest collection may work with an existing search service and a relational permissions table. A larger collection may justify a dedicated retrieval platform. The required access checks and update behaviour should drive the choice.

Ask vendors how filters interact with their retrieval modes, how metadata updates propagate and how deleted records are removed from indexes and backups. Demonstrate those behaviours with your documents instead of accepting a generic “enterprise security” label.

Consider the operating cost of rebuilding indexes and refreshing derived content. An inexpensive query service can still be costly if permission synchronization requires manual repair.

Assign owners to the parts that go stale

The knowledge owner maintains the source content. The identity owner maintains group membership and access policy. The application owner maintains retrieval, generation and caching. Those responsibilities need a shared incident path.

When the assistant gives a wrong answer, classify the cause. It may be a stale policy, an incomplete source, an authorization defect, a retrieval miss or an unsupported inference. Sending every issue to the model team makes the system harder to improve.

Set a review process for obsolete sources. Adding more documents can reduce quality when the collection contains several conflicting versions and no reliable indication of which one governs current work.

Work through a document-access change

Imagine a project folder that initially belongs to two departments. A search assistant indexes its documents and answers questions with citations. Later, one department loses access. The important test is whether a member of that department can still retrieve the content through the assistant, an earlier conversation or a cached answer.

Handle the access change as a lifecycle event. Determine how the source system signals it, when the index updates and which cached results need invalidation. A permission field copied during initial ingestion becomes stale unless something maintains it. Where immediate synchronization is unavailable, define a conservative response for content whose permission state cannot be established.

Test more than the search results page. A generated answer may contain a sentence derived from a document even when the citation is hidden. Prevent unauthorized material from reaching the answer-generation stage in the first place. Removing a link after generation cannot reliably remove the information the model has already incorporated.

Keep the evidence understandable

Authorized readers should be able to open the source behind an answer. Store enough document identity and version information to resolve the citation without exposing internal storage paths. When a document is replaced, decide whether an old conversation should link to its historical version, show that the source changed or require a new search.

These choices affect trust. A procurement employee checking an approval policy needs to know whether the answer came from the current policy or an archived draft. Document status, ownership and effective dates can be as important as semantic similarity. Agree which source attributes are required before importing a large collection.

For disputed answers, give the reviewer a compact evidence package: the question, authorized source references, relevant passages and the application configuration version. Avoid copying entire confidential documents into an unrestricted support ticket. The review process should preserve the same access discipline as the search experience.

Define the first search collection carefully

A first collection should have a clear owner, a manageable permission model and a recurring business question. A maintained service handbook is often easier to evaluate than an uncurated shared drive containing years of duplicated attachments. Choosing a narrow collection makes defects visible; it does not prevent later expansion.

Ask the collection owner to supply questions that should have answers, questions whose answers conflict and questions the collection cannot answer. Include examples from employees with different access levels. Record acceptable evidence for each question before testing the assistant.

The resulting acceptance set is useful beyond launch. Run it when ingestion rules, permissions, embedding choices or generation models change. A change that improves general answer quality can still break access filtering or citation fidelity.

For a project estimate, provide the source systems, approximate document types, identity provider and examples of restricted collections. KYCONNECTS can use those boundaries to discuss an integration scope grounded in access control and answer quality rather than an arbitrary chatbot feature list.

Questions about secure RAG

A useful assistant should be able to say less

The right answer sometimes contains only the information the requester is entitled to use. That limitation is a feature of a trustworthy enterprise knowledge system.

Begin with a collection whose ownership and permissions are clear. Expand only after the team can demonstrate accurate retrieval, reliable revocation and evidence that remains available to the intended reader.