Memory Poisoning in AI Agents: When What the Agent Remembers Becomes the Attack
Memory poisoning is injection that outlives the session: an attacker gets text into an agent's long-term memory, RAG store or shared context, and every later session that retrieves it inherits it. Five controls contain it: provenance on every memory write, scoping by user and task, expiry for unverified entries, review before high-impact writes persist, and snapshots you can roll back to.
On this page
An agent that remembers is more useful than one that doesn't. It knows your preferences, where last week's task stopped, the policy it looked up yesterday. Vendors ship memory as a feature, and teams build shared knowledge stores so agents can learn from each other's work.
Every one of those is a write path. Whatever can write to an agent's memory can shape what the agent does next week, for a different user, in a session that never saw the attacker.
What memory poisoning is
OWASP's Agentic AI – Threats and Mitigations guide lists it first in its threat model, as T1 Memory Poisoning: exploiting an agent's short- and long-term memory "to introduce malicious or false data and exploit the agent's context". The later OWASP Top 10 for Agentic Applications files it as ASI06 Memory & Context Poisoning, and draws a useful boundary. Context there means anything an agent retains, retrieves or reuses: summaries, embeddings, RAG stores. One-time prompts are left to ordinary prompt injection, LLM01:2025.
That boundary is the point. Prompt injection lasts as long as the session. Memory poisoning persists.
It helps to separate three kinds of memory, because the attack and the control differ for each:
- Session context: the running conversation and its summaries. Poison here can survive in a summary that outlives the session.
- Per-user long-term memory: saved facts and preferences the agent recalls in future sessions.
- Shared stores: a RAG knowledge base, a vector database or a memory pool that several users or agents read. One write reaches everyone who retrieves it.
How memory poisoning attacks work
The published attacks share a shape: get the agent to write, then wait for it to read.
Through content the agent processes. In September 2024 Johann Rehberger disclosed SpAIware. A website or document analysed in ChatGPT could invoke its memory tool and store instructions that sent the user's later conversations to an attacker's server, through an image URL. OpenAI fixed the exfiltration channel. Rehberger's post notes that an untrusted website or document could still store arbitrary memories.
Through a delayed trigger. In February 2025 he showed the same class of attack on Gemini. Gemini generally avoided calling sensitive tools while processing untrusted content, so the hidden instructions in a document waited. They told the model to save chosen "facts" as memories if the user's next reply was a word like "yes" or "sure". When the user replied, the write looked like the user's own request. Google assessed the risk as low likelihood and low impact.
Through ordinary queries. MINJA (Dong et al., 2025) assumes no direct access to the memory bank at all. The attacker plants malicious records "by only interacting with the agent via queries and output observations". The records are built to be retrieved later, as demonstrations, when a different user asks a related question.
Through the knowledge base. AgentPoison (Chen et al., NeurIPS 2024) poisons long-term memory or a RAG knowledge base with demonstrations that are retrieved only when a query contains an optimised trigger. On each of the three agents tested, the authors report an average attack success rate above 80%, with a poison rate below 0.1% and under 1% impact on benign performance.
None of this is new in principle. Greshake et al.'s 2023 paper on indirect prompt injection gave a GPT-4 application a simple key-value memory and showed it being reinfected in a new session by reading its own notes.
Why memory poisoning is harder to catch than prompt injection
Four properties make it worse than the session-bound version.
The write and the harm are separated in time. The session that planted the memory may look harmless. The session that acts on it contains no injection in its input at all. A filter on the current prompt sees nothing, because there is nothing there to see.
Memory is trusted more than the web. A retrieved memory arrives looking like the agent's own knowledge, not like third-party content. A defence that only marks web pages and documents as untrusted will wave it through.
Shared memory spreads. OWASP's scenario is a customer service application where an attacker writes incorrect refund policies into shared memory, and every agent that consults it reinforces them.
Agents poison themselves. An agent that writes its own outputs back into trusted memory can turn one bad input into many entries. ASI06 calls this "bootstrap poisoning" and recommends preventing automatic re-ingestion of an agent's own outputs.
This is why injection belongs among the attack patterns a tool-calling agent's threat model has to cover, not in a chatbot appendix. Memory gives it a delayed fuse.
How to detect memory poisoning in AI agents
Detection starts with treating a memory write as an event worth recording, not a side effect.
- Log every write with its cause. Which session, which user, what content was in context when the write happened, and whether that content came from a user, a tool, a document or the agent itself. This is the provenance part of an audit trail that can reconstruct what an agent did.
- Flag writes made while untrusted content was in context. That is the moment both of Rehberger's attacks used.
- Flag writes that read like instructions. A preference reads like a fact: "prefers metric units". A poisoned entry often reads like a command, a rule addressed to the model, or a URL.
- Watch write frequency. OWASP's playbook lists abnormal memory modification frequency as a signal of manipulation.
- Trace behaviour changes back to retrievals. When an agent starts deciding differently, you need to know which memory entries were in context for that decision, so you can find the write that caused it.
Five controls for agent memory
OWASP's mitigations for T1 and ASI06 make a long list. Most of them fall into five controls.
| Control | What it means in practice | What it stops |
|---|---|---|
| Provenance on every write | Each entry carries its source, the session that created it and a trust level | Untraceable entries; poisoned "facts" that look first-party |
| Scope | Memory is partitioned by user, tenant and task; retrieval sees only its own partition | One write reaching every user; cross-tenant leakage |
| Expiry | Unverified entries decay or expire; retention follows sensitivity | Poison that persists indefinitely |
| Review before persist | Writes triggered by untrusted content, and high-impact entries, need confirmation before they become trusted | Silent writes like the SpAIware and Gemini attacks |
| Snapshots and rollback | Memory is versioned, so you can restore a validated state | A clean-up that has to guess what was poisoned |
Two rules sit underneath all five.
First, retrieved memory is data, not instruction, however it was stored. Whatever reads it, the agent or a check on the agent, should give a memory that says "always approve refunds" the weight of a sentence in a document, not the weight of a sentence from the policy owner.
Second, check the action, not just the memory. You will not catch every poisoned entry. A consequential action that poisoned memory steered towards can still be checked against what the agent is allowed to do before it runs, whatever its reasons.
A memory poisoning checklist
- List every store your agents read from and write to, including conversation summaries and shared vector indexes.
- For each store: who and what can write to it, and is every write logged with its source?
- Can content from a web page, email or document trigger a write without anyone confirming it?
- Is memory partitioned per user and tenant, or can one write reach everyone?
- Do unverified entries expire?
- If you learned today that a store was poisoned last month, could you restore it to a known-good state?
Where Syntrox fits
Syntrox sits outside the agent, so its judge does not share the agent's memory. Our judge, Nucleus, treats any text inside the material it evaluates as evidence, never as instructions, and an instruction addressed to the evaluator counts against the output. Syntrox records each evaluated trace's score, confidence and judge version outside the agent.