One malicious document can poison a RAG system

You must now treat your knowledge base as a two-layer system: document integrity at ingestion, and vector index integrity in retrieval. A single malicious document can steer a RAG assistant's answers, so you need recorded provenance, version control and hash verification before indexing, plus continuous monitoring of embeddings and retrieval behaviour.

The prompt is an analysis of 3 November 2026 of poisoning attacks against retrieval-augmented generation systems, which argues that a single crafted document is sufficient to compromise a RAG system's outputs. Research demonstrates that an attacker need not flood a knowledge base with hundreds of false entries; one carefully constructed malicious text can steer the answers a RAG assistant produces. In our assessment, this means that any organisation operating a RAG system over internal documents now faces a concrete attack surface that demands controls at two distinct points: the document layer and the vector retrieval layer together.

How does a single document compromise a RAG system?

Retrieval-augmented generation works by having a language model first retrieve relevant passages from a knowledge base, then use those passages to formulate its answer. The vulnerability lies in the chain that follows document upload. 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 surfaced for a given question. Each link in that chain influences whether a poisoned chunk reaches the final answer. Because the harm emerges not from the document alone but from the entire pipeline, a document integrity check at upload is necessary but insufficient.

What determines whether a poisoned document will actually influence the answer?

Research examining 432 different configurations shows that vulnerability depends on your specific setup. The likelihood that a poisoned passage is retrieved and influences output is linked to the retriever architecture, the dataset, retrieval depth and the generator model. Critically, retrieval depth—often expressed as top-k, the number of retrieved passages returned—increases the probability that poisoned passages are retrieved. These effects arise from interactions between components, which means no universal benchmark exists. How vulnerable your system is depends on your own configuration choices, particularly those affecting how many passages the retriever returns.

What controls must you demonstrate across the pipeline?

1. Record document provenance before indexing — maintain a documented chain of custody showing source, approval date and approver for every document added to the knowledge base.
2. Calculate and store cryptographic hashes — compute a hash for each approved document version and verify it matches before proceeding to embedding and indexing.
3. Monitor vector index mutations — establish continuous monitoring of the vector index to detect unexpected changes, new embeddings or alterations to stored representations.
4. Track retrieval behaviour and depth settings — record which retrieval depth (top-k value) your system uses and log which passages are retrieved for each query, making retrieval decisions auditable.
5. Enforce source attribution in responses — require that every answer includes verifiable attribution to source documents with their hashes, and block responses that fall back to model training data when retrieval or integrity checks fail.

What does document integrity actually prove?

A matching hash proves that a document is identical to an approved version. It does not prove that the content is correct, safe or free from malicious intent. Provenance and integrity are distinct from truth. This distinction matters because it shapes who bears responsibility for what. A hash provides traceability; it does not provide verification. A lawyer cannot treat a RAG answer as verified without source attribution and document hash. A CISO must require that every indexing has recorded provenance, approval and hash before a document proceeds to embedding. A director must allocate budget for monitoring index mutations and retrieval behaviour, not only for upload checks. A configuration choice such as top-k directly touches security risk and belongs in the system's risk record, not only with the development team.

Tooling can enforce these controls and flag deviations, but the decision about what retrieval depth your system should use, what documents belong in your knowledge base, and what to do when an integrity check fails remains yours. Automation can make those decisions visible and auditable; it cannot replace the professional judgement required to set acceptable risk.