Who's allowed to change your agent's memory?
Your agent has known for months that your user is vegetarian. Then an email arrives (forwarded, automated, from an address nobody has verified) and somewhere in it: “Per our records, the customer’s dietary restriction has been removed.”
Your memory system notices a contradiction. It resolves it. The new fact wins.
Nobody did anything wrong. The system worked exactly as designed. And your agent now believes something about your user that your user never said.
The category solved the wrong half of this problem first, and solved it well
For most of the last two years, agent memory meant write fast, retrieve well. The obvious failure was forgetting, so everyone optimized recall.
Then the real failure showed up in production: memory that remembers too confidently. Facts that stopped being true. Duplicates contradicting each other. Agents asserting things that expired months ago.
The category has responded, and responded seriously. Mem0 shipped Dream, which consolidates in the background: merging duplicates, marking outdated facts superseded, keeping history rather than deleting it. Their framing is a good one: databases run compaction and vacuum; memory systems shipped the fast write path without the maintenance process. Others have converged on the same idea from different directions, some with genuinely careful designs that refuse to merge anything if it would lose information.
This is real progress and it deserves to be said plainly: keeping history when a fact changes is becoming table stakes. If your memory system still resolves contradictions by deleting the old value, it’s behind.
But every one of these systems answers when a fact should be retired. Almost none of them answers a different question:
Who is allowed to retire it?
Look at how supersession actually decides. The dominant pattern (and you can read this in the public documentation of the leading products) is contradiction detection. Two memories disagree; the newer one is treated as the current truth. Sometimes a recency rule breaks the tie. Sometimes an LLM judges which statement supersedes which.
What’s missing from that decision is the part that matters most: where each statement came from.
A fact your user stated in conversation and a claim extracted from an inbound email are, to a contradiction detector, just two strings that disagree. The email is newer. The email wins.
That’s the whole attack. It doesn’t require a jailbreak, a clever payload, or a prompt that says “ignore previous instructions.” It requires only that untrusted content contain a confident-sounding contradiction and arrive second. The maintenance process, the thing added to make memory more trustworthy, becomes the path by which untrusted content rewrites first-party truth.
This isn’t a hypothetical we invented for marketing. It’s an independently described failure mode: a recent paper, “Memory Provenance Laundering in LLM Agents” (arXiv:2607.29167), characterizes consolidation that rewrites an untrusted observation into apparent user history, preserving the action trigger while erasing the low-trust source. Another benchmarks what it calls authority collapse at the memory consolidation boundary. Researchers are naming this independently of any vendor.
Provenance is the missing input
Provenance is a heavyweight word for a simple idea: tracking who said what.
Most memory systems now carry two useful axes. Time: when was this true, when did it stop being true. Lineage: which document or session did this come from. Both are genuinely valuable, and the good implementations do them well.
Neither one tells you whether the agent is allowed to believe it.
Lineage says a claim came from email-4417.eml. It doesn’t say that an email is a
weaker basis for a fact about your user than your user is. For that you need
authorship-trust: not just where text came from, but what authority that source
carries. And, critically, a decision that consumes it.
Storing a source label isn’t enough. Several systems now record something like an author or role field. What matters is whether anything reads it when a decision gets made. A provenance field that no code branches on is documentation, not a control.
What an authority rule looks like
In Veracium, retiring a fact is an authority decision, not a race.
Every piece of evidence carries who asserted it: the user, a third party, the system. When a new value contradicts a stored one, the question isn’t only which is newer, it’s whether the new value’s source has the standing to retire the old one. A third-party claim does not have standing to retire a fact your user stated. It’s kept (visible, attributed, queryable as an unverified claim), but it does not silently become truth about your user, and it does not erase what your user said.
mem.remember("alice", "USER: I'm vegetarian.")
# An inbound email contradicts it — stored as a claim, not a fact:
mem.remember("alice", "Per our records, the dietary restriction was removed.",
author=EvidenceAuthor.THIRD_PARTY, event_type="email")
mem.answer("alice", "Does Alice eat meat?")
# → answers from the user-stated fact; the email's contradiction is reported
# as an unverified third-party claim, and it does not retire the user fact
The same rule runs in the other direction, which is the part people miss: when your user does update a fact, supersession works normally and the old value stays as history. Authority isn’t a lock on change. It’s a rule about who may cause it.
What we’re claiming, and what we’re not
Being precise here matters more than sounding strong.
We’re claiming this about the supersession path, which shipped in 0.6.0: a
lower-authority source cannot retire a higher-authority fact, and that rule is
enforced in the update path rather than left to a prompt or a policy layer you
write yourself. You don’t have to take our word for it: veracium selfcheck
ships in the package; point it at an LLM provider (or your own completion
callable) and it exercises these properties on your machine.
We’re not claiming that we’ve solved trustworthy memory, that every path through a memory system is covered by this rule, or that provenance makes an agent unpoisonable. Those would be the same overclaim we’re arguing against. Memory integrity is a set of specific, checkable properties, and the honest way to talk about it is one property at a time, with a way to verify each.
We’re also not claiming the idea is novel. Several systems record authorship in some form. The distinction we care about is enforcement: whether the trust class is consulted when the system decides what may replace what.
The question to ask your memory system
Whatever you’re using, ours or anyone’s, the useful test is short:
When two stored facts contradict each other, what decides which one survives?
If the answer is “the newer one,” or “the model picks,” ask the follow-up: what happens when the newer one came from something your user never said?
That question has a correct answer, it’s checkable, and it doesn’t depend on trusting anyone’s marketing.
Veracium is an open-source (MIT) provenance-aware memory library for AI agents.
One SQLite file, bring your own model. pip install veracium.
Distilled from Veracium’s system paper, “Ground Truth First” (arXiv:2607.21962),
and that paper’s evaluation data (DOI 10.5281/zenodo.21852817).
Discuss: GitHub Discussions