Day 18: Why relevant data can still be unauthorized data
Why relevant evidence is still wrong evidence if the user was not allowed to see it.

Your RAG system just found the perfect document for the question. It is the executive compensation file, and it is answering an intern.
Everything worked. Retrieval was accurate, ranking was sensible, the answer was well grounded. And you have a serious incident.
Relevant does not mean authorised.
A retrieval system should answer from the best evidence the current user is allowed to see — not the best evidence in the index.
The property that makes this dangerous
Semantic search has an uncomfortable characteristic: sensitive documents surface exactly when they are most relevant to whoever is asking.
The moment someone asks about salaries is the moment the compensation file ranks first. The moment someone asks about the acquisition is when the deal memo becomes the top hit. Relevance and sensitivity correlate, so the failure mode is not a rare edge case. It is the system working precisely as designed, aimed at the wrong audience.
Index-time filtering does not save you either. Permissions change: people switch teams, contractors roll off, documents get reclassified, regions impose new rules. An index built against last quarter's access model is enforcing last quarter's access model.
Enforcement has to happen in retrieval
There are only two places a rule can live, and they are not equivalent.
In the prompt: "Do not reveal salary information." This is a request to a probabilistic system that just read the salary information. It can be confused, talked around, or simply ignored under an unusual phrasing.
In the query: the retrieval call itself is scoped by the requesting user's identity, groups, region, and clearance, plus the document's classification and state. The compensation file is not filtered out of the answer. It never enters the candidate set at all.
Only the second one is a control. If your RAG security story is "the model was instructed not to," you do not yet have a security story.
Two rules that follow from that:
- Mirror your existing permissions; do not rebuild them. A parallel copy of your access model in the vector store will drift from the real one, and it will drift silently. Resolve permissions from the same source of truth your document system uses.
- Fail closed. If permissions cannot be resolved for a request, return nothing. The alternative (degrading to unfiltered retrieval when the permission service times out) is an availability decision that quietly becomes a disclosure decision.
The test to run this week
Take your least-privileged user account. Ask it your most sensitive questions: compensation, terminations, unannounced plans, legal matters. Read exactly what comes back.
Then make that a test suite that runs on every index change, because "we checked once" and "it holds now" are different claims, and only one of them survives a re-index.
Closing thought
Retrieval quality is not one dimension. An answer can be relevant, current, well-cited, and still be a breach.
Day 18 of 60 Days of Production AI Systems.
Has anyone on your team run your sharpest questions through your lowest-privileged account?
Previous: Day 17: Why hybrid search is often the practical default
Next: Day 19: Why reranking is where retrieval becomes useful
Day 18 of 60 · Retrieval Foundations (chapter 3 of 10)






