A retrieval system can find a relevant source and still be wrong. Once documents have different visibility, correctness means more than semantic relevance: the system must be allowed to use that source for this person, in this workflow, at this time.
The boundary sits before the model
If restricted material has already entered the model context, output filtering is too late. The material can influence an answer even when particular terms are removed afterwards. A deterministic access boundary must not depend on a model’s probabilistic restraint.
The order is therefore: resolve identity, determine permitted scope, search eligible sources, assemble context, then generate an answer.
Permission is part of the query
Each retrieval request needs an explicit actor and effective policy context. Depending on the system, the relevant boundary may be tenant, team, document, section, record or field.
First determine which content is eligible. Only then rank that set for relevance. When access and ranking are combined in a fuzzy mechanism, the boundary becomes difficult to test.
The index is part of the permission architecture too. Changes in ownership, classification or group membership must reach retrieval reliably. Stale metadata can reopen an otherwise well-designed query.
Define the no-source case
A sound knowledge system needs an explicit null case. When there is no sufficiently relevant and permitted source, it should say so rather than filling the gap with a plausible answer from general model knowledge.
That behaviour belongs in evaluation. Useful tests include:
- the same question under different identities,
- removed or expired permissions,
- documents with mixed visibility,
- caches after an access change,
- absent and conflicting sources.
Traceability without another data lake
A later review should be able to reconstruct the essential decisions: actor, policy version, eligible source, selected passages and access result. This does not mean retaining every input and output indefinitely. Logging needs its own purpose, permissions and retention boundary.
A practical acceptance line
A bounded first use is defensible when every request has an explicit identity, authorization is enforced before model context, the selected sources are visible and the null case is safe. A permission change should also become effective in retrieval within a known, testable path.
This does not make RAG automatically secure. It places the critical boundary where it can be enforced and examined: before generation.
Fitting that boundary into a real workflow is part of the services.
Want to assess a specific workflow?
Get in touch