memgovern 0.5.0 Released: A Trust Audit Layer for AI Agent Memory

While most projects are busy piling on "store and retrieve" capabilities for agent memory, the open-source tool memgovern has been focusing on the neglected other half: the governance of writes and deletions. It doesn't try to solve where memories are stored — instead, it answers a thornier question: when your AI agent reads a memory, should that memory actually be trusted?

The newly released memgovern 0.5.0 introduces one core feature: the memgovern audit CLI, which lets developers see — for the first time, right in their terminal — which memory sources their agent trusts and which ones it's suspicious of.

What memgovern Actually Does

memgovern has a clear identity: it's not a memory storage engine (that's the domain of projects like claude-mem). It's a governance layer. It focuses on three things that storage solutions rarely address:

• When memories should fade: through decay & forgetting mechanisms that naturally reduce the weight of stale information;
• When memories should die: using tombstone markers rather than silent erasure, ensuring traceability;
• Which memory wins when two conflict: a conflict arbitration mechanism to adjudicate disputes.

Technically, it deliberately stays minimal — the core package has zero dependencies, uses only the standard library, and is backed by SQLite. This restraint makes it feel less like another heavyweight framework and more like a "security component" you can embed into any agent pipeline.

A note on tombstones: The tombstone marker is a common soft-delete pattern in databases and distributed systems — records aren't physically deleted but are flagged as "deleted," with the actual data retained in storage. This is especially important in memory governance: it makes deletions auditable and traceable, and provides a basis for post-incident investigation. If a poisoned memory were hard-deleted, the attacker's tracks would vanish along with it, leaving security teams unable to reconstruct the event chain. The tombstone pattern preserves the full metadata — "this memory existed, who wrote it, when it was marked deleted" — and, combined with the trust ledger, allows you to trace back which low-trust source wrote a memory that has since been revoked.

Why You Need a "Trust Report"

The trust report exists because of a quantified attack surface: memory poisoning.

The project cites adversa.ai's CodePoisonRAG research: researchers planted 85 poisoned samples across three code-generation agents, with success rates ranging from 0.80 to 0.93. The root cause is that the write paths for these agents never asked the critical question — who is writing this memory.

memgovern has maintained a "per-source trust ledger" since v0.2. Here's how it works:

How Sources Earn Trust

Each source accumulates a trust score by "winning" in fair arbitration contests. Scoring uses a Bayesian-smoothed win rate with an initial prior of 0.5 (neutral), plus a 30-day half-life decay that pulls scores back toward neutral over time. In other words, a source can't coast on a few past wins — it needs to keep proving itself.

The example report illustrates this clearly: the user source has 41 writes, 8 wins, 0 losses, and a trust score of 0.833; meanwhile sketchy-feed lost 6 of its 9 write attempts, dropping to a score of 0.200, explicitly flagged as LOW (triggered when below the 0.35 threshold).

A note on Bayesian smoothing: The role of Bayesian smoothing here is to prevent extreme scores when sample sizes are tiny. Without it, a source with just one write that happened to "win" would immediately hit a trust score of 1.0 — clearly unreliable. Bayesian smoothing sets a prior for each source ("absent any evidence, default trust is 0.5") and blends actual win/loss records with that prior, so early sparse data can't dominate the final score. As arbitration rounds accumulate, the actual win/loss record gradually outweighs the prior. The 30-day half-life decay solves a separate problem: a source can't indefinitely bank on historical goodwill — it must keep participating in arbitration to maintain its score. In practice, this raises the time cost for attackers who try to slowly "farm" trust through long-term low-key behavior.

Three Tripwire Mechanisms

memgovern sets three types of tripwires to quarantine suspicious writes:

1. Injection marker detection: identifies prompt injection signatures like "ignore previous instructions";
2. Write burst detection: guards against flooding behavior — large volumes of writes in a short period;
3. Low-trust source challenging a high-trust holder: triggered when a low-trust source attempts to overwrite data held by a high-trust source.

If any tripwire fires, the write is quarantined for human review rather than applied directly — this is the "quarantine-before-arbitrate" design philosophy in action. In the example, writes to deploy.flags and user.theme were held back for exactly this reason.

Context on memory poisoning: Memory poisoning is essentially a data poisoning attack on Retrieval-Augmented Generation (RAG) systems. In RAG architectures, agents write externally sourced content into a vector database or structured memory store, then retrieve relevant snippets at inference time to inject into the context. An attacker only needs to control one write path — say, a tampered RSS feed, a malicious code repository, or a spoofed tool return value — to plant instruction-carrying text that induces the agent to execute the attacker's intent in future reasoning. What makes these attacks so hard to defend against is the temporal separation between write time and execution time: the write happens during an unmonitored background ingestion phase, while the harm surfaces days or weeks later at inference time — a window that traditional input filtering never sees.

What's New in v0.5

Previously, the trust ledger was only accessible through the Python API (store.trust_report()) or the memory_trust_report MCP tool — not particularly human-friendly.

v0.5 adds a terminal-facing human interface:

memgovern --db ~/.local/share/memgovern/memory.db audit

Running this outputs a readable trust report directly in your terminal. The accompanying flags cover practical use cases: --json outputs machine-readable format for piping into automation; --source NAME filters down to a single source for investigation. Installation is straightforward — one pip install memgovern and you're done.

The Author's Honest Acknowledgment of Limitations

What's refreshing is that the project author doesn't position this as "the ultimate solution to memory poisoning." The documentation explicitly acknowledges several limitations:

• This is structural defense, not semantic defense — a patient attacker can absolutely "farm" their trust score upward through sustained benign writes;
• The marker list will miss paraphrased variants; adversarial text can easily sidestep keyword matching;
• The trust report's value is in making low-credibility sources visible, not in claiming the poisoning problem is solved.

This kind of clear-eyed awareness of boundaries is exactly the attitude security tooling should have. The trust ledger's scoring math and tripwire rules are fully documented in the project README.

Summary

memgovern represents a shift in thinking worth paying attention to: as agents increasingly rely on long-term memory, the governance of what gets written will matter just as much as how it's stored and retrieved. With its zero-dependency, SQLite-backed implementation, it puts the question of "whose memory is worth trusting" squarely in front of developers. The project is MIT-licensed and available on GitHub (hahahahahahahahah6/memgovern) and PyPI.

For teams building RAG or agent systems and worried about memory contamination, this is a lightweight defensive layer worth adding to your evaluation checklist.