Permission-aware retrieval: the control most RAG diagrams omit

Most retrieval-augmented generation diagrams show a user query flowing to an index, a handful of similar chunks returning and a model composing an answer. One box is often absent: the policy decision that establishes which resources this user, agent and task may retrieve at all.

In an enterprise system, relevance is not permission. A salary document may be highly relevant to a manager’s query and still outside that manager’s scope. A customer record may match perfectly and belong to another tenant. If restricted content reaches the model and is filtered only from the final answer, the access boundary has already failed.

Permission-aware retrieval carries authenticated identity and current policy into candidate selection, preserves source provenance through indexing and checks access before content enters ranking, caches or generation.

Establish the active principal

Every query should run on behalf of an authenticated principal: a person, service or agent acting under a defined delegation. Record both the initiating user and the runtime identity used to access sources.

Ask:

• Who requested the task?
• Which organisation, tenant and role are active?
• Is the agent acting as the user, as a service or under delegated authority?
• Which purpose and action class is approved?
• Are device, session, location or risk conditions relevant?
• When do credentials and delegation expire?

Do not accept identity claims supplied in free-form prompts. Resolve them from an authoritative identity and access-management source and pass signed, validated attributes to the retrieval policy layer.

NIST SP 800-207 describes zero trust as removing implicit trust based on network location or asset ownership and making authentication and authorisation discrete functions before a session to a resource. A RAG system should apply the same resource-focused reasoning to documents and chunks.

Preserve permissions during ingestion

Permission-aware query handling depends on an index that has not discarded source control information. At ingestion, retain:

• authoritative source identifier and version;
• tenant, repository and security domain;
• document, section or record-level policy labels;
• owner and classification;
• effective and expiry times;
• deletion and retention class;
• provenance for every derived chunk, summary and embedding.

Decide the enforcement grain. Document-level access is insufficient when one document mixes public and restricted sections. Chunk-level metadata may work only if chunks do not combine security domains and cannot be detached from their source policy.

Treat permission changes as index events. When a source owner removes a user or changes classification, update or invalidate searchable derivatives promptly. A nightly synchronisation may be unacceptable for immediate revocation; define the maximum stale-permission interval and safe behaviour when synchronisation fails.

Filter before similarity ranking

The safe ordering is conceptually simple:

1. authenticate the principal and validate delegation;
2. resolve current policy and allowed resource domains;
3. construct an authorised candidate set;
4. perform keyword, vector or graph retrieval within that set;
5. rerank authorised results;
6. assemble bounded context with provenance;
7. generate and apply output or action controls.

Retrieving globally and filtering afterward can expose restricted text to the vector service, reranker, cache, traces or model. It can also leak through metadata such as result counts or timing. Prefer native pre-filtering, separated indexes or a policy-enforcing retrieval gateway that never returns unauthorised content to downstream components.

The appropriate pattern depends on scale and policy complexity. Physical separation can simplify strong tenant boundaries. Metadata filtering can support dynamic role or attribute policies but needs careful fail-closed behaviour. Post-filtering may be a defence-in-depth check, not the primary access control.

NIST SP 800-207A emphasises identity-based policies for users, applications and services and architectures that enforce granular application-level controls. Although not written specifically for RAG, that application-identity model fits retrieval pipelines composed of ingestion, index, reranking and model services.

Keep policy outside the generative model

The model can help explain a denial or request clarification. It should not decide whether a chunk is authorised based on a natural-language instruction. Enforce policy in a trusted component with explicit rules, tested inputs and auditable decisions.

NIST’s security and privacy control catalogue, SP 800-53 Rev. 5, includes access enforcement and least-privilege controls. Applying those control ideas means that the retrieval service enforces approved authorisations for logical access and receives only the permissions needed for the current request.

Avoid an index service identity that can read everything while the application hopes to filter correctly. Where possible, combine application policy with source-native access checks so the retrieval layer cannot silently exceed the underlying system of record.

Control caches, summaries and conversation history

Authorisation must survive derived data. A response cache created for an administrator cannot be served to a general user. A summary generated from restricted sources inherits their sensitivity. Conversation history can contain content the current user no longer has permission to retrieve.

Key cache entries by principal and relevant policy attributes, or avoid shared caching for restricted content. Attach source IDs and policy fingerprints to generated summaries. Revalidate access before reusing previous context, especially after role changes or account transfers.

Do not log retrieved chunks by default. Structured logs can capture policy decision, source identifiers, counts and outcome without copying content. Use protected, time-limited debugging when content is necessary for investigation.

Test denial and useful access together

A permission filter can prevent leakage and still make the assistant unusable. Evaluate both security and retrieval quality across representative identities.

Build a matrix with users, groups, tenants, resource types, actions and conditions. Include:

• a user with no access to a relevant document;
• a user with access to only one section;
• overlapping group memberships;
• recently granted and revoked access;
• a renamed or moved source;
• cross-tenant documents with similar language;
• malicious instructions asking the model to infer restricted content;
• cached answers produced under broader permissions;
• source and policy services unavailable;
• an administrator whose elevated access should not persist into a later session.

Inspect candidate IDs and model context, not just the final answer. A refusal does not prove restricted content was never processed. Conversely, a correct answer might come from an unauthorised source even if identical public information exists.

Peer-reviewed work on permission-aware RAG proposes interfacing retrieval with provider-controlled identity and access systems to support fine-grained access across multiple resources. Treat any research architecture as evidence for design options, not a guarantee for a local implementation; test the chosen index, policy and failure modes.

Plan for policy-service failure

Define safe behaviour when identity, group membership or source-policy services are slow or unavailable. For restricted corpora, fail closed rather than falling back to an unfiltered search. Consider whether a narrowly scoped, recently validated policy cache is acceptable and for how long.

Monitor:

• denied and allowed retrieval decisions by resource class;
• policy-evaluation failures and latency;
• stale permission updates;
• orphan chunks without provenance;
• cross-tenant candidate anomalies;
• cache hits across policy changes;
• discrepancies between source and index access.

Alerts should route to an owner with an action. A rise in denied searches might indicate probing, broken group mapping or legitimate users losing access. The signal needs context before it becomes a governance conclusion.

Treat retrieval as part of the data-processing ecosystem

Permission-aware RAG spans source systems, embedding services, vector stores, model providers and observability. The NIST Privacy Framework encourages organisations to understand their role and relationships across the data-processing ecosystem. Map which provider sees queries, embeddings, content and outputs and whether its own personnel or subprocessors can access them.

Authorisation does not settle purpose limitation or data minimisation. A user may be allowed to read an entire case file while the agent needs only the case status. Apply field selection and task scope after access is established.

The most important RAG control sits before the attractive part of the diagram. Identity and policy determine the candidate set; relevance ranks within it. Preserve that order through ingestion, caches, context and logs, and test it under change and failure. Only then can a grounded answer also be an authorised one.