Why retrieval-augmented generation turns access control into an inference problem, and what developers can do about it.
Most teams building AI features start with a simple goal: connect a language model to the company’s data so people can ask questions in plain English. Support tickets, wikis, contracts, meeting notes, and code repositories all become searchable through one friendly interface.
That convenience is the point. It is also the risk.
For years, access control meant deciding who could open which document. A retrieval-augmented generation (RAG) system changes the question. It doesn’t just open documents. It reads many of them, combines fragments, and writes a fluent answer that no single document contained.
So the question developers now face is no longer just “Who can see this file?” It’s “What can this system reveal by connecting everything it can see?”
1. The Assistant Often Has More Access Than the User
A typical RAG pipeline works in a few steps. A user asks a question. The system converts it into a numerical representation and searches an index for the most similar chunks of text. Those chunks are assembled into a prompt, and the language model writes an answer.
Notice what is missing from that description: any mention of who is asking.
In many early implementations, the retrieval layer connects to the index with a single service account. Every document the index can see is eligible to be retrieved for every user. The application then relies on the model, or on a line in the system prompt, to decide what is appropriate to share.
That is not access control. A prompt instruction is a request, not an enforcement mechanism. It can be worked around, forgotten during a refactor, or defeated by a cleverly phrased question.
The principle is simple: authorization must happen before content reaches the model, not after. If a chunk is in the context window, assume it can leak.
2. Permissions Get Lost in the Indexing Step
Even teams that care about access control often lose it during ingestion.
A document in a source system has an owner, a sharing list, and maybe a sensitivity label. When it is split into chunks, embedded, and written to a vector store, that context frequently disappears. The chunk becomes a vector and some text, detached from the rules that governed the original.
Consider these failure modes:
Stale permissions: A file is unshared in the source system, but the index still holds the old copy and keeps serving it.
Flattened permissions: Nested folder and group rules get collapsed into a coarse “internal” tag.
Orphaned chunks: A document is deleted, but its embeddings remain.
Over-broad indexes: Everything is placed in one collection because it was easier to build.
A safer pattern has two parts. First, every chunk carries its authorization metadata, such as the groups or individuals allowed to read it, and the search itself is restricted to chunks the current user is entitled to see. Filtering inside the search matters because restricted content never enters the candidate set at all. Second, the results are re-verified against the system of record before they are used, because an index is a copy, and copies go stale. Retrieving a few extra candidates up front leaves room to discard any that fail the second check without returning too few results.
3. Inference Is the Subtler Problem
Fixing document-level permissions solves the obvious leak. A harder one remains.
Imagine a user is allowed to see every document they retrieve. Individually, each is fine. But the assistant can summarize, compare, and connect them. A user with access to meeting notes, a project roadmap, and a staffing spreadsheet might ask a question whose answer reveals that a reorganization is coming, even though no document says so.
Nothing was breached in the traditional sense. Every access was authorized. Yet the conclusion was something the organization never intended to disclose to that person.
This is the same dynamic that makes “anonymized” datasets risky: individual fields look harmless, but combining them reveals more than any one of them does. AI makes that combination cheap, fast, and available to anyone who can type a question.
A useful threat model asks:
Can a user reconstruct a sensitive fact by asking several narrow questions?
Can the assistant aggregate information across sources that were never meant to be correlated?
Can someone infer the contents of restricted documents from the shape of the answers, such as what the assistant refuses to say?
Can repeated queries slowly extract what a single query would not?
There is no single fix, but there are meaningful mitigations: limit which collections can be combined in one query, apply sensitivity labels that restrict aggregation, and cap how much text from high-sensitivity sources can enter a single prompt.
4. Untrusted Content Is Also an Attack Surface
Retrieval adds another risk: the documents themselves can contain instructions.
If your system indexes web pages, emails, support tickets, or shared documents written by outside parties, an attacker can plant text designed to manipulate the model. A sentence telling the assistant to ignore its previous instructions and reveal the contents of retrieved HR documents can sit quietly in a ticket until a relevant query pulls it into context.
This is commonly called indirect prompt injection, and it is covered in OWASP’s guidance for LLM applications. The defense is architectural, not rhetorical:
Treat retrieved text as data, never as instructions.
Give the model the minimum privileges needed for the task.
Keep sensitive tools and data out of any context that also includes untrusted content.
Require human confirmation before the assistant takes consequential actions.
The reasoning mirrors classic injection defenses: don’t let data be interpreted as commands, and don’t give a component more power than its job requires.
5. Logs Are a Dataset Too
Teams often secure the knowledge base carefully and then log everything about how it is used.
Prompts, retrieved chunks, and model outputs are valuable for debugging and evaluation. They are also a concentrated record of what people asked and what the organization knows. Questions reveal intent. A log of one employee’s queries can show what they are worried about, what they are working on, and what they are planning to do next.
Treat AI logs with the same care as the underlying data:
Minimize: Log identifiers and metadata by default, not full text.
Redact: Strip sensitive fields before storage.
Restrict: Limit who can read prompt logs, and audit that access.
Expire: Set retention limits, and delete on schedule.
If you wouldn’t give a developer unrestricted access to the source documents, don’t give them unrestricted access to a log that quotes them.
6. A Practical Checklist
Before shipping a retrieval-powered feature, work through these questions:
Does retrieval run as the end user, or as an all-powerful service account?
Is authorization enforced before content enters the prompt?
Do chunks carry permission metadata, and is it checked at query time?
What happens when a document is unshared or deleted? How quickly does the index reflect it?
Can answers combine sources that should not be combined?
Is retrieved content treated as untrusted input?
What can the model do beyond generating text, such as call tools, send messages, or write data?
What do we log, who can read it, and when is it deleted?
Have we red-teamed the system with questions designed to extract restricted information?
Can we disable the feature or revoke access quickly if something goes wrong?
None of these questions is exotic. Most are standard security thinking applied to a new kind of system.
Conclusion: Authorize the Answer, Not Just the Document
The promise of AI assistants is that they make an organization’s knowledge easy to use. The danger is that they make an organization’s knowledge easy to over-use.
Traditional access control asks whether a person may open a file. AI-era access control must also ask what a person may learn, given everything the system can read, connect, and say.
So enforce permissions before retrieval. Keep authorization data attached to your content. Treat everything the model reads as untrusted. Log less, and protect what you log. And remember that a helpful answer assembled from authorized parts can still be an unauthorized disclosure.
The best AI features won’t be the ones that can see the most. They’ll be the ones that know exactly what they should and shouldn’t say, and that were built that way from the start.
Further Reading
OWASP, Top 10 for Large Language Model Applications (includes sensitive information disclosure and prompt injection)
NIST, Privacy Framework
NIST, AI Risk Management Framework
These resources offer background. The analysis and recommendations above are original synthesis. Check each link and current version before publishing, since I haven’t verified live URLs.
