What is Memory Poisoning?

Why It Matters

Memory poisoning is the attack that outlives the session. Where prompt injection reaches the model once, a poisoned memory entry reaches every future run: a corrupted preference, a falsified fact, an injected instruction written into the state the agent reads at the start of each task. The OWASP agentic list names it ASI06, and the reason it earns its own entry is persistence: the attack lands in one run and pays out in all of them, while every per-run check sees a normal-looking context.

Why It Evades Single-Run Checks

The poison looks like legitimate state. A memory entry has the same shape whether it was learned from real work or written by an attacker, so reading the store is not a check.

The steering is invisible per-run. Each decision influenced by the poison is individually defensible; the corruption only shows as a pattern across runs.

The write path is the vulnerability. Anything that can influence what gets committed to memory (tool outputs, retrieved content, the agent’s own summaries) is a poisoning channel, which is why memory writes need the same scrutiny as actions.

Where Defenses Break

The common failure is treating memory as trusted storage: entries are written without provenance and read without verification, so the store is simultaneously the agent’s most influential context and its least checked input. The counter-controls from the OWASP mapping are integrity checks on episodic memory and hash-chained audit logs that make the memory’s history tamper-evident, so a poisoned entry is traceable to when and how it was written.

How Flytebit Handles It

Memory in the systems we ship is treated as untrusted input: writes carry provenance, the store is integrity-checked, and the audit trail makes a poisoned entry reconstructable rather than invisible. The containment side (a poisoned memory cannot widen the credential scope) comes from the containment layer. The incident context is in Agentic AI Horror Stories.