Persistent context poisoning is a long-lived attack on an AI agent’s memory or shared context, where malicious instructions, facts, or preferences are stored and reused across sessions. In agentic AI and MCP-connected workflows, poisoned context can steer tool use, data retrieval, decisions, and identity actions until the corrupted state is detected and removed.
How persistent context poisoning works
Persistent context poisoning targets the layer where an agent stores learned context, memory, or reusable instructions. Because the poisoned content survives beyond a single prompt, it can influence later sessions even when the immediate user input looks harmless.
This makes the attack qualitatively different from one-off prompt injection. The harmful content is not just read once, it is retained, retrieved, and trusted again, which means the agent may keep acting on stale or malicious state until the corrupted memory is discovered and corrected.
Why it is dangerous in agentic workflows
The main danger is that long-lived memory can quietly reshape future behaviour. A poisoned preference, fact, or instruction can steer tool selection, retrieval, escalation paths, or approval logic in ways that are hard to spot during normal testing.
In agentic systems, that matters because the stored context can outlive the original compromise point. An attacker does not need repeated access if they can seed a durable instruction once and let the system reuse it across tasks, conversations, or connected services.
Where the attack persists
Persistent poisoning is most concerning where agents share context across users, sessions, or tools. Shared memory, long-term scratchpads, retained summaries, and retrieval indexes can all become carriers for malicious state if write controls are weak or provenance is unclear.
The risk increases when the agent treats stored context as authoritative rather than advisory. If the system cannot distinguish trusted memory from attacker-supplied memory, the poisoned content can be replayed into planning, retrieval, or execution decisions long after the initial injection.
How organisations should think about detection and recovery
Defenders need visibility into what was written, when it was written, and which later actions consumed it. That means logging memory writes, tracking provenance, and reviewing unusual changes in agent behaviour after updates to shared context.
Recovery usually requires more than deleting a single prompt fragment. Teams should identify the contaminated memory source, remove or invalidate it, and then review downstream sessions, tool actions, and decisions that may have been influenced by the bad state.
Risk and Threat Considerations
persistent context poisoning creates a durable trust failure: one successful write can shape many later decisions, especially in shared or reused agent memory. That can expose data, distort outputs, and create unintended actions long after the original attacker interaction has ended.
Failure mechanism: The agent accepts untrusted content into a persistent store, then later rehydrates that content as if it were legitimate context, allowing the attacker’s instruction or false fact to survive normal session boundaries.
Impact: The poisoned state can drive repeated tool misuse, bad retrieval, privilege-relevant actions, or identity-related decisions, and the same corruption may affect multiple users or workflows before it is detected.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI06 — Memory & Context Poisoning | Directly addresses poisoned agent memory and context reuse across sessions. |
| Recommendation — Validate stored context before reuse and isolate memory writes from untrusted inputs. | ||
| NIST AI RMF | GV.2 — Map Context, Define, and Frame AI Risks | Applies because persistent context poisoning is an AI risk that needs governance and monitoring. |
| Recommendation — Establish governance for memory retention, provenance, and review of agent context risks. | ||
| MITRE ATLAS | AML.TA0004 — Evasion | Persistent poisoning helps adversaries hide malicious influence inside reused context over time. |
| Recommendation — Track persistence mechanisms and hunt for repeated influence patterns in agent behavior. | ||
Practitioner Guidance
Why practitioners should care: Treat agent memory as security-sensitive state, not as a convenience cache. If the system can write to shared or long-lived context, the write path deserves the same scrutiny as any other control surface that can alter later behaviour.
What to watch for: Look for unexplained changes in agent decisions, repeated references to unverified facts, or tool-use patterns that begin to mirror earlier malicious instructions. Those are often stronger signals than the initial prompt that caused the contamination.
Practitioner takeaway: The safest design assumption is that persistent context can be poisoned, so every reuse of stored memory should be bounded by provenance, validation, and a clear path to revoke bad state.
Related resources from NHI Mgmt Group
- Guide: AI Agent Memory Security Guide
- Why do context poisoning attacks matter if the model itself is secure?
- How should organisations govern context poisoning in agentic development tools?
- How should security teams stop context window poisoning in AI coding assistants?
- What breaks when context poisoning is not controlled?