Back to News & insightsEngineering

Permission-aware RAG: retrieve only what the reader may know

Trace access control through indexing, retrieval, reranking, citations, caches, and deletion so an assistant respects document boundaries.

Editorial guide · Updated September 27, 2026 · 4 min read
A silver key illuminates one authorized compartment in a sealed glass archive.

A document assistant should not discover whether a passage is private by generating an answer from it. Access control must shape the evidence available to the system before private content reaches a model or an unauthorized reader.

This is easy to overlook when a prototype contains only public files. Adding a company workspace changes the problem: every document, chunk, cached result, and citation becomes part of the permission model.

Begin with the source of authority

Imagine a fictional consulting firm with shared methods, client-specific folders, and restricted commercial proposals. A consultant can read the shared methods and assigned client folders. A search query that resembles a restricted proposal must not widen that scope.

Use a trusted identity and permission service to establish access. Do not accept a user-supplied tenant identifier as proof of membership. The model's proposed tool arguments also remain untrusted input; server-side checks decide which scope is allowed.

Document whether permissions come from the source repository, the application, or a synchronized copy. If several systems contribute, define which one wins when they disagree. Ambiguous authority creates inconsistent access even before retrieval begins.

Carry permissions into the index

When a document is split into chunks, preserve its identity, version, and permission metadata. A passage should remain traceable to the source that authorized it. Losing that link during preprocessing can leave a searchable fragment after the original file becomes restricted.

Apply verified access constraints before content is exposed to rerankers or generation services. Where possible, make the retrieval query itself permission-aware. Filtering an answer after generation cannot undo a disclosure to an intermediate service.

PostgreSQL row-level security is one documented mechanism for database-side row policies. Its behavior depends on roles and configuration, including privileged bypass cases. Any chosen storage layer needs tests with the exact identity used by the assistant, not only an administrator's test session.

Treat every retrieval stage as a data boundary

The consulting assistant may use keyword search, vector search, reranking, and summarization. Check each stage for unauthorized content. A reranker that receives restricted passages has already crossed a boundary even if the final answer omits them.

Avoid logging full candidate passages by default. Debug traces, cached snippets, and evaluation exports can become a second document repository with weaker permissions than the original. Keep identifiers and safe operational metadata where they are sufficient for diagnosis.

Decide what users see when nothing permitted answers the question. The response should not confirm the existence or title of a confidential document unless the access policy explicitly allows that metadata to be disclosed.

Revocation is part of normal operation

Suppose a consultant leaves a client project. Removing folder access is not enough if old cached answers or conversation summaries still contain client details. Define how revocation affects retrieval, caches, persisted conversations, and previously generated artifacts.

Some historical outputs may have already been legitimately delivered. Others remain within the application's control and should be protected under the relevant retention policy. Be precise about that distinction instead of promising that an index deletion erases every copy everywhere.

Version permission state or use a reliable invalidation mechanism where needed. If the permission service is unavailable, fail according to an explicit policy. For sensitive content, silently broadening access to preserve availability is the wrong fallback.

Test with paired identities

Create a fixture containing public, team-only, and client-restricted documents. Ask the same question as two users with different permissions. Verify the retrieved passages, intermediate tool payloads, final answer, citations, and cached follow-up.

Then change one user's access and repeat without rebuilding the whole environment. This exposes stale permission copies. Include direct citation links: the source document must enforce access when someone opens it, even if the assistant previously generated the link.

Also test deletion, renaming, and moving a document between folders. These ordinary operations often reveal gaps that an adversarial prompt test alone does not cover.

Make evidence inspectable without leaking it

Provide authorized readers with useful citations and a way to report an incorrect source. Give operators enough metadata to investigate which permission decision was applied. Keep the content itself restricted to people who need it.

A permission-aware assistant is a search and authorization system as well as a generation system. Its credibility depends on respecting what each reader may know throughout the pipeline, including when permissions change after the first answer.

Technical background

Read source on www.postgresql.org

An original editorial guide. Provider capabilities and documentation can change. Follow the linked sources and test the exact model or service before relying on it.