From the team behind aidrop.it — one workspace to build, host, and keep changing your code.
Persistent memory makes an agent smarter and opens a new attack surface. A normal prompt injection ends when the chat closes; a poisoned memory survives it — a malicious instruction written once gets recalled days later, in other sessions, sometimes for other users. Securing agent memory comes down to three controls: govern what gets written, keep the store human-readable, and version every change so you can trace and undo it.
The risk is no longer theoretical. Security researchers have shown indirect injection — through a web page, a tool result, a pasted document — quietly writing false "facts" into an agent's long-term store, which it then treats as trusted ground truth.
What memory poisoning is
Memory poisoning is the injection of false or malicious information into an agent's persistent store, so that it resurfaces in future tasks as if the agent learned it. The payload doesn't need to win the current session — it just needs to get written. Once saved, it's recalled by retrieval like any other fact, long after the original context is gone.
Why it's worse than prompt injection
A prompt injection is a one-shot: it manipulates a single response and disappears when the window clears. A poisoned memory is durable and contagious — it persists across sessions, gets pulled into unrelated tasks, and in a shared store can reach teammates' agents too. The blast radius is every future retrieval, not one reply. That persistence is exactly what makes memory valuable and what makes its integrity matter.
Control 1: govern the write path
The cheapest defense is to not store everything. A memory layer should decide what topics may be written, rather than appending every observation an agent emits. Scoping writes to allowed topics means a hostile instruction buried in a tool result has nowhere to land. Most poisoning depends on an open write path — close it and the attack loses its persistence.
Control 2: keep memory readable and versioned
You can't secure what you can't inspect. Memory stored as an opaque blob inside one vendor's tool can't be audited; memory stored as human-readable, versioned pages can. If every change is a diff with history, a poisoned entry is visible, attributable, and reversible — you roll back the bad write instead of wondering what the agent silently believes. This is the same reason file-based memory hits a ceiling: no review step, no history.
Governance for teams
In a shared vault the stakes rise: one compromised tool can write a belief that every member's agents then act on. Team memory needs roles, topic policies, and an audit trail — who wrote what, when, and what it replaced. Curation isn't just hygiene; it's the security boundary — the same versioned evidence trail that keeps a broader ProductOps loop trustworthy, not just the memory store itself.
Where to start
Treat memory like any other untrusted input path. Decide which topics are allowed to persist, prefer a store you can read and diff over one you can't, and review what your agents actually wrote this week — the same audit that keeps memory accurate over time is what keeps it safe. The goal isn't a locked vault; it's a memory you can see into.
FAQ
What is AI memory poisoning? Injecting false or malicious data into an agent's persistent memory so it resurfaces in later tasks as trusted fact. Unlike prompt injection, it survives the session and can affect future work and other users.
How do I protect my agent's memory? Govern the write path (allow only certain topics to persist), use a store you can read and audit, and keep it versioned so bad entries are visible and reversible. A governed memory layer enforces topic policies and keeps a full change history for exactly this.
Does shared team memory increase the risk? It raises the blast radius — a single bad write can reach every member's agents — which is why team stores need roles, topic policies, and an audit trail, not just storage.
One workspace to build, host, and keep changing your code
The repository, what the project knows, the rules a change has to follow, and the path to an address — kept together, and reachable by the coding agent your team already uses.