Guides › Secure RAG › Does RAG leak data?

Does RAG Leak Data?

Hunter Moore, Founder and CTO · Updated August 4, 2026

Yes. A retrieval-augmented generation pipeline leaks data whenever it returns a chunk originating from a document the person asking was not entitled to open. It usually happens without an exploit, without an anomaly in the logs, and without anyone noticing, because the system is working exactly as built.

At a glance
  • Not an exploit. Most leakage is the pipeline working exactly as built, on permissions that were already too broad.
  • Four routes. Unentitled retrieval, direct access to the index, aggregation, and derived copies such as caches and summaries.
  • Encryption never engages. Leakage happens through an authorized query against a decrypted index, so encryption at rest does not apply.
  • Measure your own rate. Run known queries as several test identities and compare what was retrieved against what each identity was entitled to.

That is the short answer. The longer answer is that there are four distinct routes, they have different causes, and only one of them looks anything like an attack.

What are the four routes RAG leaks data through?

Retrieval returns a chunk the user should not see. The vector index is queried directly, bypassing the application. Content that was harmless in aggregate becomes identifying once retrieval lifts it out of context. Or the material was copied into an embedding store, a cache, a log or an evaluation set that inherited none of the original controls.

1. Retrieval returns an unentitled chunk

This is by far the most common and gets the least attention, because it does not look like a security event. Someone asks a reasonable question, the retriever does its job, and the answer is built partly from a compensation review, a patient record or an unannounced acquisition.

The cause is almost always the same. The index was built by a connector authenticating as a service account with broad read scope, because that is the only practical way to build a complete index on a schedule. The index then holds the union of what everyone can see. Unless retrieval re-checks entitlements against the requesting identity at query time, the assistant serves that union to whoever asks.

2. Direct access to the index

Vector databases are frequently deployed with weaker controls than the systems whose content they now hold. The 2025 OWASP Top 10 for LLM Applications lists this territory as LLM08, Vector and Embedding Weaknesses, and calls out multi-tenant context leakage specifically, where embeddings belonging to one group are returned in response to another group's queries.

3. Aggregation

A paragraph that was unremarkable inside a 200-page report becomes identifying when retrieval extracts it and places it beside three other fragments. Retrieval is a joining operation, and joins create disclosure that no single source had on its own. This one is hard to test for and routinely missed in reviews.

4. Derived copies

Summaries, caches, conversation history, agent memory and evaluation datasets all inherit content from the index and rarely inherit its permissions. OWASP moved Sensitive Information Disclosure up to LLM02 in the 2025 list, from sixth place in the previous edition.

A RETRIEVAL PIPELINE, FOUR STAGES Source systems connectors, drives, wikis Index chunks and embeddings Retrieval top-k similarity search Model context answer generation Route 1 Over-broad ingestion The connector authenticates as a service account with read access to everything, so content that should never be indexed is indexed anyway. Route 2 Permissions not carried Chunks inherit the text but not the source ACL, so the retriever has nothing to filter on even if it wanted to. Route 3 No check at query time Similarity search runs against the whole index, then results are trimmed or not. Ranking already saw everything. Route 4 Copies keep the content Chat history, caches, evaluation sets and logs retain retrieved text and rarely inherit its restrictions.
None of these four routes requires an attacker. Each is a default behaviour of a retrieval pipeline that was assembled for accuracy rather than for entitlement.

Is this a vulnerability or a configuration problem?

Usually neither, in the strict sense. Most RAG leakage is a permission problem that predates the AI deployment. Content was already over-shared across SharePoint, Confluence, Google Drive or a data lake, and nobody noticed, because finding a mislabeled file required knowing it existed.

Is it a reportable breach

Deciding what to call this internally does not settle whether the exposure has to be reported. Those are two separate calls, and the second one is not the retrieval team's to make.

Semantic search removes that friction. An index returns documents by meaning rather than by path, so the obscurity that was quietly doing access-control work stops working. The pipeline did not create the exposure. It made it reachable in one query.

The pipeline did not create the exposure. It made it reachable in one query.

This distinction matters when you go to fix it, because it determines who owns the remediation. If the underlying document was world-readable in the source system, tightening the retriever treats the symptom.

INDEX TIME QUERY TIME General wiki open to all staff Finance drive controller group only HR case files two named people One index the union of all three built by one service account Nothing in the index records who is allowed to see what. Every chunk is now equally reachable by a similarity score, regardless of where it came from. Employee entitled to: general wiki asks a normal question Similarity search scores every chunk in the index, not just eligible ones HR detail in the answer no error, no alert, no entry in the source system's access log The employee did nothing unusual. The retriever behaved exactly as designed.
The index is built once, with broad credentials. The question is asked later, by someone narrower. Unless entitlements are resolved at that second moment, the gap between the two is the leak.

Does encryption or a network boundary stop it?

No. Encryption at rest protects the vector store against someone who steals the disk. Retrieval leakage happens through an authorized query against a decrypted index, so encryption never engages. Network isolation keeps the retrieval service off the public internet, which does nothing about a legitimate request from a legitimate employee.

Both are worth having for their own reasons. Neither is positioned to answer the question that leakage turns on, which is whether this particular user was entitled to this particular chunk. Those controls are covered in more depth under vector database security.

How do you tell whether your RAG system leaks?

  1. Build a ground-truth entitlement matrixTake the entitlements from your source systems.
  2. Write queries that target restricted materialEach query's answer should live in a document only some identities may open.
  3. Run each query as several test identitiesCover the range of entitlements you need to tell apart.
  4. Compare retrieved against entitledThe output is a leak rate you can track.

The full procedure, including the step that determines whether the test is even possible, is written up as a RAG leakage self-test. The prerequisite is that your application logs which chunks each query retrieved, tied to the requesting user. If it does not, that gap is the first finding.

What actually prevents it?

Two controls carry most of the weight. Entitlements evaluated per query against the requesting identity, ideally as a pre-filter that constrains the candidate set before similarity search rather than a post-filter applied to results. And content decisions made at ingestion, before text becomes an embedding, so every downstream copy inherits them.

The reason ingestion matters is that a chunk, an embedding, a cache entry, a summary and a fine-tuning example all derive from what was ingested. Fixing content once upstream is cheaper and more durable than governing five copies. Transformation is the workable form of this, because removing sensitive values breaks the documents, and a contract with holes in it stops answering questions about the contract.

Hardshell operates at that ingestion layer, upstream of training, fine-tuning and retrieval, inside the customer's own environment. The full control map, including what belongs at retrieval and at the context boundary, is in how to prevent RAG data leakage.

Frequently asked questions

Does RAG leak data more than fine-tuning?

Differently, not necessarily more. Retrieval keeps content out of model weights but creates a live query path into your corpus that runs at user speed. Fine-tuning does the reverse, encoding content permanently into weights where extraction research has repeatedly recovered it. The comparison is set out in RAG vs fine-tuning for sensitive data.

Can a guardrail catch RAG leakage?

Partially. Output inspection catches structured patterns like card numbers and national identifiers with decent recall. It performs much worse on contextual sensitivity, such as an internal forecast or a named employee's performance note, because there is no pattern to match. It also runs after retrieval already placed the content in the model's context.

Is RAG leakage a reportable data breach?

It can be. A breach is normally unauthorized access to a system, while this is a system working as designed and returning content to someone with no right to it. Regulators tend not to care about the mechanism. If identifiable personal data reached someone who should not have received it, notification duties can still apply. Treat it as a disclosure and involve counsel rather than filing it as a bug.

How common is it?

There is no credible public baseline, and anyone quoting a precise industry-wide figure is guessing. What is well established is that the preconditions are close to universal, because broad-scope indexing connectors and post-filtered retrieval are the default in most RAG stacks. The honest answer is to measure your own rate rather than trust a benchmark.

Does using a private or self-hosted model fix it?

No. Where the model runs has no bearing on which documents the retriever selected. A fully self-hosted stack with an over-broad index leaks exactly the same content to exactly the same people. It removes a different risk, which is third-party processing of your prompts.

Sources

OWASP, OWASP Top 10 for LLM Applications, 2025. Cited above as LLM02, Sensitive Information Disclosure, and LLM08, Vector and Embedding Weaknesses.