A RAG assistant can reveal more than any one answer

Retrieval-augmented generation is designed to help an assistant find the right internal knowledge at the right moment. That same usefulness can become a disclosure path when many ordinary-looking questions are allowed to add up.

The security question is therefore larger than “Is this answer safe?” It is also: “What has this person, account, or automated client been able to learn across the whole interaction?”

Research presented at USENIX Security 2026 makes that cumulative risk unusually clear. The researchers built an adaptive system that remembers what a RAG assistant has already revealed, maps the remaining gaps, and chooses each next question to explore a new part of the underlying collection.

What the researchers found

The system, RAGCrawler, treats knowledge-base extraction as a planning problem. Instead of repeating one attack prompt, it builds an attacker-side knowledge graph from earlier answers, estimates which topics are still underexplored, and generates natural-language questions intended to reach fresh documents.

The evaluation used four public corpora spanning biomedical literature, scientific papers, consumer health, and clinical dialogue. For the main experiments, the researchers sampled 1,000 deduplicated documents from each corpus and tested four generator models with a BGE retriever. Each method received a budget of 1,000 queries.

Across those 16 configurations, RAGCrawler exposed 66.8% of the sampled corpus on average and as much as 84.4% in one configuration. The strongest prior baseline averaged 46.1%. The researchers also tested another retriever, a smaller attacker-side model, query rewriting, and multi-query retrieval. The absolute results changed, but the adaptive approach remained effective.

These are controlled experiments, not evidence that a named enterprise RAG system has been breached. “Coverage” is the researchers' measurement of documents exposed through retrieval in their setup; it does not mean that every byte of every document was reproduced. Production results will depend on corpus structure, retrieval depth, model behavior, authorization, rate limits, monitoring, and what the application returns to the user.

The useful finding is the shape of the problem. The attack succeeds through a sequence of plausible queries whose combined direction becomes visible only over time. In the final paper's defense evaluation, a round-level LLM input filter flagged just 0.03% of RAGCrawler's queries. Looking at each question in isolation missed what the sequence was doing.

A privacy boundary that remembers

Many RAG controls are local. They decide whether the current query looks unsafe, which documents match it, and whether the current answer contains a prohibited value. Those checks matter, but they can approve a long series of individually reasonable disclosures without recognizing their cumulative effect.

Query rewriting is not necessarily a remedy. In the study, rewriting sometimes helped the attack by producing clearer queries that reached a broader set of documents. Multi-query retrieval also increased the diversity available from one request. Features built to improve relevance can increase exposure when they are not paired with an equally deliberate disclosure boundary.

That boundary should begin before generation. If a requester is not authorized to receive a document, the retriever should not place that document in model context and hope the model keeps it hidden. Access decisions should follow the requesting identity and the source document or chunk, including after indexing, copying, and re-embedding.

What operators should examine now

First, verify retrieval-time authorization. Test that permissions are enforced for the real requesting identity and remain attached to derived chunks and indexes. Include revoked access, shared documents, group changes, and cross-tenant attempts.

Second, evaluate sequences rather than prompts. Red-team with adaptive, multi-turn questions that change wording and topic while accumulating knowledge. Measure which sources and unique regions of the corpus become reachable over time, not only whether one response contains a familiar secret pattern.

Third, make retrieval depth and answer detail explicit security choices. Returning more context can improve answer quality, but it also gives each query more chances to expose new material. Tune the amount retrieved, quoted, summarized, and retained to the sensitivity of the collection and the user's task.

Fourth, monitor cumulative behavior at a meaningful identity boundary. Session resets alone are weak if the same account, token, application, or coordinated set of clients can continue the exploration. Rate, novelty, document coverage, repeated semantic expansion, and unusual access breadth can be more informative together than any single “malicious query” score.

Finally, retain enough evidence to investigate. An operator should be able to connect the requester, query sequence, retrieved document identifiers, authorization decisions, generated answers, policy outcomes, and any later revocation—without turning the evidence system into a new store of unnecessary sensitive content.

The PrivacyFirst view

A RAG system does not disclose information one answer at a time. It discloses along a path.

That path needs memory, identity, and limits of its own. A helpful answer can be perfectly reasonable in isolation and still be one more step toward reconstructing something the requester was never meant to see as a whole.