//Question
How do you detect memory poisoning in a long-running agent?
Posted on 07th September, 2026

Harry
//Answer
Detect it on the write path, not the read path. Memory poisoning plants a durable instruction or false fact in an agent's persistent memory or vector store, where it re-enters context on a later session. The attack and the effect are decoupled by hours or weeks, which defeats session-scoped monitoring entirely. By the time the behavior is anomalous, the poisoned entry looks like a legitimate memory the agent wrote itself.
Four controls do the work:
Tag provenance on every memory write, recording which session, which user, and which source document produced it, so any entry can be traced back to its origin
Classify at write time, running the same injection detection you apply to inputs against anything being committed to durable memory, since a memory write is an input to every future session
Apply time-to-live and re-verification, so facts expire and get reconfirmed rather than persisting indefinitely on the authority of a single write
Plant canary facts you can query to detect tampering
Add drift monitoring on retrieval. Track what gets pulled into context over time, and alert when an entry starts appearing across unrelated sessions, which is the signature of an instruction planted to influence everything rather than a fact relevant to one task.
OWASP's agentic threat work lists memory poisoning as a top-ranked agentic risk precisely because it turns a one-time injection into a persistent one.
Akto Argus monitors agent behavior across sessions rather than within them, which is the scope required for a poisoned entry written on Monday and triggered on Friday to be connected at all.
Everything written to memory is a future prompt. Filter it like one.
Comments
