Your RAG corpus is extractable.

A company ships an internal assistant over its private corpus — contracts, support history, a decade of proprietary documentation. The security work is done properly. The vector store is encrypted at rest. Access to the database is locked down and logged. A penetration test of the infrastructure comes back clean. The corpus is, by every check the team ran, safe.

Months later a competitor is asking suspiciously well-informed questions, and an investigation turns up the mechanism. Someone with nothing but an account on the public assistant — the same chat box every employee uses — has been asking it ordinary-sounding questions, thousands of them, and reassembling the answers into a faithful copy of large parts of the corpus. They never touched the database. They never needed to. The system handed them the corpus one answer at a time, because handing out the corpus one answer at a time is exactly what the system was built to do.

This post is about the RAG privacy threat that the encrypted database does not address, because it is not a threat to the database. It is a threat through the front door.

At-rest encryption is not the threat model

There are three different privacy questions you can ask about a retrieval-augmented system, and teams routinely answer two of them and assume they have answered the third.

The first is the corpus at rest: is the knowledge base encrypted, access-controlled, and audited as a data store? The second is the query: when a user asks something, does that query leak to a model provider or a third party it should not reach? Both are real, both are well understood, and both have standard answers — disk encryption, tenant isolation, a self-hosted or contractually-bounded model.

The third question is the corpus via the answer, and almost nobody draws it as a boundary. A retrieval system’s entire purpose is to pull content out of the corpus and render it into responses. The answer channel is, by design, a pipe from the private corpus to the user. Securing the database while leaving the answer channel unconsidered is locking the warehouse and running a conveyor belt out through the wall. The threat model that matters here is not “can an attacker breach the store.” It is “what can an attacker reconstruct from what the store is designed to emit.”

Query access is a read primitive

Here is the mechanism, stated as plainly as it deserves. A RAG system retrieves chunks relevant to a query and generates an answer grounded in them. That means every answer is, by construction, a partial readout of whatever chunks were retrieved. An adversary who can choose queries is not asking questions. They are issuing reads. Steer the queries methodically and you are paginating the corpus.

This is why corpus extraction does not look like an exploit. There is no payload, no malformed input, no vulnerability in the usual sense. The attacker uses the system exactly as intended and simply does it comprehensively. A RAG deployment is, viewed adversarially, a database that exposes a natural-language read API to anyone who can reach the chat box — and unlike a database, it usually has no notion of row-level authorization, no concept that this asker should not be allowed to read that content. The retriever ranks by relevance. It does not rank by permission.

What the extraction attacks achieve

The reason this is a post and not a thought experiment is that the 2025–2026 literature measured it, and the numbers are not reassuring.

Connect the Dots (arXiv 2601.15678) builds RAGCrawler, which treats corpus extraction as an adaptive coverage problem — each query chosen to reach the parts of the corpus the previous answers did not. Within 1,000 queries it reached 66.8% average corpus coverage, and up to 84.4%. That is roughly two-thirds of a private knowledge base — in the best case, five-sixths of it — reconstructed from a thousand queries that individually look like ordinary use. The paper also reports a 44.9% improvement over prior extraction baselines, and cuts the queries needed to reach 70% coverage by at least 4.03x. The attack is not only effective; it is getting cheaper.

Silent Leaks (arXiv 2505.15420) closes the most comforting escape hatch. You might hope to catch extraction by spotting malicious-looking queries. Its IKEA attack performs implicit knowledge extraction through queries that are benign by construction — nothing about them trips an input filter — and still surpasses prior methods by over 80% in extraction efficiency and over 90% in attack success rate. And it states the consequence without flinching: a substitute system built from the extracted data performs comparably to the original. The adversary does not merely read your corpus. They can stand up your product.

Fine-Grained Privacy Extraction (arXiv 2507.23229) shows the leak is precise, not just bulk. Its black-box framework exploits a knowledge asymmetry — if the RAG system knows something a plain LLM does not, that something came from the corpus — and uses that gap to pull out sensitive sentences specifically, at over 91% extraction in single-domain settings and 83% across multiple domains, generalizing even to domains it was not built against.

These are no longer scattered demonstrations. Benchmarking Knowledge-Extraction Attack and Defense on RAG (arXiv 2602.09319) is the first systematic benchmark of the area, consolidating attacks and defenses, multiple retrieval embeddings, and open and closed generators under one evaluation protocol. When a threat gets its own benchmark, it has stopped being a curiosity and become a property of the architecture.

Why the obvious defenses underperform

The instinct on reading the above is to reach for filters, and the filters underperform for structural reasons worth being explicit about.

Filter the inputs — block malicious queries — and IKEA walks through, because its queries are not malicious. They are benign questions asked in a revealing order, and the order is not visible in any single query.

Filter the outputs — refuse to reveal sensitive content — and the knowledge-asymmetry attack walks through, because the leak is the correct answer. The user asked a legitimate-seeming question, the corpus contains the response, and the retrieval system answering it correctly is the system working as specified. There is no malformed output to catch.

Underneath both is a tension you cannot filter your way out of: a RAG system that reveals nothing about its corpus is a RAG system that does not function. Every answer is a deliberate, controlled leak of corpus content — that is the feature. So the design question was never “leak or do not leak.” It is “to whom, how much, how fast, and observably enough that a thousand-query reconstruction does not pass for normal use.” Defenses that ignore that framing and try to make the answer channel silent are fighting the product.

Defending the answer channel

You cannot close the answer channel. You can make extraction expensive, slow, scoped, and visible. Concretely:

Authorize at retrieval time, per chunk, against the asker. Database-level encryption protects the store from an infrastructure breach; it does nothing about the answer channel. The retriever itself must enforce that this identity is permitted to retrieve this chunk. Relevance ranking is not access control, and bolting permission on at retrieval is the single highest-leverage change.

Segment the corpus. If no single identity can retrieve the whole knowledge base, no single identity can reconstruct it. Partition by sensitivity and by need-to-know so a compromised or hostile account paginates a wedge, not the library.

Watch the query stream. RAGCrawler needs on the order of a thousand systematically-chosen queries. That is a footprint. Per-identity query-rate limits and anomaly detection on query patterns — coverage-seeking traffic looks different from real use — turn a quiet month-long reconstruction into an alert on day one.

Put extraction in the security test suite. Run RAGCrawler-style and IKEA-style attacks against your own deployment and measure the coverage an attacker reaches. An untested corpus is an unknown coverage number, and the unknown number is not low.

Decide the privacy-utility trade deliberately. The most sensitive content should not be sitting in a broadly-retrievable index at all. Gate it behind stronger checks or keep it out — confidential RAG is about protecting the context and not only the query, and the spans inside a chunk that must never surface are the job of PII redaction that does not wreck retrieval. Note too that chunk granularity is itself an extraction surface: smaller chunks give an attacker finer-grained reconstruction, so the chunking decision is now also a privacy decision.

The honest framing — the one the existing confidential-RAG work already takes — is that this is mitigation, not closure. An answer channel that is useful cannot also be silent. What you are buying is cost, scope, and visibility: an attacker who needs far more queries, reaches far less of the corpus, and is seen while doing it.

The checklist

Before you call a RAG corpus private:

• The threat model explicitly names corpus-via-answer extraction, not only corpus-at-rest and query privacy.
• The retriever enforces per-chunk access control tied to the asker’s identity — relevance ranking is not treated as authorization.
• The corpus is segmented so that no single identity can retrieve all of it.
• Per-identity query-rate limits and query-pattern anomaly detection are deployed, sized against a thousand-query reconstruction.
• Extraction attacks are in the security test suite, and you have a measured coverage number for your own deployment.
• The highest-sensitivity content is excluded from the broadly-retrievable index or gated behind stronger checks.
• Chunk granularity is reviewed as a privacy parameter, not only a retrieval-quality one.
• The privacy-utility trade has been decided on purpose, by someone who knows the answer channel cannot be made silent.

If the only privacy control you can point to is “the database is encrypted,” you have secured the warehouse and left the conveyor belt running. The corpus does not leak because someone broke in. It leaks because the system was built to hand it out, and nobody counted the queries.

Reading list

• Connect the Dots: Knowledge Graph-Guided Crawler Attack on Retrieval-Augmented Generation Systems (arXiv 2601.15678) — RAGCrawler reaches 66.8% average corpus coverage, up to 84.4%, in 1,000 queries; corpus extraction framed as an adaptive coverage problem.
• Silent Leaks: Implicit Knowledge Extraction Attack on RAG Systems through Benign Queries (arXiv 2505.15420) — extraction through queries that defeat input filtering by not looking malicious; a substitute system built from the loot performs comparably to the original.
• Fine-Grained Privacy Extraction from Retrieval-Augmented Generation Systems via Knowledge Asymmetry Exploitation (arXiv 2507.23229) — a black-box attack that pulls sensitive sentences specifically, at over 91% extraction single-domain, by exploiting what the RAG system knows that a plain LLM does not.
• Benchmarking Knowledge-Extraction Attack and Defense on Retrieval-Augmented Generation (arXiv 2602.09319) — the first systematic benchmark of the area; the sign that corpus extraction is now a measured property of RAG, not an anecdote.

A penetration test of your infrastructure tells you whether someone can break into the corpus. It tells you nothing about whether they can simply ask for it. Those are different questions, and a RAG system answers the second one every time it does its job.