MINJA research shows over 95% injection success rates against production agents that use persistent memory. That number should stop you for a second if your team has recently added a memory layer to an agent - and a lot of teams have.
The threat has a name now. OWASP recognized it in 2026 by adding Memory and Context Poisoning as ASI06 to its Agentic AI Top 10. The classification exists because the prompt injection defenses most teams already have - input moderation, output filtering, session-bounded checks - do not address attacks that persist across sessions. This post explains what memory poisoning actually is, why it is structurally different from prompt injection, and what a working defense looks like.
What persistent memory poisoning actually is
AI memory poisoning is a persistent attack against agent memory: an attacker writes malicious content into an agent's long-term memory so the agent acts on the poisoned content in future sessions. Unlike prompt injection, which resets between sessions, memory poisoning persists across every subsequent interaction - the attack and its effect are temporally decoupled.
That last phrase is the one worth sitting with. Memory poisoning makes the agent behave wrongly across every subsequent interaction. The attacker can write today and the agent acts wrongly months later. The window between infection and consequence is what makes it hard to catch.
The attacker's goal is to inject misleading or malicious memory items into an assistant's persistent memory layer so that an agent later retrieves and trusts these malicious items to perform unrelated future tasks. When an AI agent remembers attacker-controlled information as a trusted context, the attacker has gained persistence inside the agent's decision-making process.
A practical example: a Slack-connected agent that reads customer emails to extract preferences gets a crafted message that writes a fake vendor contact into long-term memory. Three weeks later, when a teammate asks the agent to find the right supplier for an urgent order, it retrieves that poisoned entry as authoritative and routes the request to an attacker-controlled address. No one saw the write. No session log caught it. The agent behaved exactly as designed.
to make the poison stick, the tool aims it at the core files that load every session, so a single write is loaded into every later session instead of waiting to be pulled from a separate memory store. One email, persistent access.
Why your prompt injection defenses don't cover this
Most teams treat injection as an input problem. Sanitize what comes in, filter what goes out, and the risk is contained within the session. That model is correct for stateless agents.
The structural difference from prompt injection matters. Prompt injection is session-scoped: malicious instructions in the current prompt make the model behave wrongly for that session, and the effect ends when the session ends. Memory poisoning lives in a different layer entirely - the retrieval store that gets injected into every future context window.
Unlike stateless models that process each interaction independently, memory-enabled agents accumulate knowledge over time: they retain user preferences, record past task outcomes, and build domain knowledge encountered during operation. For long-horizon tasks such as software development, enterprise workflow automation, and personalized assistance, this persistent state is what allows agents to improve with use and become progressively more effective. That's exactly right - and it's also exactly what makes the attack surface durable.
The Gemini memory attack demonstrated how delayed tool invocation bypasses runtime guardrails using trigger words like 'yes' or 'sure' that appear in nearly every conversation. The defense that stopped the previous turn's injection didn't fire because the instruction wasn't in the prompt - it came back from memory retrieval.
There's also a detection problem. You do not catch the change for a few reasons. The assistant hides its behind-the-scenes steps by design, so the moment it edits a file never shows up in the chat. Few users ever open the raw memory files to read them. And when the agent runs on a schedule in the background, it often sends no message at all, so there is nothing to notice.
What a working defense actually looks like
Defense requires layered controls: input moderation with trust scoring, memory sanitization with provenance tracking, trust-aware retrieval, and behavioral monitoring to detect when an agent starts defending beliefs it should never have learned. Each of those layers handles a different part of the attack chain.
The most important shift is treating memory entries as objects with metadata, not as facts. Forcepoint's August 2026 research demonstrated a memory risk engine that evaluates several signals before deciding how much to trust a new memory: the memory itself is no longer treated as truth, it becomes an object that can be inspected.
Concretely, a memory entry that gets written during an inbound email processing flow should carry lower trust than one explicitly confirmed by a user in-session. At retrieval time, high-risk-scored entries should require a fresher confirmation signal before being injected into context. This is different from how most memory implementations work today - they retrieve on semantic similarity and inject without trust weighting.
For security teams trying to detect memory poisoning in agentic systems: look for persistent changes in behaviour, repeated instruction patterns that do not match approved workflows, and unexpected decisions that recur across sessions. The strongest signal is not a single bad answer, but a durable shift in how the agent prioritises tasks or selects tools. Logging the provenance of retained state is essential.
A few concrete controls worth building now:
- Source tagging at write time. Every memory entry should record where it came from - inbound email, user utterance, document parse, tool output. Retrieval-time trust scoring depends on this.
- Namespace scoping. Memory systems with user-level namespace scoping (like Mem0's user/session/agent hierarchy) are better positioned for compliance than session-less vector stores. They're also easier to audit and easier to surgically delete.
- Staleness handling for high-value entries. A highly-retrieved memory about a user's employer is accurate until they change jobs, at which point it becomes confidently wrong. High-retrieval entries with external provenance should have an expiry or a reconfirmation trigger.
- Behavioral baselining. If an agent that previously routed support tickets to three internal queues starts routing a category to an external endpoint, that's a behavioral signal - not an input signal. Most observability tooling today monitors tokens and latency, not routing drift.
Beagle in action#ops-agents, async reviewThe regulation angle is also closing in. The EU AI Act, fully applicable from August 2026, adds a 10-year audit trail requirement for high-risk AI systems. An agent memory store with no provenance metadata cannot produce that trail. Teams that shipped memory layers as a feature without thinking about write provenance now have a compliance gap on top of a security one.
The broader point: persistent memory is the right direction for agents. Stateless agents that forget everything are genuinely less useful. But the security model for persistent memory is not an extension of session-level injection defense - it's a different problem that needs a different layer.
Persistent memory poisoning: common questions
What is the difference between prompt injection and memory poisoning?
Prompt injection is session-scoped: malicious instructions arrive in the current prompt and the effect ends when the session ends. Memory poisoning writes malicious content into the agent's long-term store, so it persists across all future sessions. The controls that catch injection - input filtering, output moderation - do not catch poisoning, because the malicious content arrives back through retrieval, not through the input.
How do agents get infected if the attacker never has direct access?
The attack surface is any content the agent reads and stores: inbound emails, documents it processes, tool outputs, web pages it browses. If the agent's memory layer writes from those sources without trust scoring, a crafted document or email can plant a memory entry the agent will later treat as authoritative context.
What is OWASP ASI06?
ASI06 is Memory and Context Poisoning - a category OWASP added to its 2026 Agentic AI Top 10. It covers attacks that corrupt the persistent context an agent relies on, including long-term memory stores and RAG indexes. It is listed separately from prompt injection because the attack mechanism and the required defenses are structurally different.
Does a longer context window make this worse or better?
Neither, directly. Longer context windows help an agent see more of the current conversation - they do not change what gets written to the external memory store. The poisoning lives in the retrieval layer, not in the context window itself, so expanding the window doesn't help and doesn't hurt.
What's the minimum viable defense for a team that already shipped a memory layer?
Start with write provenance: tag every memory entry with its source type at write time. Then add retrieval-time trust scoring so entries from unverified external sources require a higher confirmation signal before being injected into high-stakes actions. Add behavioral logging that tracks routing and tool-selection patterns over time, so drift shows up as a signal before it causes harm.