What is context poisoning, and how does it differ from Prompt Injection?
Prompt injection is a one-time, in-the-moment attack — the malicious instruction appears within a single interaction, and its effect typically ends when that session closes. Context poisoning, by contrast, involves an attacker writing false data into an agent's persistent storage layer (a vector database, a RAG index, long-term memory, conversation summaries), so that entry survives across sessions and can be referenced in any future interaction that happens to retrieve that piece of memory — often triggered in a later interaction the attacker had no direct part in.
This difference means the two require entirely different defense logic: prompt injection is defended at the point of input, while context poisoning has to be defended at the level of whether the stored content itself can be trusted — because the victim isn't a single conversation, but every future decision the agent makes that draws on that memory store.
Why does context poisoning happen, and what drives it?
The core driver is that agent systems widely adopt long-term memory or RAG retrieval to improve performance — letting an agent remember past interactions and reference cases it previously handled successfully genuinely improves accuracy and efficiency, but it also means anything written into that memory layer gets treated as a trusted source and reused repeatedly. Most systems lack provenance tracking at design time — who wrote a given memory entry, how trustworthy it is — so once poisoned content mixes into the store, it's difficult to distinguish from legitimately written entries.
Another driver is that the attack bar is actually low: MINJA, an attack presented at NeurIPS 2025, demonstrated that an attacker doesn't even need direct write access to the memory store — ordinary interaction queries alone were enough to implant poisoned content into an agent's long-term memory, achieving over 95% injection success against several production agent architectures.
How does context poisoning actually work, and what does an attacker actually do?
The typical pattern is that an attacker, during an interaction that looks entirely normal, gets the agent to store a fabricated entry — formatted identically to a legitimate record — into its memory, disguised as, say, a "previously successful case" or a "verified fact." That entry causes no immediate anomaly once stored, since it hasn't been retrieved by any subsequent query yet; only when some future, entirely unrelated user issues a query that happens to trigger retrieval of that memory does the agent treat the false entry as a trusted basis and act on it — by which point a significant amount of time may have passed since it was planted, making the agent's behavior look like it went strange "for no reason."
The attack surface concentrates on four entry points: external content an agent actively crawls or indexes (the RAG source), long-term memory storage, tampered tool descriptions (tool poisoning), and messages passed from other agents in Multi-Agent Systems. The RAG source is the one most commonly underestimated — if a pipeline doesn't validate content, anything an attacker can influence can end up indexed into the database. One benchmark testing tool-description poisoning across 20 leading agents recorded an attack success rate above 70%, with more capable models often more susceptible precisely because they're better at following instructions, including planted ones.
What does context poisoning mean for me, and how do I tell if I've already been affected?
If your agent uses any form of persistent memory — RAG, a vector database, conversation summaries, cross-session user preferences — this risk compounds the longer that memory is in use: the longer a store has been running and the more content it has accumulated, the higher the chance it's been poisoned without detection, and the gap between when poisoning occurred and when symptoms appear is often much wider than in typical security incidents, making after-the-fact tracing considerably harder.
Observable warning signs include: a sudden, unexplained shift in the agent's preferred tools, decisions drifting away from previously established patterns, and an unusual rise in failed API calls — these can be behavioral signals of a poisoned context rather than ordinary model performance variance. As a more fundamental defense, building provenance tracking into memory (who wrote it, when, how trustworthy) and partitioning storage by trust level helps — for example, keeping system-level policies and verified facts in a read-only partition requiring human review to change, separate from ordinary memory generated through user conversation, while periodically auditing the memory store with a separate, trusted model to surface entries that look properly formatted but contradict known facts.
MINJA, an attack presented at NeurIPS 2025, demonstrated that an attacker needs no direct write access at all — ordinary interaction queries alone are enough to poison an agent's long-term memory, achieving over 95% injection success against multiple production agent architectures. In March 2026, OWASP formally listed this risk category as ASI06 (Memory and Context Poisoning), a dedicated entry in its Top 10 for Agentic Applications.
Adding provenance tracking and trust-based partitioning to a memory store effectively limits how far poisoning can spread, but increases system design and operational complexity — every entry written to memory needs a tagged source, and every read requires a trust-level judgment, which adds response latency for latency-sensitive applications. Doing no tracking or auditing at all effectively lets poisoned content lie dormant indefinitely. The common industry approach is to apply strict tracking first to high-risk memory partitions (system policies, financial facts), while treating ordinary conversational memory more loosely but auditing it periodically.