RAG access control: how do we preserve document permissions?

Design RAG access control across retrieval, citations, caches and history, with an editable two-user permission and revocation test plan.

All posts

Potentially, for explicitly supported read permissions that the connector can establish and the application can enforce before exposing content. A chat login or tenant filter does not demonstrate equivalence with source-file access. If the source rules cannot be mapped and kept current, start with a curated collection that every approved user may read.

What should a RAG access control test prove for two users?

It should prove that the retrieval system supplies only the passages each user may read, including after access changes. RAG means retrieval-augmented generation: documents are fetched to support an answer. Restricted content must be stopped before it enters the model request.

Use the editable two-user RAG access control test plan with synthetic documents and unique markers. The expected outcomes below are requirements, not observed results.

Change or requestUser A expectationUser B expectation
Document shared only with ARead permitted contentDenied, including title, preview and citation
Document shared with bothRead permitted contentRead permitted content
A's access revokedSubsequent retrieval blocked within the explicitly agreed freshness ruleAccess unchanged if B remains entitled
Permission lookup unavailableRestricted retrieval stopsRestricted retrieval stops
Saved answer reused after revocationCurrent access checked before redisplay or model reuseSame rule under B's current rights

Inspect the retrieved passages and model input as well as the displayed answer. Record source-change, reconciliation and denial times. A finite passing suite supports a bounded rollout decision; it does not establish instant synchronisation or recall information already seen.

Where do the authoritative document permissions live, and can the connector read them?

The original document system remains authoritative. Copying a file into an index does not create a new right to disclose it.

Define the scope before choosing a connector. This proposal concerns supported read access to copied documents. It does not claim to reproduce editing rights, download restrictions, device conditions or every sharing-link rule.

Microsoft Graph's list-permissions documentation says non-owner callers receive only sharing permissions applying to themselves. A connector that downloads a file successfully may still lack a complete view of who can read it.

The endpoint explains inherited permissions using inheritedFrom. However, the permission resource documentation states that OneDrive for Business and SharePoint libraries do not return that property. Its absence cannot establish that a document has no inherited access.

The proposed admission rule would exclude files whose effective permissions are unknown or unsupported. Record the source, permission types and account used to enumerate them. Resolve source-specific visibility limits before importing restricted content; increasing the connector's privileges requires its own scope review.

Which user and group identities must be mapped into the search index?

Map the authenticated reader to stable source identities and supported group memberships. Display names and browser-supplied group lists are unsuitable authority.

The proposed mapping would retain the identity-provider issuer, user identifier, source-system identity and organisation boundary. Include guests and nested groups only when the connector's semantics have been established. Record membership verification time and the permission revision used for a request.

Each searchable passage would carry its document identifier, content version and a reference to the relevant permission record. If a document becomes unavailable, the application must be able to locate its passages and derived copies.

Qdrant's multitenancy documentation demonstrates tenant identifiers in payloads and filtered queries. It does not establish automatic mapping of source-file permissions. Different staff within one tenant can still have different rights.

Open WebUI's RBAC documentation describes roles, groups, feature permissions and resource sharing inside that application. Its additive permission model is not proof that external grants, denies or inheritance survive a connector import. Verify the mapping for the chosen source rather than translating every rule into a group name.

Should access be checked during indexing, retrieval or both?

Both. Indexing must retain permission relationships, and retrieval must enforce the reader's current entitlement before restricted text reaches the model.

A proposed trusted backend would resolve identities, construct mandatory access filters and apply them to every retrieval route. It would then verify candidate access before releasing passages. The browser would not be allowed to remove the filter or nominate another user's identity.

PostgreSQL 18 row security can enforce policies on rows. Once enabled, it denies normal access when no applicable policy exists. Superusers and BYPASSRLS roles bypass those checks; table owners normally do too, unless forced under row security. Inspect the actual runtime role and policy composition. A shared database connection does not automatically represent the signed-in staff member.

Qdrant's documented tenant filtering offers another component for a design. Its tenant-index setting concerns data organisation, so the application still needs to enforce the required query filter. Neither database mechanism imports source permissions automatically.

Permission freshness is a separate problem. If access changes between checks, a copied permission record can be stale. A claim of identical current permissions needs a source-specific approach to concurrent changes. If an approved delay is allowed, describe that delay explicitly.

The proposed pilot would block requests when access cannot be established. It would also test revocation during generation before enabling restricted-content streaming. These are requirements to implement and verify, not existing safeguards demonstrated here.

Proposed revocation timeline tracks source access changes, permission reconciliation and derived-copy invalidation before a new access decision. Timing is unverified.
View the diagram at full size

Can snippets, caches, citations or generated summaries leak a document that retrieval filtered out?

Yes. A restriction on one retrieval route does not protect content copied to another route or store.

OWASP's RAG security guidance recommends per-passage access metadata and retrieval-time checks. It also addresses permission-scoped caching and invalidation after relevant changes. This is security guidance, not evidence that a particular product implements those controls correctly.

For the proposed pilot, disable shared response caching for restricted material. Protect citation, preview and download endpoints with the same authority checks as retrieval. Treat document titles as potentially sensitive too.

Saved summaries need provenance. A summary combining several restricted documents should require access to every contributing source unless separately reviewed for wider sharing. Recheck protected history before displaying it or including it in a later model request. A stored conversation can otherwise reintroduce material that fresh retrieval would deny.

Keep audit records restricted and avoid copying document text into routine logs. Recovery needs special attention: restoring an old index or cache must not restore revoked access. Reconcile current permissions before reopening the recovered service.

Revocation cannot recall information already seen or exported by a previously authorised person. The proposed controls concern subsequent access through the assistant. Downloads, parsing, embeddings, storage, model processing, backups and administrator access remain part of the separate deployment review.

How do we test denied access after a document is shared, unshared or moved?

Use synthetic documents with unique markers and compare source decisions with assistant decisions for both authorised and denied users.

A bounded pilot would use one source system, a small fixture collection and distinct users with direct and group-based access. The knowledge owner approves the corpus, the identity administrator owns mappings, and the platform owner owns synchronisation and recovery. A security reviewer assesses the test evidence before any restricted production corpus is admitted.

The proposed outputs are a permission map, protected retrieval design and repeatable negative-test suite. Keep access read-only and exclude unsupported permission types and operational writes.

Test another user's request, a newly granted share and a removed direct grant. Remove group membership, move a file between inherited-permission folders, and delete or replace a document. Also test forged client identities, omitted filters, permission-service outages and access changes during generation.

Inspect retrieval traces and model input as well as the final answer. A model declining to reveal a secret does not repair an unauthorised passage already supplied to it. Check snippets, titles, citations, cached answers and history reuse for each denied case.

Acceptance would require every defined denied case to block disclosure and every authorised control case to remain useful. Record the source-change time, detection time and first denied request. Agree any permitted delay explicitly before testing; it cannot be described as instantaneous equivalence.

Any unauthorised disclosure would stop the pilot. Rollback would disable restricted-corpus retrieval and invalidate derived copies. An old backup could reopen only after current permissions were reconciled.

When is a curated common-access corpus safer than reproducing complex file permissions?

Prefer it when every approved assistant user may read every included document and the additional value of restricted material is modest.

This is the strongest countercase to permission-aware retrieval. A deliberately approved set of manuals or redacted policies removes much of the per-document mapping problem. That is an inference from reduced complexity, not a measured security result.

The knowledge owner still needs to approve the audience and new material. A powerful service account's downloadable files are not automatically a common-access collection. Keep provenance, withdrawal and deletion procedures, and review whether an audience change invalidates the original approval.

For restricted retrieval, estimate connector integration and reconciliation labour plus infrastructure, storage, power, backups, maintenance and regression testing. Costs depend on the source rules and required revocation timing; no price or saving is established here.

Proceed only when the source scope, identity mapping and changing-permission behaviour can be demonstrated for the selected configuration. Otherwise, exclude the restricted documents and use the common-access collection or the original document system.