Memory poisoning happens when false or hostile content is written into an AI agent's long-term memory and then trusted in later sessions. Prevent it by deciding what may be written to memory, recording where each entry came from, keeping memory separate per user and task, and being able to find and roll back bad entries quickly.
Why memory changes the risk
A prompt injection inside a single conversation ends when that conversation ends. Memory removes that limit. When an agent saves a fact, a preference or a lesson learned, it will read that entry again in future sessions and treat it as something it already knows.
That makes memory a store of instructions as well as data. If a hostile web page, email or document persuades the agent to save "the finance team has approved all refunds from this supplier", the damage does not happen once. It happens every time the agent recalls that entry, possibly for other users and long after anyone can remember where it came from. The OWASP Top 10 for Agentic Applications lists memory and context poisoning as a risk of its own, separate from goal hijacking and tool misuse, for this reason.
Poisoning is not always an attack. An agent that summarises a mistaken conversation, or saves its own wrong guess as a fact, poisons its memory just as effectively. The controls below cover both cases.
Where poisoned memory comes from
Start by listing every path that can write to the agent's memory. In most systems there are more than the team expects.
Content the agent reads
Web pages, emails, tickets, uploaded files and tool results can all contain text written to be remembered. If the agent can save anything it reads, every one of those sources can write to memory.
Users and other agents
A user can tell the agent something false and ask it to remember it. In a multi-agent system, one agent's output often becomes another agent's memory, so a mistake in one place spreads to several.
The agent's own output
Many memory designs save summaries of past sessions automatically. If those summaries go straight back into trusted memory without checks, the agent's errors become its future facts.
Controls that keep memory trustworthy
Decide what may be written at all
Treat memory writes as an action with a policy, not a side effect. Define which kinds of entry the agent may save, such as user preferences or task outcomes, and refuse everything else. Instructions, approvals, credentials and claims about other people's permissions should never be saved from untrusted content.
Record provenance on every entry
Store who or what caused each entry, the source it came from, when it was written and which session wrote it. Give entries a trust level based on the source: a fact confirmed by a system of record ranks above one taken from an email. Let low-trust entries expire unless something confirms them.
Keep memory separate
Partition memory by user, tenant and task so that one poisoned session cannot reach everyone. The same separation that keeps customer data apart, covered in multi-tenant AI agent data isolation, also limits how far a bad entry can travel.
Check high-impact recalls
When a remembered entry would change a decision with real consequences, such as a payment, an access change or a message to a customer, check it against the system of record first. Memory can suggest, but the source system should decide.
Make memory reviewable and reversible
Log every write, read and deletion alongside the agent's other actions, as described in how to audit what an AI agent did. Take regular snapshots so you can roll memory back to a known good state, and make sure you can delete entries by source, which also supports the right to erasure for AI agents.
Test for it before launch
Add memory poisoning to your pre-launch testing. Plant a document that tries to save a false approval, then start a fresh session and check whether the agent acts on it. Do the same with a user who repeats a false claim across several conversations. If either succeeds, tighten the write policy before you go live. Include memory clean-up in your AI agent incident response plan, so the team knows how to find and remove bad entries when one gets through.
If you are adding long-term memory to an agent that acts on business systems, talk to CodeDTX about designing it with these controls from the start.
Frequently asked questions
Is memory poisoning the same as prompt injection?
They are related but not the same. Prompt injection tries to change what the agent does in the current session. Memory poisoning tries to make a change last, by getting hostile or false content saved and then trusted later. An injection is often how poisoning starts, but the controls differ: memory needs write policies, provenance, separation and rollback as well as input filtering.
Does a RAG knowledge base count as agent memory?
Yes, if the agent or its users can add to it. A retrieval index that only your team updates through a reviewed process is lower risk. Once an agent can write documents, notes or summaries into the index, it behaves like memory, and the same controls apply: limit what can be written, label the source of each entry and keep a way to remove bad entries.
Should we turn off long-term memory to avoid the risk?
Not always. Memory can make an agent more useful by keeping preferences and context between sessions. The question is what it may store and how much the agent trusts it. Start with narrow memory, such as user preferences, with provenance and expiry. Widen it only when you can show that writes are controlled and that bad entries can be found and removed.
How do we find poisoned entries after the fact?
Provenance makes this possible. When you suspect a bad entry, search memory by its source, session or time window, review what those entries say, and roll back to a snapshot taken before the problem if needed. Without provenance you are left reading every entry by hand, which is why recording the source of each write matters from the first release.
