Your RAG Deployment Is Leaking Documents You Didn't Mean to Share
Most enterprise AI assistants are built on the same basic architecture. The organization's internal documents get converted to vector embeddings and stored in a database. When a user asks a question, the system retrieves the most semantically similar document chunks and hands them to the language model alongside the question. The model synthesizes an answer and cites its sources. It works well.
The part that is working less well is the assumption, implicit in almost every RAG deployment I have reviewed, that access controls from the source documents carry forward into the vector database. They rarely do.
How RAG Actually Works
Retrieval-Augmented Generation solves a real problem. Language models have context windows, not encyclopedias. You cannot inject 50,000 internal documents into a single prompt. RAG addresses this by indexing documents as vector embeddings, retrieving only the most relevant chunks at query time, and injecting those chunks into the model's context. The model answers based on retrieved content rather than training data.
The elegance of the approach is genuine. So is the attack surface.
The Authorization Gap
When documents are ingested into the vector database, their access controls typically do not travel with them. In the source system, an HR policy document might be accessible only to HR. In the vector database, that document's embedding is indexed alongside everything else. When a user asks a question that semantically matches the HR document, the retrieval system surfaces it. The model incorporates that content into its response. The user, who was never supposed to see the document, now has its contents delivered in friendly, conversational prose.
This is not a subtle vulnerability. It is a direct violation of the access control model the organization spent years building, executed by the AI assistant the organization deployed to improve productivity.
The fix exists: capture document-level access metadata at ingestion time, store it alongside the embedding, and filter retrieval results against the authenticated user's permissions before injected chunks reach the model. It requires building infrastructure that most deployment timelines do not budget for. So it does not get built, and the gap sits there.
Document Poisoning
The other underappreciated attack in RAG pipelines runs in the opposite direction. Instead of extracting data you should not see, an attacker inserts instructions the model should not follow.
RAG pipelines ingest documents from internal systems: wikis, shared drives, ticketing systems, project management tools. In most deployments, anything the ingestion process can read gets indexed. That means anyone with write access to a source document can inject content into the AI's knowledge base.
The attack is conceptually simple. Write a document that contains adversarial instructions embedded in plausible-looking content. The retrieval system surfaces the document in response to relevant queries. The language model processes the malicious instructions alongside legitimate user questions. The model acts on them.
This is a variant of indirect prompt injection. The difference in a RAG context is the delivery mechanism: not a webpage or email the model happens to process, but a document that an insider - or an external attacker who has compromised a document management system - deliberately placed into the knowledge base.
The vector database does not evaluate document trustworthiness. It finds semantic similarity. If the malicious document is written to match common query patterns, it gets retrieved reliably.
Multi-Tenant Isolation
Multi-tenant RAG deployments add another dimension. If multiple teams or customers share the same underlying retrieval infrastructure, inadequate namespace boundaries allow queries from one tenant to surface documents belonging to another. A filter applied after retrieval can still expose content that should have been invisible. The isolation needs to govern which namespace the retrieval operates against, before the query runs.
What Good Looks Like
Audit your ingestion pipeline with the same scrutiny you would apply to any system that processes untrusted input. Document provenance matters: who can write to source systems, who can add content to the ingestion queue, and whether there is a review step before documents become part of what the AI can say.
Implement access controls at the vector database level. Retrieve metadata alongside embeddings at ingestion. Filter on metadata before retrieved chunks reach the model context. It is more complex than indexing everything. It is also the only way to make your AI assistant's confidentiality posture match your actual access control model.
Log what gets retrieved. Retrieval logs are your primary detection mechanism for both authorization failures and poisoning attempts. A document being retrieved at anomalously high frequency across diverse query patterns deserves investigation.
Test it. Ask your AI assistant questions designed to surface documents your account should not access. Check whether it follows instructions embedded in documents alongside legitimate content. If either attempt produces the wrong result, you have work to do.
RAG is useful infrastructure deployed with genuine enthusiasm and, in most cases, without the security architecture that a document-access system requires. That is fixable. But only for the teams that know to look.