An attacker may hide an instruction in a web page, email, support ticket, or tool result. If the agent treats it as a lasting preference or fact, the attacker has moved from one risky prompt to a reusable foothold. Agent memory makes useful personalization possible, but it also makes storage a security boundary.
Why is memory poisoning hard to spot?
The original input may look harmless, and the bad action may happen later. The later agent sees remembered context, not the attack that created it.
That is different from a one-off prompt injection. The attack survives retrieval, compaction, and handoff. Persistent context needs provenance, not blind recall, especially when it can affect tools or external communication.
How do teams reduce the risk?
Treat every memory write as data from a source with a trust level. Keep its source and timestamp. Require validation or review before an untrusted item becomes an operating instruction. Context engineering should separate verified facts from temporary observations.
Teams also need a delete and correction path. AI agent security controls should test whether poisoned memory can alter a tool call, then block the action through authorization or approval even if retrieval fails.