RAG Retrieval Access Control: Filter Evidence Before the Model Sees It

“Please answer only from materials the user is authorized to access” can improve model behavior, but it cannot serve as a security boundary. Once an unauthorized chunk enters the context, the model, logs, traces, and caches may expose it. The core principle of RAG access control is simple: first filter candidate evidence according to a trusted identity, then give the model only the permitted content.

Identity Context Must Not Come from User Input

The user ID, organization ID, role, and project membership in a retrieval request must come from a verified session or server-side authorization context. Do not let the frontend submit an arbitrary tenantId and interpolate it directly into a vector query. Do not merely state in the prompt that “the current user belongs to Team A.” The retrieval service should receive a subject that cannot be forged, then internally resolve the resources or policy labels that subject is allowed to access.

When an agent acts on behalf of a user, record both the original user identity and the agent application's identity. This makes it possible both to determine whether the user has the necessary business permissions and to restrict whether a particular client can invoke high-risk retrieval or export endpoints. Sessions and caches should be invalidated promptly after permissions change; do not wait until the user's next login to refresh them.

ACL Filtering Must Be Part of Retrieval, Not Post-processing

When each document or chunk is written to the index, attach the minimum useful ACL metadata, such as tenant, project, department, document visibility level, and expiration time. At query time, apply these conditions as prefilters for vector or full-text retrieval. Retrieving a global top-k first and then removing unauthorized chunks creates two problems: too few usable results may remain, and candidate rankings or logs may leak unauthorized resources.

If the permission model is complex, do not copy complete membership lists into every chunk. Instead, store stable policy IDs or resource labels, then have the retrieval gateway calculate usable filters through the authorization service. The important requirement is to keep filtering logic in one tested implementation rather than allowing every business tool to assemble its own where clause.

Caches and Citations Are Also Part of the Authorization Surface

A retrieval cache key must include at least the subject or permission version, tenant, query hash, and index version. Caching results for a query such as “refund process” by query alone can let the next user read the previous user's private documents directly. Proactively invalidate relevant caches when permissions change. If precise invalidation is impossible, shorten the TTL rather than extending the exposure window.

Citation links in model output also require a second authorization check. A chunk being authorized when the answer was generated does not mean the user will still be authorized when clicking its link later. When showing the source text, downloading an attachment, or expanding context, the citation service must authorize the request again rather than giving the browser a raw object-storage URL.

Turn Unauthorized Access Attempts into Regression Tests

The test suite must verify more than whether authorized users can retrieve documents. It must also confirm that unauthorized users still fail after obtaining a document ID, the same query, a stale cache key, an old citation link, or an asynchronous task ID. Cover scenarios involving cross-tenant access, removed memberships, expired documents, administrator support mode, and service-account calls. Rerun this test suite whenever the vector database, caching layer, or authorization service changes.

Correct RAG access control will cause some questions to return “I do not have permission to access the relevant materials” or ask the user to select a project. That outcome is safer than inventing an answer and easier to fix than exposing real content. Authorization must happen before retrieval so that the model operates only within the permitted knowledge boundary.

Policy Releases Need an Observable Transition Period

When permission rules change, first calculate the differences between the old and new policies in shadow mode and record the document sets that the new rules would reject or newly allow. Have business owners confirm high-impact differences instead of immediately applying the new policy to all retrieval traffic. After the production switch, monitor rejection rates, empty-result rates, and blocked cross-tenant access events to prevent both unintended access and sudden loss of materials for legitimate users.

Service accounts and background tasks also need least-privilege access. An indexing worker's ability to read source documents does not mean the query service may bypass user ACLs. A support tool's ability to diagnose problems does not mean it may place customer content into model context. Assign different identities to different responsibilities so that the permission design remains clear as the system grows.

Before launch, validate the system against a real permission matrix: have different roles, different projects, users with expired memberships, and support personnel run the same query, then compare the evidence and citation links visible to each. The results must explain every allow or deny decision rather than merely checking whether the final answer contains text. An authorization system must be testable and auditable, or it will quietly stop working when new tools are integrated.

When the user's context cannot be determined, deny access by default and return an actionable clarification prompt. Any fallback path that “returns results first to avoid harming the experience” will become a genuine data-leak risk in a multi-tenant system.

Include this default-deny path in product copy and support workflows. Users need to know how to reselect a project, request access, or contact the resource owner. Support staff need to see the denial reason and trace instead of temporarily bypassing ACLs to answer a ticket. A secure experience does not mean never rejecting a request; it means providing a correct, actionable, and non-disclosing next step when rejection is necessary.

Further Reading

• Enterprise Knowledge Base RAG
• Prompt Injection Defense
• MCP Multi-tenant Isolation