Skip to main content

Command Palette

Search for a command to run...

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.

Updated
3 min readView as Markdown
Day 18: Why relevant data can still be unauthorized data
V
I’m Vamsi, a builder focused on production AI systems. I write Production AI Field Notes to break down the architecture behind reliable LLM apps, RAG, agents, multi-agent workflows, evaluation, observability, safety, and governance. My goal is simple: help builders move beyond impressive AI demos and design systems that can be tested, operated, trusted, and improved in the real world.

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)

Retrieval Foundations

Part 6 of 6

A practical foundation for retrieval systems. This series explains how chunking, embeddings, vector databases, keyword search, semantic search, hybrid retrieval, metadata, and access filters decide what evidence an AI system can safely use.

Start from the beginning

Day 13: Why chunk boundaries shape answer quality

How chunk boundaries decide what evidence the system can actually retrieve.