RAG poisoning: prompt injection through knowledge bases

How retrieval-augmented generation works

A RAG system indexes a collection of documents, emails, tickets or pages in advance. When a user asks a question, it searches that index for the passages most similar to the question, takes the top handful, places them in the model’s context window alongside the question and asks the model to answer from them. The design is popular because it grounds answers in real material and lets an assistant work with private information without retraining.

The weak point is the join. Retrieved passages arrive in the context as plain text, with no reliable marker of where they came from and no difference in standing between a policy the company wrote and a message a stranger sent. The model reads them the way it reads everything, and, as the UK National Cyber Security Centre notes, nothing inside it separates data from instructions.

Why attackers favour it

Four properties make a retrieval store a better target than a chat box. Persistence: a poisoned document sits in the index indefinitely, and nobody re-reads indexed content. Targeting: relevance ranking is public knowledge, so an attacker writes for the questions the victim will ask, which is exactly how the EchoLeak email reached Microsoft 365 Copilot in 2025. Scale: one document can influence every query that retrieves it, across every user of the store. Stealth: the user never sees the retrieved passages, only the answer built from them.

Greshake and colleagues anticipated this in February 2023 under the heading of information ecosystem contamination, and OWASP’s LLM01:2025 scenarios include the case directly: a malicious modification to a document in a repository that a RAG application relies on.

What the documented cases had in common

In EchoLeak, retrieval was the delivery mechanism: an email crafted to look like business guidance was surfaced for an unrelated later question, and the assistant followed the instructions it contained. In PromptArmor’s August 2024 Slack AI case, search-based retrieval assembled a private message containing an API key and an attacker’s instructions from a channel nobody else had joined into one context, and the answer leaked the key through a link. In Invariant Labs’ May 2025 GitHub case, the store was a public repository’s issues, which an agent retrieved and obeyed.

Each case had a store that anyone could write to, a retrieval step that mixed trust levels, and a model that acted on what it retrieved. None of them involved a bug in the retrieval code. The attackers wrote text and waited.

Who can write to your corpus

Before defending a store, list its writers. Shared drives and wikis accept edits from every employee and often from contractors. Ticketing systems accept text from customers. Mailboxes accept text from the world. Public web crawls accept text from anyone with a page. Partner feeds, uploaded files and scraped documentation each add a class of author. Every one of those authors can address the model, and most ingestion pipelines review none of what they take in.

Defences specific to retrieval

Segment the corpus by trust and retrieve accordingly. Content from outside the organisation should not sit in the same index as secrets, which is the Slack lesson, and the assistant answering from a low-trust segment should hold the privileges of that segment, which is the NCSC’s rule applied to retrieval. Carry provenance through to the model: the spotlighting techniques published by Microsoft researchers in 2024 mark where retrieved content begins and ends so that the model can weigh it, cutting the success of indirect injection sharply in their tests, though not to zero.

Review at ingestion, not only at query time. Strip hidden HTML, comments and invisible characters from documents as they are indexed, and scan them for instruction-shaped passages before they can be retrieved; the checks this site’s scanner performs on a pasted document are the same checks an ingestion pipeline should perform on every document it admits, with hard negatives kept so that the pipeline does not reject every security policy in the company. Re-scan when a document changes. Keep high-authority collections under human review, and put confirmation and egress controls in front of anything the assistant does with what it retrieved.

What a clean scan does and does not mean

A scan for injection indicators finds text that is shaped like an instruction or hidden from a reader. It does not find a document that simply states something false, and a false statement in a trusted store is poisoning too; that is a question of corpus governance, not of detection. It also cannot know which segment a document belongs in or what the assistant may do with it. A clean scan of a document is a good reason to admit it to a store whose readers are appropriately limited, and no reason at all to give that store’s assistant the keys to everything else.