One malicious document can poison a RAG system: check both the source and the vector index

Researchers showed with CorruptRAG that a single crafted document can already be enough to make a RAG assistant give misleading answers. So protect your knowledge base on two levels: check the provenance, version and hash of every document before indexing, monitor embeddings, vector index and retrieval behaviour, and let the system stop when an integrity check fails.

The study Practical Poisoning Attacks against Retrieval-Augmented Generation describes CorruptRAG, an attack in which a single poisoned text is injected. The core point: an attacker does not have to flood a knowledge base with hundreds of false pieces. One carefully crafted malicious document can already be enough to steer the answers of a RAG system. RAG stands for retrieval-augmented generation: a language model first retrieves relevant passages from its own knowledge base and uses them to formulate its answer. That makes the subject concrete for any organisation that lets such an assistant search through internal documents.

What exactly does the CorruptRAG study show about RAG poisoning?

The ACM study demonstrates that a single poisoned text can practically influence a RAG system, without the attacker having to inject many documents. According to the study, a single poisoned text can make the attack relatively quiet compared with large-scale injection campaigns; the attacker still needs a means of placing content into the relevant knowledge database or ingestion pipeline. The study thereby describes a practical attack vector, not merely a scenario in which multiple documents are required.

The second relevant finding comes from the study Influence Factors on RAG Poisoning, a full-factorial investigation with 432 configurations. It shows that the likelihood that a poisoned passage is actually retrieved and influences the answer is linked to the retriever architecture, the dataset, the retrieval depth and the generator. A greater retrieval depth — in many implementations expressed as a higher top-k, the number of retrieved passages — according to the study increases the likelihood that poisoned passages are retrieved. The researchers stress that the effects arise from interactions between those components. In our assessment, this means that these figures are not a universal benchmark: how vulnerable your system is depends on your own configuration.

Why is protecting the source file alone not enough?

Because the harm does not arise in the document alone, but in the chain that follows it. A document is split into chunks, converted into embeddings (numerical representations that measure semantic similarity) and stored in a vector index. The retriever then determines which chunks are retrieved for a question. Each of those links influences whether a poisoned chunk reaches the answer.

Our editorial interpretation: a knowledge base is only defensible once document integrity and the derived vector and retrieval layer are monitored together. Whoever checks only the upload guards the front door but leaves the corridor behind it unwatched. And an important nuance: a matching hash only proves that a document is identical to an approved version, not that the content is correct or safe. Provenance and integrity are something other than truth.

Which integrity checks do OWASP and AWS advise for a knowledge base?

The OWASP Foundation’s RAG Security Cheat Sheet covers security controls across the RAG pipeline, including document ingestion, provenance, vector storage, retrieval and response handling. Its recommendations, together with AWS guidance, support a practical framework for protecting documents and monitoring derived vector and retrieval layers. Taken together, these sources support the following practical control framework, supplemented where indicated by our analysis:

• Document level: our recommended implementation is to record provenance, uploader, approval, version, hash and file type before indexing; scan for hidden instructions; and route changes through a separate review and signing procedure.
• Vector level: as a practical implementation of the OWASP controls, keep the embedding model and version, chunk relationships, namespaces, access metadata per vector chunk and index mutations auditable; keep snapshots and logging of index changes.
• Access and provenance: filter access before retrieval and, as our recommended audit practice, attribute answers to their sources and include the corresponding document hash where available.
• Detection and recovery: OWASP’s framework supports flagging unusual index or retrieval changes, cascade deletion and use of a protected manifest with document hashes.
• Fail-closed behaviour: following the OWASP control model, stop the answer when a hash or access check fails; our recommendation is not to fall back automatically on the model’s memory.

That last point deserves emphasis. Answers without verifiable source attribution, or answers after retrieval or integrity checks fail, must not quietly fall back on what the model 'knows' from its training. It is precisely then that the difference between a checked and an unchecked answer disappears from the user's view.

What does this mean for directors, lawyers and CISOs deploying a RAG assistant?

Our analysis: because a single crafted document can already have effect according to the ACM study, a CISO must require that every indexing has a recorded provenance, approval and hash before a document proceeds. Because the second study shows that retrieval depth increases exposure, a configuration choice such as top-k directly touches the security risk; therefore that choice belongs in the system's risk record, not only with the development team. Because a matching hash proves no truth, a lawyer must not treat a RAG answer as verified without source attribution with document hash. Because the ultimate exposure is partly determined by the vector and retrieval layer, a director must free up budget for monitoring index mutations and retrieval behaviour, not only for upload checks.

In practical summary, in order of introduction:

1. Record provenance, version and hash for every document and set up a signing procedure for changes.
2. Make the configuration of the retriever, retrieval depth and vector index part of your AI security control for AI systems.
3. Require source attribution with document hash in every answer and block answers that do not meet this, in line with the principle of documenting defensible audit evidence.
4. Monitor index mutations, keep snapshots and prepare cascade deletion, so that you can roll back in the event of an incident, as with an incident-response playbook for AI agents.

The open question remains exactly how the interaction between the retriever, retrieval depth, dataset and generator determines the effectiveness of an attack. That dependency means you must test your own setup, in line with the idea that an internal provenance record that does not prove correctness does provide traceability.

Sources: The article draws on the ACM study CorruptRAG, the arXiv research Influence Factors on RAG Poisoning, the OWASP RAG Security Cheat Sheet and the AWS Prescriptive Guidance on data in generative AI.