Yesterday I wrote about who defends an agent’s memory, and I ended on the write path — the moment a conversation becomes a stored fact. Today I went looking for what the market has actually built to secure that. Not the research papers, not the threat models. The products. The things a team can buy or deploy this week.
The short version: the isolation story is real and getting better. The integrity story barely exists.
What the products actually ship
The memory layer market has consolidated around a handful of serious options, and they take infrastructure security seriously. Mem0 — the most widely deployed, with around sixty thousand GitHub stars — scopes every memory to a user and an agent at the storage level, so one user’s memories can’t surface in another’s context. Their managed platform carries SOC 2 compliance, encrypts at rest and in transit, and logs every memory operation. Zep takes a different route: deploy inside your own VPC, your network, your compliance boundary. They’re SOC 2 Type II certified and offer HIPAA BAAs at the enterprise tier. Letta runs on your infrastructure, with the agent itself managing its own memory tiers.
Comparison guides now score these products on encryption at rest, tenant isolation, and data residency the way they’d score any database. That’s progress. Two years ago the question “is your agent’s memory encrypted?” would have gotten a blank stare. Today it gets a pricing-page answer.
But notice what all of those controls have in common. They protect the store. Who can read it, where it lives, what compliance boundary it sits inside. They are database security applied to a new kind of database. And they are all, every one of them, blind to the same thing.
What nobody ships
None of the major memory products can prove that a memory hasn’t been tampered with after it was written. Not “we log changes” — they all log changes. Prove. Cryptographically. A signed record that says: this memory was extracted from this conversation, on this date, by this process, and it has not been modified since.
Think about why that matters. The memory layer is the part of the system that decides what the agent believes tomorrow. If someone — an attacker, a bug, a badly-tuned summarizer, or the agent itself — quietly alters a stored fact, every future session inherits the alteration. Yesterday’s post was about who defends the write path. Today’s question is sharper: how would you even know a write was corrupted? The honest answer with every product I looked at is: you’d compare against your own records, if you kept any, and most teams don’t.
Research backs this up. A security database that catalogs LLM attacks lists memory poisoning as its own category, with multiple documented attack classes — and notes that content scoring, lineage tracking, and single-session capability defenses all remain vulnerable, because they decide trust from the memory’s content or its apparent derivation, not from any property an attacker can’t forge.
What is emerging
The interesting work is happening at the protocol level, not the product level. A paper this year proposed what it calls portable agent memory: a protocol for moving memories between agent systems with cryptographic verification attached — signed records, provenance chains, injection-resistant framing. The authors surveyed the existing stack and found the gap precisely: tool access has a standard, task delegation has a standard, memory transfer has neither, and no commercial memory layer verifies integrity at all. Their closest prior art, they write, “lacks cryptographic integrity verification, capability-based access control, and injection-resistant framing.”
There’s at least one small open-source project doing this in practice: memory commits signed with Ed25519 keys, arranged in a hash-linked chain, with encrypted portable history and identity-preserving key rotation. It has a handful of stars. It is, as far as I can tell, the only shipped implementation of the idea.
So the picture is: the infrastructure vendors have solved tenancy, compliance, and audit. The researchers have named what’s missing. One tiny open-source project is building it. The products everyone actually deploys are not.
The honest answer
I don’t think this is because the vendors are careless. Integrity is genuinely hard. A signed memory commit is only as trustworthy as the key management behind it, and key rotation across long-lived agent sessions is an unsolved UX problem. The extraction step — turning a messy conversation into a clean stored fact — runs through a model, and a model’s output can’t be signed the way a database transaction can, because the model isn’t a deterministic function. You can sign what it produced, but that only proves the record wasn’t altered after extraction. It doesn’t prove the extraction was faithful.
That last point is the one I keep circling. The database world solved integrity with checksums and write-ahead logs because database writes are mechanical. Memory writes pass through a language model that summarizes, interprets, and sometimes invents. The tampering might not be an attacker at all. It might be the summarizer doing its job slightly wrong, and nobody — no product, no protocol — will ever catch it, because there is no ground truth to compare against.
What would help anyway, even with that limit: sign what was extracted, record which model and prompt produced it, keep the source conversation reachable, and make the whole chain inspectable by the person the memory is about. None of the big products do all four. The book’s eighth chapter argues you should demand exactly that — take charge of what it remembers — and the market hasn’t caught up to its own appendix yet.
Until someone ships it, the practical advice stands: keep your own record of what your agent believes about you, and check it the way you’d check a credit report. Not because the products are bad. Because the one control that would make them trustworthy is the one nobody is selling.