PIP-005
Indirect injection through a retrieved document
Instructions are placed in a document the system will retrieve, so they enter the prompt without the user or the attacker touching the application.
How it works
Retrieval selects passages by similarity, not by trustworthiness, and pastes what it finds into the prompt alongside the real instructions. Anyone able to write into a source the system indexes can therefore write into its context. The attacker never needs access to the application and the user never sees the payload.
Why it works
Retrieval and instruction assembly are separate concerns that meet in a single flat string. At the moment of assembly, a retrieved passage and a developer instruction are indistinguishable.
What it looks like
Ordinary-looking document text containing an embedded directive, often positioned to be retrieved for a common question and phrased to read as guidance to whatever is processing the document.
Described rather than reproduced. This library publishes mechanisms, not payloads: recognising a class of attack and choosing a control does not require a working copy of it.
Defences
Treat retrieved content as hostile input
Architectural
Assume every retrieved passage may carry instructions. Keep it in a clearly demarcated region, and never let its content select an action.
Control who can write to the corpus
Architectural
Most indexes quietly include sources the organisation does not control: supplier documents, ticket bodies, crawled pages, user uploads. Establishing which sources are writeable by outsiders is usually the finding.
Scan documents at ingestion
Do not rely on
Screening at index time catches careless payloads and gives a place to alert. It cannot be relied on, since the payload is ordinary prose and can be rewritten indefinitely.
Framework mapping
- LLM01:2025 · OWASP LLM Top 10
- LLM08:2025 · OWASP LLM Top 10
- AML.T0051.001 · MITRE ATLAS
Mappings are asserted only where the identifier is known correct, and omitted where uncertain. Last reviewed 2026-08-03.