Memory poisoning is an attack that plants a false fact, a manipulated preference, or a hidden instruction into an AI agent's persistent memory, so it gets recalled and treated as trustworthy in future sessions, sometimes long after the interaction that planted it. Unlike a prompt injection that only affects the current conversation, a poisoned memory keeps paying off for the attacker every time the agent retrieves it, which makes memory one of the highest-value targets in an agentic system and one of the least monitored. Most teams review what an agent says in the moment. Far fewer review what it decides to remember.
Why memory is a different kind of attack surface
A single-turn manipulation ends when the conversation ends. A memory-based manipulation persists across sessions, users, and sometimes even across the agent's own updates, if the memory store itself doesn't get cleaned out during changes. That persistence is the whole point for an attacker: plant something once, and it can influence behavior repeatedly without needing to repeat the attack. It also means the damage window for memory poisoning is open-ended until someone specifically audits what's stored.
Common ways poisoned content gets written
An agent that summarizes a conversation and stores the summary as a fact can be manipulated into storing something false, simply by an attacker phrasing a claim confidently enough during the conversation. An agent that extracts "user preferences" from support tickets can have a malicious preference planted through a fabricated ticket. An agent operating in a shared or multi-tenant memory store can be exposed to poisoning through any tenant whose input isn't properly isolated from others, turning one user's manipulation into everyone's problem.
The recall step is where damage actually happens
Poisoning only matters once the poisoned entry gets retrieved and acted on. That retrieval step is worth defending on its own terms: does the agent treat memory entries with appropriate skepticism, or does it grant them the same authority as a verified fact just because they came from its own storage. Many agent architectures don't distinguish between "verified" and "unverified" memory at all, which means a single successful write can carry full authority indefinitely.
Why detection is genuinely hard
There's rarely an obvious signal that memory has been poisoned, because the agent behaves consistently with what it "remembers," and that consistency looks like correct operation from the outside. Detecting it usually requires either auditing memory contents directly against known-good data, or noticing behavioral drift, an agent making decisions that don't match its expected policy, and tracing that drift back to a specific stored fact.
Isolation and expiration reduce the blast radius
Two structural changes help even without perfect detection: isolating memory per user or tenant so one person's poisoning attempt can't cross into another's session, and applying expiration or periodic re-verification to stored entries so a poisoned fact doesn't sit unchallenged indefinitely. Neither eliminates the risk, but both shrink how far and how long a successful poisoning attempt can matter.
Model and framework updates can reset trust assumptions
When the underlying model or agent framework gets upgraded, the way memory gets read, summarized, or weighted can change in ways that aren't obvious from the release notes. A memory architecture that assumed the model would always treat certain entries as lower-confidence context might behave differently after an update that changes how the model handles long context or memory retrieval internally. This means a poisoning risk that was adequately contained under one model version isn't guaranteed to stay contained after the next one, and memory-handling logic deserves a fresh look whenever the underlying model or framework changes, not just when the memory store's own code changes.
Where TELEON fits
TELEON's audit trail of agent and tool activity gives teams a practical way to trace behavior back to its source, including cases where an agent's decision pattern shifts in a way that correlates with a specific stored memory entry, which is often the first real lead in investigating suspected poisoning. Policy enforcement at the tool-call boundary also limits what a poisoned memory can actually cause, since even a fully successful poisoning attempt still has to pass through an action-level check before it results in a real-world effect.
Designing the memory architecture itself, isolation boundaries, verification of stored facts, expiration policy, is application-level work specific to how each system implements memory, and it needs deliberate attention rather than being left as a default of whatever framework the team happened to pick.
A short checklist
- Isolate memory storage per user or tenant, never share one pool by default.
- Distinguish verified facts from unverified summaries within the memory store.
- Apply expiration or periodic re-verification to stored entries, especially preferences.
- Audit what an agent writes to memory, not just what it retrieves and uses.
- Watch for behavioral drift that might trace back to a specific memory entry.
- Require higher confidence for actions triggered mainly by recalled memory.
- Test memory poisoning scenarios directly, not just prompt injection in a single turn.
Memory gives an agent the ability to build on past interactions instead of starting fresh every time, and that's genuinely useful. It also means every past interaction is a chance for something false to get written in permanently. Treating memory writes with the same scrutiny as any other consequential action, rather than as harmless bookkeeping, closes one of the quieter gaps in agentic systems.