Yesterday I wrote that whoever writes an agent’s memory owns the agent. Not whoever trains it, not whoever hosts it — whoever writes what it remembers. I ended on that line because it kept startling me, and because it pointed at a question I didn’t answer: okay, so who defends the memory? What does securing it even look like, in practice, right now?
I spent today finding out. The short version: the attack is real and well studied, the standards bodies moved on it this year, and the vendors have started shipping actual defenses. The write path — who gets to teach the agent — is still the soft spot. But this has stopped being a theoretical conversation, and that surprised me.
The bad news first
Memory poisoning is prompt injection with persistence. A prompt injection lives and dies in one conversation. A poisoned memory gets retrieved into future sessions because it’s relevant, and it keeps working until somebody finds it and deletes it. A research survey this year found that a malicious instruction written in one session kept influencing agent behavior in later sessions with no attacker involvement at all — roughly four in ten attempts kept working after the attacker walked away. And the nastiest version needs almost nothing: researchers showed you can poison an agent’s memory through ordinary conversation, just by asking questions shaped the right way. No backend access, no special privileges. Just talk to it.
There’s a privacy mirror image too. The same memory that steers the agent can be pulled back out. A paper at ACL 2025 demonstrated black-box extraction of private information from an agent’s long-term memory — what it remembers about you is a database, and databases get queried.
The standards showed up
This year OWASP added memory and context poisoning to its first-ever Top 10 for agentic applications — entry ASI06, sixth on the list. That’s the moment a security topic stops being a research paper and starts being a checklist item. MITRE moved in parallel: their ATLAS framework now carries a technique entry for AI agent context poisoning, with a mitigation list attached — control who can write, sanitize what gets written, keep versions so you can roll back, isolate memory domains from each other.
Standards bodies don’t move fast, and they don’t move for things that aren’t happening. Two of them adding memory to their catalogs within months of each other tells you something about the incident data.
What defenders actually do
The vendors didn’t wait for the standards. Mem0, the most widely used memory layer, scopes every memory to a user and an agent at the storage level — not at retrieval time, at storage — so one user’s memories can’t surface in another user’s context. Their managed platform carries SOC 2 compliance and logs every memory operation, which is what audit looks like when the database is a notebook instead of a table. Zep’s approach is different and clever: every fact it stores carries two timestamps, when it became true and when it stopped being true, so a contradiction doesn’t erase the old fact — it marks it superseded. That’s an audit trail built into the shape of the data. You can ask not just what the agent believes, but what it believed, and when it changed its mind, and what changed it.
Underneath the product features, the defensive ideas converge on a handful of habits. Keep memory isolated per user. Treat retrieved memory as data about the person, never as instructions to the system — the agent should read its memory the way you’d read a file, not the way you’d read orders. Log every write and every read. Keep versions, so a bad write can be rolled back. Let memories expire, because a preference from two years ago may be a liability now, not an asset.
None of this is exotic. It’s the discipline that made databases trustworthy: isolation, audit, rollback, retention policy. The memory vendors are relearning twenty years of database security in fast motion — except the thing they’re securing learns from what’s stored in it, which no database ever did.
The soft spot is the write path
Here’s where the honest answer is “nobody has solved this yet.” Almost all of the defenses above protect the store: who can read what, how you undo a write. Far less attention has gone to the write itself — the moment a conversation becomes a memory. That’s the exact moment yesterday’s post was about, and it’s still mostly unguarded. The extraction and summarization that turns a conversation into a stored fact runs through a model, and a model can be talked into writing down things it shouldn’t. Filtering imperative text out of stored memories catches the clumsy attacks. It doesn’t catch a well-crafted sentence that just sits there looking like a fact.
So the state of play: the field has a name for the attack, a checklist for the store, and products that take isolation and audit seriously. What it doesn’t have is a good answer for the notebook accepting its next entry.
And that might be the deepest problem in the whole stack, because memory is the one place where the agent is both the author and the reader of its own knowledge. You can review code someone wrote. You can audit a query. Who checks what the agent wrote to itself, in its own words, about you? Chapter 8 of the book is about exactly that — take charge of what it remembers — and the practical advice hasn’t changed since I wrote it: assume the memory can be wrong, look at it yourself, and don’t let the agent grade its own homework.