RAG permissions: security trimming, ACLs & secure retrieval

An internal RAG system can produce excellent answers and still be unfit for production if permissions are implemented poorly.

The critical question is:

Does a user see exactly the information they are allowed to access in the source systems – no more and no less?

That is not a prompt-engineering problem. It is access control in the retrieval layer.

The primary rule: authorization happens before the model

A common anti-pattern:

1. Retrieval finds all semantically relevant documents.
2. Restricted documents enter the context window.
3. The system prompt tells the LLM to use only content the user is allowed to see.

At that point, the security boundary has already failed.

Once sensitive content is in model context, authorization depends on the behavior of a generative system. That is the wrong layer.

The safer sequence is:

user identity → effective permissions → retrieval filter → authorized chunks → LLM

What security trimming means

Security trimming is well established in enterprise search: search returns only results the current principal is allowed to access.

RAG should follow the same principle.

A document or chunk may carry metadata such as:

• allowed_user_ids
• allowed_group_ids
• denied_user_ids
• tenant_id
• department_id
• classification
• source_acl_version

At query time, the user's effective principals are resolved and applied as search filters.

Simplified:

semantic_query AND tenant_id = X AND allowed_group_ids IN user_groups

The exact schema varies by source and search engine. The principle does not: retrieval must only return authorized evidence.

Early binding vs late binding

Early binding

Authorization data is materialized into the search index during ingestion.

Advantages:

• fast query-time filtering,
• clear security boundary in retrieval,
• good scalability across large corpora.

Trade-offs:

• group and permission changes need synchronization,
• ACLs can become large metadata structures,
• nested groups need careful resolution.

Late binding

The system checks authorization dynamically against the source system or an authorization service.

Advantages:

• permissions stay closer to the source of truth,
• less duplicated ACL data,
• changes can take effect immediately.

Trade-offs:

• additional latency,
• more runtime dependencies,
• harder across large candidate sets.

Hybrid models are also useful: broad filtering early, finer policy checks later – but still before restricted content reaches the LLM.

User identity must be stable

Authorization becomes fragile when systems use email addresses or display names as permanent identity keys.

Prefer stable IDs from an identity provider such as:

• Microsoft Entra ID,
• LDAP/Active Directory,
• Keycloak,
• Authentik,
• an internal IAM.

Retrieval should operate on a stable user ID plus resolved effective groups and roles.

Groups are the normal case

Enterprise documents are rarely shared user-by-user. Access is usually based on:

• departments,
• project groups,
• teams,
• roles,
• SharePoint groups,
• tenants,
• partner groups.

The architecture therefore needs an explicit answer to:

Who resolves nested groups, and how fresh is that mapping?

Common options:

1. resolve groups on every request,
2. maintain a cached principal index,
3. materialize effective groups during synchronization.

No option is universally correct. Scale, change frequency and latency determine the trade-off.

Permission changes matter more than the initial import

The demo case is simple:

• import document,
• copy ACL,
• search filter works.

The production case is harder:

An employee changes department. A project group is closed. A document is reclassified.

Permission changes need reliable propagation.

That includes:

• permission change detection,
• group synchronization,
• cache invalidation,
• ACL update or reindex,
• audit logs.

For sensitive data, an index with yesterday's permissions is not a minor freshness issue.

Permission revocation: access must disappear

Revocation deserves explicit treatment.

If a user had access yesterday and loses it today, stale caches or indexes must not continue to return restricted content.

Test:

• individual permission removal,
• group membership removal,
• tenant changes,
• document reclassification,
• group deletion.

Revocation is a production acceptance criterion.

Tenant isolation is more than a metadata filter

In multi-tenant systems, tenant_id should not be an optional convenience field.

Prefer defense in depth across:

• data model,
• query filtering,
• index/collection boundaries,
• storage,
• authentication tokens,
• logging.

The higher the sensitivity, the less a single forgotten filter should be able to break isolation.

Separate indexes or physical separation can be appropriate for high-risk workloads.

Chunk-level or document-level ACL?

If every chunk inherits the same rights from its source document, document-level ACL is usually simpler.

Chunk-level authorization becomes relevant when:

• one document contains different protected sections,
• content from several sources is merged,
• sections have different classifications.

It also increases complexity.

Principle:

Make authorization granularity only as fine as the real requirement demands.

Pre-filter or post-filter vector search?

When a search engine can combine metadata filters efficiently with vector retrieval, pre-filtering is often preferable: restricted content never enters the candidate set.

Post-filtering can hurt retrieval quality:

1. Vector search returns the top 10.
2. Eight are unauthorized.
3. Filtering leaves only two, although relevant authorized content existed at rank 11–30.

Authorization therefore affects not only security but also retrieval quality.

Hybrid search + ACLs

Permissions apply to every retrieval path.

If the system combines:

• BM25/full-text search,
• vector search,
• metadata filters,
• reranking,

the same authorization logic must constrain all of them.

A secure vector store is useless if a parallel keyword path leaks restricted results.

Reranking must not cross the boundary

A reranker should only process already-authorized candidates.

Pipeline:

authorization → retrieval candidates → reranking → context assembly

Not:

global retrieval → reranker → ACL filter

The later authorization happens, the more components unnecessarily process sensitive data.

Caching: an underestimated failure mode

Caches can bypass otherwise correct authorization.

Examples:

• retrieval results cached across users,
• query cache without user/tenant context,
• stale group mapping,
• final LLM response reused for multiple roles.

Every cache key needs the relevant security context.

For sensitive systems, document:

• what is cached,
• for how long,
• with which user/tenant key,
• how revocation invalidates it.

Citations can leak information too

Even when answer text is filtered correctly, citation metadata can expose restricted information:

• document titles,
• file paths,
• project names,
• URLs,
• authors,
• departments.

Source attribution must respect the same permissions as the content itself.

Permission-aware evaluation

A standard RAG evaluation set is not enough.

Add role and authorization cases.

| Test | Expected result | |---|---| | User A asks about an allowed policy | correct source is retrieved | | User A asks about restricted HR information | no HR document enters retrieval | | HR user asks the same question | HR source is retrieved | | User is removed from HR group | access disappears | | Document is reclassified | new ACL applies after sync |

Track two failure classes separately:

False denial

The user is authorized, but retrieval incorrectly removes the required source.

Result: poor answer quality.

Unauthorized retrieval

The user is not authorized, but retrieval exposes the source.

Result: security incident.

For sensitive systems, the second class is far more critical.

Logging: explain why a result was allowed

For debugging and audit, the system should be able to trace:

• user/tenant ID,
• effective roles/groups,
• applied filters,
• retrieved document IDs,
• ACL version,
• sources used.

Logs should still minimize personal data and sensitive content. But the system needs enough evidence to explain why a result passed authorization.

Architecture checklist for RAG permissions

Before production, answer:

1. What is the source of truth for identities?
2. What is the source of truth for ACLs?
3. Early binding, late binding or hybrid?
4. How are groups resolved?
5. How quickly must permission changes take effect?
6. How does revocation work?
7. How is tenant isolation enforced?
8. Are all retrieval paths filtered consistently?
9. Do cache keys include security context?
10. Are citations protected too?
11. Are permission-aware evaluation cases present?
12. Is unauthorized retrieval treated as a critical failure?

SharePoint, DMS and other sources

Permission-aware RAG is especially important with SharePoint because the source already has a mature authorization model. See Connect SharePoint to RAG for the integration architecture.

For multi-source ingestion, see Connect RAG data sources.

If an existing system needs to be tested for permissions, retrieval and go-live failure classes, see AI Production Readiness.

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