Agent Memory Poisoning: How to Find a Bad Memory, Trace It, and Undo the Damage

An agent reads a document in February. It stores a short note from it as a harmless fact. In April, a different user asks an unrelated question, the agent retrieves that note, treats it as its own accumulated experience, and acts on it. By then the person who planted it is long gone, the February session is a distant record, and nobody can say where the note came from.

That is the shape of a problem that is getting more attention as agents gain persistent memory. This article starts with the problem: what it is, how big it is, what it costs, and why standard tooling does not solve it. Only then does it turn to a way of handling it.

A scene worth keeping in mind

Consider a hypothetical accounts payable agent at a mid-sized company. It remembers supplier details so staff do not re-enter them. One day it processes an invoice email that carries a line of hidden text, formatted so the agent treats it as a note to remember: the supplier has changed bank details, use the new account from now on.

Nothing breaks that day. The agent stores the note, and the invoice is paid normally. Three weeks later, a legitimate payment to the same supplier goes to the new account. Finance finds out when the supplier asks where its money is.

Now the questions begin. Which memory was wrong? Where did it come from? Which other payments used it? Was anything else planted in the same way? What did the agent believe on the day of each payment? Most teams discover that they can answer none of these, because the memory store holds the note but not its history.

This is a hypothetical, but each ingredient has been demonstrated in public research, covered below.

Why memory changes the threat

Most security thinking about language models assumes the problem lives inside one conversation. A prompt injection tricks the model, the model misbehaves, and the effect ends when the session ends.

Persistent memory breaks that assumption. Researchers describe memory poisoning as the durable counterpart to prompt injection: malicious or false content is written into an agent's memory so that it shapes behavior in future sessions. Two properties make it hard:

Persistence. The poisoned entry survives session restarts and can outlast model updates, because it lives in storage, not in the model.
Temporal decoupling. The write and the harm are separated by days or weeks. The security community describes this as an attack where the injection happens in one month and the damage in another.

The OWASP Top 10 for Agentic Applications 2026 gives this its own entry, ASI06, titled Memory and Context Poisoning, separate from ordinary prompt injection. The reasoning is that the controls, detection methods, and recovery processes are different.

Three ways memory goes bad

Attackers get the headlines, but they are only one cause. In practice, there are three.

Malicious injection. Someone deliberately plants content, through a document, a web page, an email, a shared knowledge base, or ordinary queries.

Accidental corruption. The agent writes a wrong conclusion into memory, such as a misread number, a hallucinated policy, or a guess stored as fact. Nobody attacked anything, and the effect is the same.

Staleness and drift. True facts become false. A customer moves, a price changes, a policy is replaced. The old note keeps being retrieved. Security writers also describe long-term memory drift, where repeated small taints shift an agent's stored knowledge gradually, which is hard to see because each step looks plausible.

The third kind is far more common than the first. It is also the best reason for any team with memory to care about this problem, even if it never expects to be attacked.

What the evidence shows

The evidence has two layers, and it is worth keeping them apart.

Demonstrations on real products. Security researcher Johann Rehberger showed in 2024 that untrusted content could cause ChatGPT to write to its long-term memory, and his SpAIware exploit, disclosed in September 2024, achieved persistent data exfiltration across future sessions. In February 2025 he showed a comparable attack on Google Gemini using delayed tool invocation, which bypassed a defense that blocked memory writes triggered by a document. Palo Alto Networks Unit 42 reported in October 2025 that indirect prompt injection through a malicious web page could corrupt the long-term memory of an Amazon Bedrock agent. LayerX Security reported a flaw in the ChatGPT Atlas browser in late 2025 that allowed injection of persistent instructions into a user's memory.

Laboratory research on success rates. The MINJA study reported over 95 percent injection success and about 70 percent attack success, using only ordinary queries and no special privileges. AgentPoison reported at least 80 percent attack success with a poison rate below 0.1 percent of the memory, across healthcare, driving, and question-answering agents. A newer study, Trojan Hippo, reported attack success of up to 100 percent on one model and 85 percent on another with no memory defenses in place.

Honest limits. Those rates come from research settings, and they should not be read as production failure rates. A follow-up study found that realistic conditions, where an agent already holds many legitimate memories, dramatically reduced the effectiveness of the MINJA attack. One review of the public record also found no evidence of a large-scale malicious memory poisoning breach in production, as opposed to promotional manipulation. Separately, a defense study reported that even LLM-based detectors missed about two thirds of poisoned entries, a figure I have seen only in secondary summaries, so treat it with care.

The fair summary is this: the attack class is real, demonstrated on major products, and not yet proven to be common in the wild. The accidental and stale versions need no attacker at all.

What it costs when it goes wrong

The costs are not mainly about the poisoned entry. They come from what you cannot do afterwards.

Wrong decisions repeat. Unlike a one-off error, a bad memory is retrieved again and again, so each use is another wrong action. The longer it lives, the larger the pile to clean up.

You cannot scope the damage. Without knowing which actions used the entry, you must assume all of them might have. Teams then review everything, which is slow, or nothing, which is risky.

You cannot date the start. If you do not know when the entry was written, you cannot say which period is affected, and you cannot tell customers anything precise.

Deleting destroys the evidence. The natural reaction is to delete the bad memory. That stops the harm but also removes the trail, so you can no longer show a regulator, a customer, or an insurer what happened.

Shared memory spreads harm. Where memory is shared across users, sessions, or cooperating agents, one write becomes another party's read, and the problem crosses boundaries.

Trust takes the hit. Customers in finance, health, and insurance ask how you would know if an agent were acting on bad information. A story that begins with we would have to check everything does not close deals.

Why the usual tools do not help

Teams that notice the problem often reach for what they already have. Each falls short for a specific reason.

Input filters check content at the moment of writing. They help, but research suggests existing prompt injection defenses give incomplete coverage for memory attacks, and they do nothing about accidental corruption or staleness.
Observability and tracing show healthy-looking single events. A poisoned memory produces normal-looking calls, so the anomaly is not in any one event.
Vector stores and memory libraries store content, usually without a record of where it came from, who or what wrote it, or what later depended on it.
Periodic review by humans cannot keep up with writes at agent speed, and cannot answer where an entry came from.
What good looks like

Whatever tools you use, a team that handles this well can answer five questions quickly:

Where did this memory come from? Which input, source, and step produced it.
What did it influence? Every later action that retrieved it.
When did it start? The exact time it was written, and what changed since.
What did the agent know on a given day? The state of memory at the time of a disputed action.
Can I retire it without destroying the evidence? Remove it from use while keeping the record.

Beyond answering these, a few practices from the security guidance are worth adopting: treat memory writes as untrusted input that needs the same scrutiny as tool calls, record the source and trust level of each entry, expire or review entries on a schedule, require human approval before high-impact memories change consequential actions, and limit what shared memory can reach.

How ZizkaDB helps

ZizkaDB is an open source causal database for AI agents. It does not detect poisoned content or block injection, and it should not be your only control. What it provides is the record that makes the five questions answerable. In practice:

Provenance for every memory. Each event links to the event that caused it. Log a memory write as a child of the step that produced it, and one call walks it back to the source document or message:

python
await db.log(
agent="ap-agent",
event="memory_written",
data={"text": "Supplier bank details changed", "subject_id": "supplier_113"},
parent_id=source_event_id,
importance=0.8,
)
(await db.why(memory_event_id)).print()

Scoping the damage. The API has an impact route that walks the graph downstream from an event, so you can list every later action that depended on a bad memory. I could not confirm that the context function logs which memories it supplied, so log a retrieval event listing them and make the next model call its child. Then the impact route finds the payments.

Retiring without erasing. Writing a new event with a supersedes reference removes the old fact from retrieval and search while keeping it in the log. The harm stops and the evidence stays.

Knowing what the agent knew. The time travel function reconstructs state at a given timestamp from the state events you log, which answers what the agent believed on the day of a disputed payment.

A trail an attacker cannot quietly edit. Each event carries a SHA-256 checksum and a chain hash linking it to the previous one, so editing or deleting a row breaks verification. Store the chain head outside the database. This protects the record, not the content: it proves entries were not changed afterwards, not that they were true.

Ranking by importance and recency, and a self-hosted default of keyword search, help in a smaller way by letting old and minor notes fade from retrieval.

The opening scene, replayed

Return to the accounts payable agent and the payment that went to the wrong account. With the record above in place, the investigation runs in an afternoon instead of weeks:

Start from the wrong payment. Run the lineage call on the payment event. The chain shows the memory entry the agent relied on, and that entry's parent is the invoice email from three weeks earlier. That answers where it came from.
Read the source. Open the parent event. The hidden line of text is there, along with the session it arrived in. You now know it was an input problem, not a model error, which decides the fix.
Scope the damage. Run the impact route on the memory write. It lists every later action that retrieved the note: two payments and one supplier lookup. You review three actions instead of three months of activity.
Date the start and check the state. The write event carries its timestamp. Reconstruct the agent's state for the day of each payment to confirm what it believed at the time, which is the answer you give the supplier and your auditor.
Retire without erasing. Write the correct bank details as a new event that supersedes the bad one. The bad note leaves retrieval immediately, and stays in the log as evidence.
Prove the trail is intact. Run chain verification and compare the chain head with your stored copy. If it matches, you can tell an auditor that the record was not altered after the fact.

The same steps work for the accidental and stale versions of the problem, where there is no attacker and the cause is a wrong guess or an outdated fact.

Which question each capability answers
Question What answers it
Where did this memory come from? Causal lineage from the memory write to its source event
What did it influence? The impact route, using retrieval events you log
When did it start? The timestamp and sequence number on the write event
What did the agent know that day? Time travel over the state events you log
Can I retire it and keep the evidence? Supersedes, plus the tamper-evident chain

The honest scope: ZizkaDB turns a mystery into an investigation. It will not tell you a memory is malicious, and the open source edition records one agent per install, so multi-agent shared memory tracing is a Cloud capability.

Start this week

Pick one agent with memory and ask the five questions about its most important stored fact. If you cannot answer where it came from and what used it, start logging memory writes with a parent link and retrievals with a list of what was supplied. Then rehearse the incident: plant a harmless false fact, find it, scope it, retire it, and confirm the trail survives.

Want to test ZizkaDB on your agent? Try our open source version here: https://github.com/ZIZKA-AI-SL/ZizkaDB

Interested in a design partnership? Fill in the form on our site or reach me directly at [email protected]

Sources: Christian Schneider, Memory poisoning in AI agents · Ars Technica via Harvard Tagteam, Gemini long-term memory hack · Akto, Memory poisoning in AI agents · Trojan Hippo, arXiv · Memory Poisoning Attack and Defense, arXiv · LangProtect, Memory poisoning threat model · Vectorize, OWASP ASI06 · PointGuard AI, OWASP ASI06 · Mem0, AI memory security · ZizkaDB changelog · ZizkaDB repository