The attack surface of retrieval

A retrieval pipeline has more moving parts than its diagram suggests, and each one is a place where something can go wrong.

Ingestion

Documents arrive from shared drives, wikis, ticket systems, uploads and crawls. Two questions decide how much trouble you are in: who can put a document into the corpus, and does the corpus remember who may read it. In many systems the answers are "almost anyone" and "no".

An attacker who can add a document — a public wiki page, a support ticket, a shared folder — can plant instructions that will later be read by a model acting for someone else. Corpus poisoning is indirect injection with a longer fuse, and it works on everyone who asks a related question.

Chunking and embedding

Chunking splits documents, which can separate a statement from the qualification that made it true. Embeddings are matched by similarity, not meaning, so a chunk stuffed with the vocabulary of a popular question can be made to surface for it — the retrieval equivalent of search engine spam.

The index

Vector databases have had the same early-product security history as every data store: no authentication by default, exposed ports, and metadata that nobody treats as sensitive even though it contains document titles and identifiers. Treat the index as a copy of the source documents, because that is what it is, and secure it accordingly.

Retrieval and generation

At query time, the retrieved chunks are concatenated into the prompt. Anything in them is read by the model. If the system also lets the model cite or follow links from those chunks, the attacker gets an outbound channel as well.

A short checklist

• Can an untrusted party add or edit documents in the corpus?
• Does every chunk carry the access rules of the document it came from?
• Is the index itself authenticated, encrypted and off the public internet?
• Is retrieved text marked as data, and barred from triggering tool calls?
• Would you notice a document that nobody wrote and everybody retrieves?