Blog
Agent memory security: defending the write path
Prompt injection has a second, quieter blast radius most of the field is ignoring: memory poisoning. The model writes something wrong into permanent, trusted memory, and every future agent reads it as fact.
Prompt injection has a second, quieter blast radius most of the field is ignoring: memory poisoning. Not “the model said something wrong once,” but the model wrote something wrong into permanent, trusted memory, and every future agent reads it as fact.
The attack is real, and buyers are already asking for the defence
- MemGhost (Jul 2026) plants persistent instructions in agent memory.
- MINJA and the “untrusted-input to trusted-memory” literature show a legitimate, already-authenticated agent can be steered to write poison through the content it reads, with no stolen credentials.
- OWASP now runs an Agent Memory Guard project, and its Agentic Security Initiative tracks memory poisoning as ASI06. LLM-security databases track it as its own vulnerability class.
- Most telling: Mem0’s own users filed an issue requesting built-in memory-poisoning protection. The demand is coming from inside the incumbents’ user base.
Why “self-building” memory is exposed by default
Most agent-memory systems are self-building: the agent doing the work also decides what enters memory and writes it directly. It is a sensible default, and it is also the injection surface. A perfectly-authenticated agent reads a booby-trapped document and commits the poison as a trusted fact, because nothing independent checked the write.
This is an architectural property of self-building memory, not a knock on any one product: the leading systems (Mem0, Zep, Cognee, Letta, Anthropic’s memory) all take the direct-write path, and the common mitigation is a read-only switch: turn learning off. Gather’s bet is that you should not have to choose between learning and safety.
Gather’s answer: the writer never decides
A candidate fact travels a review pipeline before it becomes part of your trusted memory. The rule is simple: the agent that proposes a write is never the one that commits it. Who commits is a policy you set per tenant: an automated judge, a human in the queue, or direct writes for trusted owner keys.
- Deterministic screen. The security boundary an attacker cannot talk to.
- Distiller. Normalises the claim to a checkable statement.
- LLM reviewer. A semantic admit or reject, made by a party separate from the agent that proposed it.
- Multi-model panel. For the ambiguous tail, a for-and-against consensus beats one model’s snap call.
- A guard on every promotion. Updates a fact while keeping the old version in history, with a mandatory alert on every auto-promotion and a daily cap.
The proof: the same planted instruction a normal memory saves every time, ours rejects every time, because the defence is a property of the architecture (the writer never also admits), not a model trick.
Curation is a dial, not a wall
Approve every write yourself, let an automated judge admit clean facts from trusted sources, or write directly with an owner key. Set it per tenant. The one thing you cannot switch off is separation of duties: the writer is never also the admitter. That is the property an attacker cannot talk around, whichever mode you run.
Layered gates, not a single check
Poisoning is not one attack, so the defence is not one gate. Two are live today; the third is on the roadmap for the highest-stakes writes.
| Gate | Defends against | Status |
|---|---|---|
| Reviewer | Poisoned content: a semantic decision made by a party other than the agent that wrote it | Live, the differentiator |
| Attestation | A forged, compromised, or rogue writer: every fact traces back to who wrote it and can be pulled, so no single agent can quietly rewrite shared memory | Live |
| Corroboration | A single anonymous voice: the highest-stakes writes require N distinct verified agents to agree, Sybil-resistant because of attestation | Roadmap |
Honest scope
This is an OWASP-recommended control posture (a separate reviewer commits every write, whether that reviewer is an automated judge or a human, plus provenance on every fact plus per-tenant isolation), not a claim of “unhackable.” The point nobody else in agent memory makes: we compete on whether the content entering memory is trustworthy, not just on who can read it.
Sell the property, not the crypto
Buyers do not buy “Ed25519.” They buy the outcome: every fact traces back to who wrote it and can be pulled, and no single agent can quietly rewrite shared memory. That is what an injection-hardened write path delivers.
Portability you can prove
Most memory products will let you export a JSON dump. That answers “can I get my data out.” It does not answer “can I trust the data I got out.” Gather exports every fact with its full history and an Ed25519 signature your security team can re-verify offline, long after you have stopped paying us.
- Full history, not a snapshot. Superseded and retired facts travel with their valid-from and valid-to. You export the record, not just current truth.
- Verifiable after you leave. An Ed25519 signature over the exported facts, checkable offline against our public key. Change one byte and verification fails.
- Your exit is never gated. Every tier can export, including free. A credible way out is a feature, not a paywall.
Every memory API lets you export the data. Gather also exports the proof of how each fact was admitted, because it has a curation receipt to sign. See isolation and attestation for the receipt you can run yourself.