Retrieval corpus poisoning

What it is

A retrieval system answers from documents it finds at the time of asking. Whoever can place a document where retrieval will find it can influence the answer without touching the model. The planted content may be false information intended for the user, or instructions intended for the model, in which case it is also a carrier for indirect prompt injection. The store's own access controls are covered in vector and embedding weaknesses; poisoning of training data in data and model poisoning.

How it happens

• A page is published on the open web, written to rank for a query the system will search.
• A document is added to a shared drive or wiki that feeds the index.
• A customer-submitted file is indexed with internal material.
• Content is crafted to be retrieved for many unrelated questions.

Why it matters

Users trust a retrieval system because it cites sources. A poisoned source turns that trust into the attack: the false answer arrives with a reference. Detection is hard because the model is working as designed.

Warning signs

• Anyone in the organisation, or outside it, can add to an indexed source.
• Answers cite documents nobody recognises.
• One document is retrieved for an unusually wide range of questions.
• Indexed sources have no owner or review date.

Who owns it

The owner of each source is accountable for its content. The system owner decides which sources are indexed. Engineering restricts retrieval to approved sources and records where each document came from.

In practice

An internal policy assistant indexes a staff wiki that any employee can edit. Someone adds a page stating that expenses under a certain value need no receipt. The assistant gives that answer, citing the page, until finance notices the claims. The same pattern generalises to any system that retrieves from sources with weaker controls than the answers imply.