Data poisoning.
Poison is counted in documents, not percentages — the largest study of the question found that roughly 250 malicious documents backdoored every model it tested from 600M to 13B parameters, even though the largest of those had swallowed more than twenty times as much clean text without diluting them. That kills the intuition most teams are quietly running on ("our corpus is enormous, a handful of bad pages cannot matter"), and it moves the question to where you can actually act: not the pre-training run you did not do, but the index, the memory and the skill files you add yourself this week.
Poisoning writes to storage. Injection writes to a conversation.
The two attacks get merged constantly and they have almost nothing in common operationally. Prompt injection happens at inference time: attacker text lands in the context window, steers one run, and is gone when the window closes. Poisoning happens at write time: attacker text lands in something durable — a training corpus, a vector index, an agent's long-term memory — and is re-served to every future run, including runs by people the attacker has no other route to.
- Different blast radius. An injection compromises a session. A poisoned document compromises every session whose retrieval happens to select it, for as long as it sits in the index.
- Different detection window. Injection is visible in the trace of the run it hijacked. Poisoning is invisible until something retrieves it, which may be months after the write and long after the logs of that write rolled off.
- Different fix. You mitigate injection at the tool boundary, by bounding what a hijacked run can do. You mitigate poisoning at the write path, by bounding who can put text where a model will later read it.
They chain, which is why they are confused. The standard sequence is: an injected run writes a summary into memory, and that summary is now poison — a single-session attack that has been promoted into a durable one by your own write path. If your agent writes what it read into a store it later trusts, you do not have two problems, you have one problem with a latch.
The count is near-constant, so scale is not a defence.
In October 2025 Anthropic's Alignment Science team, the UK AI Security Institute and the Alan Turing Institute published the largest poisoning investigation run to date. They injected malicious documents into pre-training data and measured when a backdoor took hold across models from 600M to 13B parameters. The finding that matters is not the size of the effect but its shape: the number of documents required stayed roughly constant — about 250 — rather than scaling with the corpus.
- What that overturns. The comfortable model was proportional: an attacker needs some percentage of your data, so more data means more work for them. The measured model is absolute: an attacker needs a fixed pile of documents, so more data means no extra work at all. A 13B model trained on twenty times the tokens of a 600M model was backdoored by the same 250 documents.
- What it does not show. The behaviours tested were deliberately narrow and low-stakes — a trigger phrase producing gibberish, and similar — at model sizes well below the frontier. It is not established that an arbitrary, useful, hard-to-notice backdoor is equally cheap. Treat the result as having flipped the burden of proof, not as having priced every attack at 250 documents.
- Why it still changes your behaviour. Two hundred and fifty documents is inside the budget of one motivated person with a blog, a package registry account, or edit rights on a wiki that gets crawled. "Nobody would bother" and "it would get lost in the noise" were the two things holding the risk down, and one of them is now measured false.
The surfaces you own are the cheap ones.
You will probably never poison, or be poisoned through, a frontier pre-training run — that is someone else's supply chain and you buy it as a finished good. The surfaces under your control are far smaller than a pre-training corpus, which makes them far cheaper to hit: the ratio that matters is attacker documents to retrievable documents, and your index may hold ten thousand.
- The retrieval corpus. Anything that gets crawled into your RAG index is a write path: the support ticket a customer filed, the wiki page a contractor edited, the PDF an outside firm sent. Poisoning here is not even hard to aim — the attacker writes for the retriever, repeating the phrasing of the questions they want to intercept, so the poisoned chunk wins the similarity search for exactly the queries that matter.
- Agent memory. Every store the agent writes to and later reads is a corpus with one author you did not vet: the agent itself, under the influence of whatever it read. See agent memory, and treat "the agent learned this yesterday" as an unreviewed commit to production.
- Tool descriptions and skills. A tool schema and an agent skill are instructions that sit in the prompt at higher trust than any document, sourced from a registry you do not run. This surface has already been attacked at scale rather than in theory.
- Fine-tuning and eval sets. Both are small, both are assembled from production traffic, and traffic is written by users. A poisoned eval set is the quiet one: it does not change behaviour, it changes what you believe about behaviour.
Defend the write path, then bound what a believed lie can do.
There is no classifier that reliably spots a poisoned document, because a good one is not malformed — it is a plausible, well-written page that happens to be false or to carry an instruction. So the controls that work are boring and structural.
- Know who could write. For each corpus, write down the set of principals who can add to it. If that set includes "any customer" or "anyone on the public internet", you have an untrusted corpus, and everything retrieved from it is untrusted content regardless of how internal the system holding it feels.
- Separate trusted-for-content from trusted-for-instructions. Nothing retrieved should ever be treated as an instruction, no matter how authoritative the source — a rule the instruction hierarchy enforces only statistically, so it must also be enforced by what the tools will do.
- Keep provenance on every chunk. Source, author, write date, and the trust tier of the write path, carried through indexing to the prompt. Without it you cannot answer the only question that matters after an incident: what else did that author put in here, and which answers used it?
- Make the write path revocable. Deleting a poisoned document from a store is easy; getting it out of an index, a cache, a fine-tune and a summarised memory is not. Design deletions to propagate before you need one.
- Assume some poison got through. The last line is not detection, it is that a model which believes something false still cannot do anything irreversible on its own — the same containment that answers injection. See agent identity and permissions.
Do the inventory this week, not the tooling. List every corpus your agent reads — index, memory, skills, tool docs, eval sets — and for each one name who can write to it and who reviews that write. Most teams discover at least one path where an unauthenticated stranger's text reaches the model with no human in between, and closing that single path is worth more than any detector you could buy. Then plant a canary: put a distinctive trigger phrase and a harmless marker instruction into your own corpus, and check whether it ever comes back out in an answer.
Related: memory poisoning defences for the write-path detail, agent supply chain security for the registry side, and RAG security for running a retrieval corpus you do not fully control.