What is RAG poisoning?

RAG poisoning is when someone deliberately sneaks false or malicious documents into the knowledge base a RAG system searches, so the system retrieves that planted content and repeats it back as fact.

Why does RAG poisoning work so well?

The entire point of RAG is to make a model trust what it retrieves more than what it learned during training. That is usually a good thing — it is how RAG keeps answers current and grounded. But flip it around, and that same trust becomes the attack surface.

A model that is normally cautious will confidently repeat a lie if that lie showed up in a document it just pulled from your database.

How is it worse than plain misinformation?

A poisoned document can carry hidden instructions buried in its text — a prompt injection delivered through retrieval instead of through the user's chat box. The model reads the document, follows the buried instruction, and the attacker never had to touch the actual prompt. So the same channel that is meant to ground the model in trusted facts can quietly hand it commands it was never given by a person.

Which knowledge bases are most at risk?

The risk scales with how open your knowledge base is: the more people and automated sources can write into it, the more places an attacker has to slip in a poisoned document. Common easy entry points include:

• Public wikis anyone can edit
• User-submitted content
• Scraped web pages pulled in automatically
• Shared company drives where too many people have edit access

How do you defend against it?

Defenses focus on not treating retrieval as automatically trustworthy:

• Vet and restrict who can add or edit content in the knowledge base
• Monitor retrieved content for anomalies or sudden changes
• Treat retrieved text as untrusted input the model should weigh, not blindly obey

The goal is not to stop retrieving — it is to stop assuming that whatever comes back is automatically true.