Retrieval-Augmented Generation (RAG) is regarded as a pragmatic way to connect language models to current, domain-specific knowledge: instead of packing everything into the model, the system retrieves relevant passages from a knowledge base and uses them as context. A recent attack study, however, shifts attention to a component that is often treated as passive storage: the knowledge base itself. The paper Knowledge Poisoning Attacks on Medical Multi-Modal Retrieval-Augmented Generation, published via arXiv and the ACL Anthology, shows that an attacker does not need to break the model at all. Anyone who can inject faulty entries into the retrieval layer has enough influence to tip downstream answers.
The attack: hijacking retrieval without touching the prompt
The core of the study is that the attack is query-agnostic. The researchers inject misinformation into a medical multimodal knowledge base and use visual triggers to hijack retrieval. As a result, the system retrieves clinically plausible but factually incorrect passages and incorporates them into the answer. According to the paper, this works across multiple models and datasets, and it affects both retrieval and generation behaviour.
That is precisely what makes this threat so difficult in a high-trust domain. An answer that looks medically credible is not automatically corrected by a user who trusts the context. The attack does not need to manipulate the prompt; poisoning the source the system draws from is enough. And the researchers note that stealthy poisoning remains possible, even when simple defences are applied.
This class of attack does not stand alone. The ACL study The good and the bad: Exploring privacy issues in retrieval-augmented generation (RAG) from 2024 had already shown earlier that retrieval-augmented systems have their own attack surface. The new medical study builds on this and makes it concrete for a domain where mistakes have direct consequences.
Not just bad data, but the architecture around it
The next question is why some RAG systems are more vulnerable than others. The arXiv study Influence Factors on RAG Poisoning substantiates that poisoning is not a single model problem, but depends on the interaction between dataset, retriever type, retrieval depth, database composition, chunking and generator.
Two design choices stand out. First, the retrieval depth: the more passages a system retrieves per query, the greater the chance that a poisoned passage ends up in the context. Second, the retriever type: dense retrievers and graph-based retrievers respond differently to the same poison set than a classic BM25 approach. In other words: the same poisoned knowledge base yields a different exposure, depending on how you search it.
That makes RAG poisoning primarily an architectural question. Whoever designs context selection, retrieval depth and database composition partly determines how vulnerable the system is to manipulated sources. That is not a problem you solve afterwards with a single filter.
Metadata as a hidden channel
Moreover, manipulation need not be visible. The arXiv paper Hidden in the Metadata: Stealth Poisoning Attacks on Multimodal Retrieval-Augmented Generation shows an attack in which the metadata of image-text entries are manipulated, while the visual content is left untouched. The image is correct, but the associated descriptive fields steer retrieval in the wrong direction.
The implication is uncomfortable: defences that look only at visible content, or that rely on simple filters, fall short. A knowledge base that looks clean on inspection may nevertheless be compromised via seemingly innocuous metadata fields.
The sector responds with layered defence
That the problem is being taken seriously operationally is evident from defensive research. The arXiv paper RAGuard: A Layered Defense Framework for Retrieval-Augmented Generation Systems Against Data Poisoning builds a layered defence against corpus poisoning and thereby treats poisoning as a recognised security class. An important lesson from that work is that defence only becomes effective when it is applied to the retrieval layer itself — retriever hardening and document filtering are not a side issue, but the place where the attack takes place.
The common thread through these studies is clear: knowledge bases in RAG systems are not static reference lists, but an active attack surface that you must segment, monitor and verify.
What this means for work with sensitive information
For organisations working with confidential or high-trust information, attention thereby shifts to provenance and verifiability. If retrieval alone is enough to get faulty content into an answer, then the question is not only "what does the model say", but "where does this context come from and is it verifiable".
This is the context in which a verification layer such as Vera can be relevant. Vera is not a chatbot and not its own language model, but a privacy-focused verification layer that can route a task through selected independent AI models and expose verification steps, corrections, disagreements and sources for inspection. That does not certify that an answer is correct or true, but it can give more insight into which sources underpin an answer — precisely the point where poisoning hides.
In addition, there is the handling of the source documents themselves. The Semantic Privacy Shield is designed to replace sensitive document values with synthetic, session-only equivalents on EU infrastructure before AI processing, after which the original values can be restored locally. The workflow is fail-closed: if the privacy check fails, the document is not sent onward. That does not solve RAG poisoning, but it underlines the same basic attitude that emerges from the research sources: treat the data chain as something you deliberately control.
The studies from 2024 through to 2026 together point in one direction. Anyone deploying RAG on sensitive information would do well to make knowledge bases, retrieval sources and document metadata auditable before the system goes into production. The professional final judgement always remains with the user; technology can support control, not replace it.