Document poisoning is patient in a way most attacks aren't. Plant manipulative content inside a source that feeds a RAG pipeline's retrieval index, and wait: eventually a query from some user, anyone whose question happens to match the poisoned content closely enough, retrieves it and delivers the payload straight into the model's context. Unlike a direct injection attempt, the attacker doesn't need to touch the target application again once the poisoned content is sitting there. They just wait for retrieval to do the work for them.
Where the poisoned content can come from
Any writable source feeding retrieval is a potential poisoning vector: a public wiki with broad edit access, a shared drive where half the company can upload files, a scraped external website, a support ticket system whose content gets indexed for a knowledge assistant, a community-contributed knowledge base. The common thread is that the attacker only needs write access to the source, and for most of these examples that requires far less privilege than reaching the target application directly, an insider with modest permissions, a compromised low-privilege account, or, for public scraped content, no organizational access at all.
Why poisoning scales better than direct injection
A direct injection attempt affects exactly one conversation, the one it was submitted into. A successfully poisoned document affects every future query that retrieves it, across however many different users, over however long it takes someone to notice and pull it. One successful planting event, many exploitation events downstream, and that asymmetry is exactly what makes document poisoning so attractive to an attacker willing to wait for retrieval to deliver the payload instead of interacting with the target system directly and repeatedly.
How attackers boost the odds of getting retrieved
An effective poisoning attempt is usually written to maximize its odds of surfacing for common or predictable queries, sometimes with phrasing that closely echoes likely questions, sometimes just by repeating key terms likely to score well in similarity search regardless of the document's actual topical relevance. Some techniques go further and disguise the injected instruction inside content that otherwise reads like a perfectly normal document, a support article, a policy summary, a technical note, specifically to avoid drawing attention from whoever might review the source before it gets indexed.
Catching poisoned content before it's ever indexed
The best point to catch poisoning is before content ever enters the retrieval index, full stop. That means applying content review to anything feeding a retrieval pipeline with the same rigor you'd apply to a code change: checking new or modified documents for patterns consistent with injection attempts, unusual formatting that might hide content from casual review, or unexpected changes to content that was already reviewed and trusted. Automated scanning for known injection patterns catches some of the straightforward attempts. It won't catch everything, especially novel phrasing built specifically to dodge known-pattern detection.
Restricting write access shrinks the attack surface directly
Beyond detection, cutting down who can write to sources that feed retrieval cuts down the number of people who could plant poisoned content in the first place. It's a straightforward access control move that pays off specifically for this risk: a source with broad, unreviewed write access is a much softer target than one restricted to a small, trusted group whose changes get reviewed before they take effect.
Limiting the damage even when poisoning gets through
Detection was never going to catch every attempt, so the same downstream controls that limit prompt injection's impact generally apply here too: narrow tool scope so a manipulated model has limited real authority, independent authorization checks on any resulting tool call, output validation before generated content reaches anything sensitive. A poisoned document that successfully manipulates a response still shouldn't be able to trigger an unauthorized action if those downstream layers are actually in place.
Watching for signs poisoning already succeeded
Ongoing monitoring should watch for the patterns a successful poisoning attack tends to leave behind: unusual response content correlated with one specific retrieved document, or a sudden spike in a particular document's retrieval frequency that doesn't match its actual topical relevance. Either one can point to content specifically engineered to get retrieved far more often than its genuine relevance would ever justify.
Where TELEON fits
TELEON's audit trail can help trace an unusual agent response back to which specific documents were retrieved as part of that interaction, applied through the gateway or supported middleware, supporting an investigation into whether a specific document is responsible for a pattern of unusual behavior.
Detecting and preventing poisoning itself, through content review before ingestion and restricted write access to feeding sources, is pipeline-level work that has to happen at the point where content enters the retrieval system.
A short checklist
- Restrict write access to sources that feed retrieval to a small,
trusted group.
- Review content before it enters the retrieval index, with the same
rigor as a code change.
- Scan for known injection patterns and unusual formatting in new or
modified content.
- Limit the impact of an undetected poisoning attempt through narrow tool
scope and independent authorization.
- Monitor for unusual retrieval frequency or response patterns tied to
specific documents.
Document poisoning succeeds by exploiting the trust a retrieval system places in its own index. Reducing who can write to that index, reviewing what gets added, and limiting what a manipulated model can do downstream are the layers that make it harder to plant a payload and less damaging if one gets through anyway.