Memory Poisoning: Why Stored Context Needs Review

A memory system is only as trustworthy as what it stores. Memory poisoning is the failure mode where incorrect or malicious content enters memory and later influences an agent's behavior.

How it happens

Memory poisoning does not require an exotic attack. It can happen through ordinary means:

• A source that was wrong at the time it was recorded.
• A claim that was true once and has since been superseded.
• Content that was never verified but stored alongside verified knowledge.
• Deliberate injection of misleading content into a source the agent trusts.

In each case, the stored item looks the same as everything else. Without governance, the agent has no way to tell them apart.

Why a flat store makes it worse

A store of embeddings retrieves by similarity. It has no concept of whether a claim is confirmed or stale. If poisoned content is similar to a legitimate query, it comes back with the same confidence as anything else.

The problem compounds over time. Once poisoned content is retrieved and reused, it can be written back into memory as if it were established.

What reduces the risk

Governance does not make poisoning impossible, and it does reduce the surface:

• Provenance keeps source context attached, so a claim can be traced and questioned.
• A claim lifecycle distinguishes confirmed knowledge from candidates and stale items.
• Conflict review surfaces contradictions instead of silently choosing one version.
• Scoped recall limits how far a poisoned item can travel across projects.
• Secret redaction keeps detected credentials out of ordinary memory.

The short version

Memory poisoning is a governance problem more than a storage problem. The defense is knowing where a claim came from, what status it holds, and whether it conflicts with anything else.

For the security posture, see Security. For the term, see the glossary.