RAG permissions before the model
A restricted passage must be filtered before retrieval reaches generation. Design identity, row-level security, revocation, and relevance tests as one access boundary.
A citation filter after generation is too late. Identity, access scope, and source permissions must decide what retrieval can return before a model receives context.
Syntalith Team
An internal knowledge assistant can expose a restricted document in two ways. It can show the document as a citation, or it can use the passage to shape an answer that looks harmless. A refusal can also reveal that a restricted subject exists.
The access decision must happen before the model receives context. A secure design treats identity, retrieval, database enforcement, revocation, and answer storage as one boundary.
Put access checks before retrieval
The request path should make the order explicit:
- establish the user's identity and current group or role membership;
- resolve the source records that identity may read;
- apply that scope to every retrieval path;
- enforce the same scope at the data layer;
- pass only permitted passages to generation; and
- return citations that the user can open under the same policy.
Filtering a finished answer cannot remove information the model has already seen. A system that hides the citation while leaving the passage in context has a presentation control. It does not have an access control.
Make the identity source authoritative
Choose one authoritative source for identity and group membership. Document how a role change, suspension, or departure reaches sessions, indexes, caches, and saved answers. A manually maintained permission copy tends to drift and is difficult to review.
Each indexed record should carry a stable identifier, owner, version or status, effective date, and access scope. An email attachment and a file-share document may contain the same words while having different audiences. Deduplication should group their content without widening the scope of either record.
Service accounts and administrators need an explicit policy as well. A technical account with broad access can bypass a user-facing filter, so test it separately and log its use.
Add independent enforcement
An application-level group filter is useful for shaping the candidate set. A database policy such as PostgreSQL row-level security can enforce the same rule at query time. The two layers should use the same authoritative identity and scope model while remaining independently testable.
The PostgreSQL row-security documentation describes policies that restrict which rows may be returned or changed. It does not design an organisation's permission model. Define the model first, then choose where each policy is enforced.
Do not rely on an answer scrubber. If a restricted row never reaches the retrieval result or model context, the system has a much clearer security boundary.
Keep revocation and caching explicit
Write down how quickly access must disappear after a change. Check active sessions, retrieval indexes, embedding stores, response caches, background jobs, exports, and saved conversations. Decide whether an answer remains readable when the person later loses access to the source.
Stored citations should keep the source version and access check that produced them. A link that opens a document after access is revoked can be useful for an authorised auditor, but it should not become a permanent copy for the former reader.
Test permission and relevance separately
Create a reviewed matrix with several roles and the same question asked under different scopes. Include:
- a permitted source;
- a source the user cannot access;
- a question whose answer spans scopes;
- a revoked document;
- a stale and current version;
- conflicting sources; and
- an answer that does not exist in the allowed corpus.
For each case, record the expected access decision, candidate set, citation, answer or refusal, and escalation owner. Measure permission violations separately from retrieval recall. A safe refusal can still indicate a search-quality problem, while a relevant answer can still be a security failure.
Treat conflict as a visible state
Two permitted sources can disagree. Keep both source references, mark the conflict, and route it to the owner. The model should not average dates, limits, or responsibilities into a smooth sentence.
The conflict status should survive into the answer and downstream workflow. If the user cannot access one of the sources, the interface should explain only the permitted state and route the unresolved item to an authorised owner.
What to ask a vendor
- Which identity source supplies the user's groups?
- Where is the filter applied for vector, lexical, and fallback searches?
- What independent database or service-layer policy enforces the scope?
- How quickly do revocations reach sessions, indexes, and caches?
- Can saved answers be reopened after access changes?
- What does the user see when no permitted source answers the question?
- Are administrators and service accounts included in tests?
- Can we inspect a retrieval trace without exposing restricted content?
Ask for test evidence on your own permission matrix. A single-role check says little about permission enforcement.
Sources and safeguards
The NIST AI Risk Management Framework recommends governing, mapping, measuring, and managing AI risks across the lifecycle. The GDPR text is the primary reference for personal-data duties. Use both as inputs to your own access and retention assessment.
For an internal assistant that must keep permissions before generation, start with a process scan and bring the identity model, source inventory, and revocation requirement.
FAQ
Can a vector database enforce employee permissions by itself? Do not assume it. The retrieval service needs a policy that receives the requester's scope, and an independent enforcement point should prevent an accidental bypass.
Should every refusal be identical? The security requirement is that a refusal does not reveal whether a forbidden source exists. Define the user experience and test it against source presence and absence.
Is RLS enough? RLS can protect database rows. It does not solve identity freshness, index copies, caches, saved answers, source conflicts, or the quality of the retrieved passages.
Sources
Free process scan
Start with a free process scan.
- A 30-minute call with the engineer who would lead the work.
- A review of the processes that cost you the most time and money.
- A written summary of what to automate first and the likely cost range.
The scan chooses one process to assess, and within 2 business days you receive a recommendation, including when a simpler route is the better fit.
€0
30 minutes · written takeaway within 2 business days
Times are shown in your own time zone. We work with clients across time zones.
Describe the process in the form