Why RAG changes the permission path
A document system can make an access decision when a user requests a file. A RAG system adds several steps: it searches an index, retrieves passages, assembles model context and generates an answer. The current source rights must remain resolvable for every retrieved object, and the system must enforce them before a passage enters model context. Projecting permission metadata to each indexed chunk is one implementation pattern, not the only one.
You can map the end-to-end RAG pipeline to see the full flow in which permission enforcement must occur.
NIST's Zero Trust Architecture publication says that network location or asset ownership should not create implicit trust. The practical implication here is simple: putting an index on an internal network does not remove the need to authorise each retrieval against the user's current permissions.
Define subjects, resources, actions and policy
Before you design retrieval-time enforcement, write down:
- Subjects. Who are the users? What are their attributes (role, department, clearance level)?
- Resources. What are the protected objects? Source documents, derived chunks, cached answers, logs?
- Actions. What can a subject do? Read, retrieve, generate, export, delete?
- Policy. What rules determine whether an action is permitted?
NIST's ABAC guide describes policy decisions in terms of subject, object, action and environment attributes. That is a useful way to reason about the decision. It is not a ready-made index schema, and it tells you nothing about whether your attributes are current or correctly enforced.
You can turn classifications into handling controls to connect classification labels to permission rules, while keeping classification distinct from authorisation.
Carry source permissions into chunks and indexes
Each derived chunk needs a stable link to its source and enough information for the system to resolve current permissions. Azure AI Search documents one implementation that projects permission metadata to indexed chunks and applies caller identity or permissions during retrieval. Several of its native mechanisms use the 2026-08-01-preview API. Azure also notes that service-level roles do not automatically enforce source-document permissions.
You can preserve source permissions during document preparation by ensuring that permission metadata is complete and correctly recorded before ingestion.
The table below is an illustrative identity-to-answer control sequence. Adapt the decisions, evidence and owners to your architecture.
| Step | Action | Input | Output | Control question |
|---|---|---|---|---|
| 1 | Authenticate subject | User credentials | Authenticated identity | Is the user who they claim? |
| 2 | Determine requested action | User query, context | Action type (retrieve, generate, export) | What is the user trying to do? |
| 3 | Resolve permission context | Identity, current source rights and indexed object references | Current subject, object and environment attributes | Are the attributes current and tied to the authenticated subject and source objects? |
| 4 | Apply policy to the retrieval request | Current attributes and requested action | Permit, deny or authorised retrieval constraint | Which objects may this request search? |
| 5 | Retrieve within the authorised scope | Constrained query, index and permission metadata | Authorised candidate chunks | Has unauthorised content been kept out of the result set? |
| 6 | Assemble context | Filtered chunks, instructions | Assembled context | Is the context within budget and complete? |
| 7 | Generate answer | Assembled context | Generated answer | Does the answer follow the context? |
| 8 | Handle caches and logs | Answer, context, metadata | Cached answer, log entry | Are caches and logs permission-aware? |
| 9 | Process revocation | Permission change event | Updated index, invalidated caches | Is the revocation complete and tested? |
Apply identity-aware retrieval and security trimming
Security trimming constrains retrieval results to content the user is authorised to see. Apply authorisation early enough to keep unauthorised content out of assembled model context. Depending on the design, enforcement may sit in the index query, a separate policy decision before retrieval, a checked filter before context assembly, or a combination of controls. A display filter applied after generation is already too late.
Ask these questions for every retrieval path:
- Filter location. At the index level, at the application level, or both?
- Filter timing. Before or after reranking?
- Filter evidence. Is the filter decision logged?
- Filter testing. Are both positive and negative cases tested?
Azure's RAG design guide separates ingestion from runtime and recommends representative tests at each stage and end to end. It does not establish that your permissions are enforced.
Record each boundary explicitly
This boundary record is an editorial synthesis. Use it to find the gaps between a successful login and an authorised answer.
| Boundary | Required decision or state | Evidence to retain | Freshness question |
|---|---|---|---|
| Authentication | Subject identity and session are valid | Authentication event and subject identifier | When must identity be revalidated? |
| Source rights | Current rights exist in the source of truth | Source object ID, rights snapshot or change event | How quickly do grants and revocations propagate? |
| Indexed metadata | Each derived chunk carries the correct source and permission reference | Metadata audit tied to source version and index build | Can a partial re-index leave stale attributes? |
| Policy decision | Subject, object, action and environment produce a defined outcome | Policy and version, inputs and permit or deny result | Which attribute changes invalidate the decision? |
| Retrieval enforcement | The query or result set is restricted to permitted objects | Filter or constraint plus returned object IDs | Can reranking, fallback or another retrieval path bypass it? |
| Context assembly | Only authorised, traceable chunks enter model context | Context references and assembly trace | Can a cache or reused context cross the boundary? |
Handle tenant isolation, caches and derived output
In a multi-tenant system, enforce tenant isolation across retrieval, context assembly, generation, caching and logging. An answer cached for one tenant must never be served to another.
Make tenant identity, subject identity, policy version and relevant source scope part of the cache decision. A key based only on query text can return an answer assembled under a different user's permissions. Test direct lookups as well as semantic or approximate caches, and define which permission or source changes invalidate each result.
Derived output does not automatically inherit enforceable permissions from its sources. Generated answers, summaries and extracted entities need an explicit handling rule based on every contributing source and the action being taken. Keep provenance for that source set, apply the handling your policy requires, and test exports and reused summaries as well as the initial answer. A model or vector store does not supply this behaviour by default.
Process revocation, deletion and permission changes
When a user's permissions change, update every path that relies on them:
- Refresh or invalidate the source-rights references, policy state or projected permission metadata used by each affected retrieval path.
- Invalidate any caches that contain content the user can no longer access.
- Log the change, affected objects and propagation state.
- Test that the revocation meets a defined objective for each retrieval and cache path.
When a document is deleted, follow it through every derived artefact:
- Remove the document and its derived chunks from the index.
- Invalidate any caches that reference the document.
- Log the deletion and the affected objects.
- Test that the deletion is complete.
NCSC's secure operation and maintenance guidance recommends monitoring and evaluating versioned changes because updates can alter system behaviour.
Set a measurable propagation objective rather than promising that every change is effective immediately. Record when the source permission changed, when indexed metadata was refreshed, when caches were invalidated and when the negative retrieval test passed. A grant deserves testing too: an over-restrictive stale projection can prevent legitimate use even when it does not disclose information. If re-indexing is asynchronous, specify the safe behaviour while a change is pending.
Test positive and negative authorisation cases
This pattern, failure and test matrix is an editorial synthesis. Adapt it to your policy, technology and threat model.
| Control point | Intended rule | Common failure | Positive test | Negative test | Evidence | Owner |
|---|---|---|---|---|---|---|
| Source ingestion | Only approved sources enter the index | Unapproved source ingested | Approved source appears in index | Unapproved source is rejected | Ingestion log | Data steward |
| Chunk metadata | Every chunk can resolve current source rights through its source reference or the design's projected permission fields | Missing or stale source reference or projected field | Representative chunk resolves the expected permitted scope | Missing or stale rights data fails closed and is flagged | Metadata and permission-resolution audit | Data engineer |
| Query filter | User can only retrieve authorised chunks | Filter bypassed or misconfigured | Authorised chunk is retrieved | Unauthorised chunk is excluded | Retrieval log | Security engineer |
| Tenant isolation | Tenant A cannot access Tenant B content | Cross-tenant cache hit | Tenant A retrieves own content | Tenant A cannot retrieve Tenant B content | Cache audit | Platform engineer |
| Cache reuse | A cached result is reused only under a compatible current permission state | Query-only key or stale authorisation state | Same authorised subject and source scope receive the eligible result | Changed user, tenant or revoked source cannot reuse it | Cache key and invalidation trace | Platform engineer |
| Generated output | Answer and downstream action use only context permitted for that subject and action | A disallowed source influences an answer or export | Authorised subject receives an answer from the permitted source set | A deliberately disallowed source cannot enter context or influence the answer or export | Context and output trace | AI engineer |
| Permission change | Revoked access meets the defined propagation objective | Stale index or cache serves old content | Newly permitted user succeeds after propagation | Revoked user is denied across retrieval and cache paths | Timed revocation trace | Security engineer |
| Deletion | Deleted document and its derived artefacts cannot be retrieved or reused | Orphaned chunk or cached result remains | An unrelated retained document remains retrievable after deletion processing | An exact-source query and index or cache check return no deleted content | Retrieval, index and cache deletion trace | Platform engineer |
Keep logs and decision evidence
Keep enough evidence to explain each authorisation decision without copying unnecessary protected content into the log. ETSI TS 104 223 V1.1.1, Baseline Cyber Security Requirements for AI Models and Systems includes access-control and auditability or provenance requirements. These are baseline requirements, not certification of a particular RAG design.
For a practical working decision record, capture the subject and tenant identifiers, requested action, source or object identifiers, policy version, relevant filter outcome, returned context references, cache decision, time and control owner. This record is an editorial synthesis, not a standard. Retain denials as well as permits. Protect the record according to its sensitivity, minimise prompt or document content, and document any identifiers that you deliberately omit or transform.
Logs enable:
- Audit of permission behaviour.
- Diagnosis of permission leaks.
- Evidence for incident response.
- Verification that revocation is effective.
Tie the decision record to the exact index and source versions used. A reviewer can then distinguish a stale permission projection from a correct policy decision applied to stale data. Test that administrators can reconstruct a representative permit and deny case. Test the log's own access controls too, so the evidence does not create another route to protected material.
You can follow the organisation's AI governance policy to assign owners, evidence requirements and exception handling for access-control decisions.
What RAG access control does not solve
Access control in a RAG system does not:
- Prevent a model from generating a harmful answer from authorised content.
- Detect or neutralise instruction-like content in a document.
- Guarantee that the answer is factually correct.
- Replace source approval, classification or minimisation.
- Provide a universal security verdict.
You can place access control inside the wider RAG threat model to understand the full risk surface.
Keep document checks as a separate layer
Document checks for prompt-injection and other supported document-borne risks are a separate layer from access control. Access control determines who can retrieve what. A document checkpoint determines how to handle one exact version before it enters an AI workflow.
Once you have defined the permission model, enforcement points, failure tests and evidence, check the source as a separate intake step. .mdSiren is a document security workspace for AI. When it launches, Standard Scan will check the exact version for supported prompt-injection and document-borne risks, route it to Approved, Needs review or Quarantine, and keep the Approved exact version in your private Library. If the file changes, check the new version. This decision does not authenticate users, synchronise permissions or enforce retrieval access. A finding is a reason to review, not proof of malicious intent. Explore the document-checking workflow.
Frequently asked questions
How does access control work in RAG? One pattern projects source permissions to indexed chunks as metadata. Another retains source-object references and resolves current rights through a separate policy service. In either design, the authenticated subject's current rights must be enforced before selected context reaches the model, with both positive and negative tests.
Does a vector database preserve document permissions? Not automatically. A vector database can store vectors and permission-related metadata, but it does not recreate the source system's authorisation behaviour by itself. You still need to keep permissions current, enforce them in every retrieval path and test the result.
What is security trimming in RAG? It is the process of constraining retrieval results to content the user is authorised to see. Enforcement can occur in the query, index, application or a combination, but unauthorised content must not enter assembled model context.
How should a RAG system handle permission changes? Refresh or invalidate the permission state used by every affected retrieval path, including projected chunk metadata or policy caches where present. Invalidate relevant result caches, log the change, and test that the revocation is effective.
Is document scanning the same as RAG access control? No. Document scanning checks a specific document version for signals. Access control determines who can retrieve what. They are complementary layers, not the same thing.
