RAG permissions: security trimming, ACLs & secure retrieval

Authorization belongs in the retrieval path. Only evidence the current user is allowed to see may enter the model context at all.

A RAG system is not secure merely because the LLM is instructed not to disclose confidential material. Unauthorized evidence must never reach the model. That makes security trimming neither a UI rule nor a prompting concern; it is an architectural boundary between a query and context assembly.

The leak happens before the answer

Consider an existing business application connected to SharePoint, a DMS and an internal wiki. Documents are available to project groups, departments and individual people, with some explicit exceptions.

User A may access the internal document “Project Phoenix Budget”. User B is neither in the project group nor individually authorized. Both ask: “What is the Project Phoenix budget?”

If semantic search finds that document for user B and places it in the prompt, the security boundary has already failed — even if the final response later refuses, omits the amount or says the user lacks access. The issue is not only the generated answer. Supplying unauthorized evidence to the model context is architecturally wrong in itself.

The required sequence is:

Security trimming in the RAG path

1. 01

   User Identity

   Stable ID, tenant or workspace, plus the current session context

2. 02

   Identity Mapping

   Map application identity to source-system principal, groups and roles

3. 03

   Query

   Execute the request with its current security context

4. 04

   ACL-aware Retrieval

   Security trimming limits candidates to effectively authorized evidence

5. 05

   Authorized Evidence

   Only permitted chunks can reach reranking or further selection

6. 06

   Context Assembly

   Prepare authorized evidence for the model

7. 07

   LLM

   Generate from an already constrained context

Why post-filtering cannot be the primary boundary

A downstream filter can be useful as an additional check or to limit result presentation. It must not be the first or only control.

With conventional post-filtering, search might first return global candidates, a reranker might process them, or context assembly might select them. Results are removed only afterwards. Multiple components have already handled unauthorized data. Quality also suffers: if eight of the top ten results are restricted, only two remain after filtering even when relevant authorized documents were ranked lower.

Permission-aware retrieval, or pre-filtering, is therefore preferable: the retrieval index and query path apply the current authorization context before selecting candidates. The same rule applies to vector search, full-text search, hybrid search and reranking. A protected vector path is not enough if a parallel keyword path exposes restricted results.

Identity mapping: the same person in the application and the source

The business application knows the signed-in person. SharePoint, a DMS or a wiki know their own principals, groups and roles. A dependable mapping is needed between these worlds.

Start with a stable user ID from the application or identity provider, not a display name or email address as a permanent key. The retrieval context also needs the currently effective groups and roles, tenant or workspace, and, where the source requires it, its corresponding source-system principal.

Service accounts may simplify ingestion and have broad read rights. They must not act as the user identity at retrieval time. Where the application uses delegated access, the effective user context must still be traceable through the source or authorization model. What matters is an identity stable across sessions, not an incidental session or display value.

ACLs are first-class data, not an import by-product

A SharePoint or DMS document can have group-based ACLs, individual permissions and exceptions. The retrieval index must carry those effective rules from the source or consult a current policy source. Do not flatten allow/deny semantics and group membership into a simplistic “has group X”.

Nested groups matter only insofar as they create effective rights in the source system. The architecture needs to specify where that expansion occurs and how fresh it must be. A broad index filter and a more precise policy check can work together — but both must happen before context assembly.

Permission state is its own data layer. It must not be only a side effect of document import.

Document text can remain unchanged while its ACL changes: a file moves to another library, is reclassified or becomes restricted to a project group. That change must reach the retrieval path even when no content reindex is due. For source integration and change detection, see Connect RAG data sources.

Security trimming: pass on authorized evidence only

Security trimming constrains search to the current user's effective permissions. In practice, ACLs, groups, roles, tenant or workspace can form part of the search filter. The specific data model depends on the source and search engine; the invariant does not:

Unauthorized chunks must not enter the model context.

Filtering must stay consistent with the index and every query path. That includes derived artefacts such as chunk metadata, reranking candidates and citations. A document title, file path or project name can already be confidential. Source attribution therefore follows the same authorization decision as the text itself.

Permission changes and revocation

The difficult case starts after a successful initial import:

• User A loses project access.
• A group membership changes.
• The Phoenix document moves to another area.
• Its ACL changes while its text does not.
• Index or permission sync lags behind the source.

If user A still gets results after access has been withdrawn, the data is not merely a little stale; the security boundary has failed. Permission sync and revocation need to work independently of document content. A user's access must not disappear only at the next content reindex.

Revocation latency is a security criterion.

For each system, define how quickly a withdrawal must take effect in retrieval, context assembly and citations — and how deviations become visible. That time is a business and technical requirement, not an optimisation note.

Caches must respect the same boundaries

A technically correct retrieval filter does not help if a cache reuses results or answers across identity boundaries.

• A retrieval cache needs at least the relevant user, group and tenant/workspace context.
• An answer cache must not serve an answer to a different role or tenant.
• A permission cache needs bounded validity plus a strategy for changes and revocation.

A cache key alone does not solve every freshness problem. The crucial point is how permission changes invalidate the cache or limit its validity. Every cache must enforce the same security boundaries as retrieval.

Tenant and workspace boundaries are not group permissions

User- and group-level permissions determine what a person can see inside their area. Tenant or workspace isolation separates the system's primary security domain.

Where a tenant is the central boundary, it cannot be only an optional filter value that a query might omit. The appropriate additional separation — separate collections, indexes or storage boundaries, for example — depends on the protection need. The architectural decision must prevent one missing group filter from turning into cross-tenant evidence exposure.

Permission-aware testing and evaluation

A RAG golden dataset should contain user context, tenant and expected evidence. It tests not only whether an answer is factually right, but whether precisely the permitted evidence was found.

Track two error classes separately: a false denial means permitted evidence is incorrectly absent. Unauthorized retrieval means restricted evidence is found or passed on. For sensitive data, the latter is a security incident, not simply a quality problem.

RAG evaluation: metrics & golden datasets explains how retrieval, context assembly and answers can be assessed separately. Permissions belong there as a testable retrieval and context contract.

Architecture view

I would not treat permissions as a UI or prompting problem. The security boundary sits in the retrieval path: unauthorized evidence must not reach model context.

That does not require an unnecessarily elaborate IAM programme. It requires an explicit decision: which identity is making the request, which ACL is effective now, where is it enforced, and how quickly do old rights disappear? For SharePoint-specific integration questions, see Connect SharePoint to RAG. If an existing system needs review of retrieval, permissions and revocation, AI Production Readiness is the relevant next step.

Building RAG over internal company data and need to design or validate permission boundaries?
→ Discuss the RAG architecture