RAG access control must be enforced before the model sees a document

RAG access control means that retrieval-augmented generation only retrieves content the current caller is authorized to use for the defined task. Permission is checked before selected text enters the model context, then verified again before evidence or output reaches the user.

Tenant isolation alone does not settle the question. Two people in one company may have different rights to finance records, client folders, or commercial terms. A relevant document can still be an unauthorized document.

The safest design carries identity and permission through every retrieval step instead of asking the model to hide information after it has already received it.

Relevance and authorization answer different questions

A retriever is built to answer “Which chunks best match this query?” Authorization asks “Which resources may this person access right now?”

Those questions use different evidence. Similarity can be calculated from an embedding. Permission may depend on project membership, document ownership, a group, a contractual purpose, or a source-system rule that changed five minutes ago.

If the search runs across every chunk and filters the final prose, sensitive content has already crossed the boundary. The model may quote it, infer from it, place it in a trace, or use it to shape an answer that appears harmless.

NIST's zero-trust architecture focuses protection on users, assets, and resources and grants no implicit trust from network location or ownership. That principle fits enterprise retrieval well. A company network, a valid login, or membership in the same workspace does not prove access to every document inside it.

Carry the caller's identity through the retrieval path

A permission-aware retrieval request needs more than query text. It needs the principal, current roles or relationships, tenant, approved purpose, source scope, and time.

The path can be drawn as:

Principal → purpose → candidate sources → authorized documents → ranked chunks → model context → cited output

Authorization belongs before ranking or inside the retrieval query itself. This reduces the candidate set to material the caller may receive. Each returned chunk should retain its source identifier, version, and permission context so the application can verify the evidence again before displaying it.

Caching requires care. A cache keyed only by the natural-language question can return an answer assembled for another user. Include the relevant authorization context in the key, or keep the cached object behind a fresh permission check.

Choose an enforcement pattern that matches the source

Three patterns appear often in enterprise RAG systems.

These patterns can be combined. Tenant data may live in separate logical partitions while project or role permissions are evaluated inside each partition.

Supabase's RAG with permissions guide demonstrates one concrete approach: store ownership data with document sections and use Postgres Row Level Security to filter retrieval. The general lesson is broader than one database. Authorization should be enforced by code or data policy the model cannot rewrite.

What an early Skybridge boundary taught us

During one Skybridge implementation, we added per-agent source scopes. A finance agent could receive selected discovered sources in its prompt while another agent received a different subset.

The review found an incomplete edge. The prompt-time source filter constrained the injected digest, but an active search tool could still search the wider workspace vault. We documented the partial boundary plainly and withheld the claim of full retrieval security.

The lesson was precise: scoping the context assembled before a turn does not automatically scope every tool the agent may call during that turn.

Every retrieval route needs the same authorization decision. That includes search, direct document reads, citations, preview endpoints, exports, background automations, and administrative tools. A single wider route can defeat the narrower ones.

The historical account establishes a durable release rule: authorization belongs at retrieval time, and every current route is assessed against that standard before release.

Recheck evidence before returning the answer

Permissions can change between indexing and use. A person can leave a project. A folder can become restricted. A document can be replaced while its old chunks remain in the index.

For higher-consequence systems, recheck the cited source or its authorization record before showing the answer. If the check fails, remove that evidence and regenerate, return a limited response, or tell the user that an authorized source is no longer available.

Output filtering can catch accidental sensitive fields and enforce format rules after retrieval authorization has run. Reconstructing document permissions from generated prose is too late.

Operational logs also need their own boundary. Recording the full retrieved text may create a second store with broader operator access and longer retention than the source. Log identifiers and decision evidence where they are sufficient. Store content only when the investigation or acceptance need justifies it.

Test six ways permissions change

RAG access control should pass production-like cases, not only a query from the workspace owner.

Add cross-tenant and administration tests where the architecture supports multiple companies. Use canary documents that should never appear outside a defined principal set. Record the retrieved source identifiers so a failed test can be investigated.

Treat incomplete retrieval scope as a release blocker

A useful RAG prototype can work from a dedicated folder or fictional dataset while the permission model is still being built. Real enterprise data requires a stronger decision.

If runtime authorization cannot be enforced across every retrieval route, narrow the source. If permission changes cannot reach the index reliably, query the source live or reduce the retention window. If the system cannot explain which evidence shaped an answer, keep the output advisory and away from consequential action.

Compsia places retrieval scope inside the release record for the exact production system. That record names authorized sources, users, tests, and residual limits. The secure enterprise AI framework explains how this retrieval boundary fits with identity, tools, actions, and operation.

Questions about permission-aware RAG

Is tenant isolation enough for enterprise RAG?

No. Tenant isolation prevents one customer from reaching another customer's data. Users and teams inside one tenant may still require different document, project, or field access.

Can a system prompt enforce document permissions?

No. A prompt can instruct a model to respect a scope, but the application must prevent unauthorized chunks from entering context. Permission belongs in retrieval policy and source access.

Should RAG copy source permissions into the vector database?

That is one valid pattern. The copied permissions must stay synchronized and be applied to every retrieval. Source-native authorization or hard index separation may fit better where permissions change quickly or the boundary is strict.