How should a memory layer for LLM agents be governed?

What is memory governance for LLM agents?

Memory governance is the set of rules for what an agent’s long-term memory may contain, who may change it, who may read it, and how long it lasts. It applies the controls a company already uses for policies and code to the store an agent consults before it answers or acts.

Our comparison of memory layers covers what each tool stores. Governance asks where a memory came from, who decided it was right, which version the agent read last Tuesday, and whether you can undo it.

We found no standard written for agent memory. The NIST AI Risk Management Framework, released on 26 January 2023, is “intended for voluntary use” and NIST says it is being revised nist.gov. The EU AI Act requires high-risk AI systems to allow “the automatic recording of events (logs) over the lifetime of the system” (Article 12) and to be “effectively overseen by natural persons” (Article 14) eur-lex.europa.eu. Whether your agent counts as high-risk is a legal question; logging and human oversight are sensible defaults either way.

What goes wrong when agent memory is unmanaged?

Agents act on memories nobody checked, and when an answer is wrong nobody can say which memory caused it. Typical cases:

• An extracted “fact” was a guess the model made from one conversation, and every later session treats it as true.
• A vendor exception expired, but the memory has no end date, so the agent keeps granting it.
• Two documents disagree on a threshold and the newer one wins by accident of retrieval order, with no record of which was used.
• A customer asks to be forgotten, and their details survive in a memory store that the deletion job never touched.
• An agent from one team reads another team’s rules because the store has a single namespace.

Trail’s comparison page describes the accounts payable version: a 3-way match exception whose end date lives only in a prompt, and “Six months of invoices skip the 3-way match and you find out during an audit”. Its answer is an end date stored as a field, so “the rule retires itself” trailhq.com. Our page on AP 3-way match automation from an SOP works through that process.

What should a memory governance policy contain?

Ten controls, each answering a question an incident review will ask. We call them the Trail memory governance checklist. Copy the list, give each line an owner, and note which tool or process covers it.

For the record itself, a minimal schema that covers controls 1 to 6 looks like this:

rule_id: AP-EXC-014
text: "Vendor Alpha may skip the 3-way match under $50,000."
source: { document: "AP policy v7.pdf", page: 12, line: 4 }
proposed_by: ingestion-job        # or a user, or an agent's correction
owner: ap-policy-team
approved_by: j.doe
approved_at: 2026-03-02T10:14:00Z
version: 3                        # previous versions kept, never edited
scope: { tenant: acme, teams: [finance], agents: [ap-agent] }
valid_until: 2026-04-30           # retire, then review
status: approved                  # proposed | approved | rejected | retired

The field names are ours. The agent’s read path should filter on status, scope and valid_until before similarity.

Who should be allowed to write to agent memory?

Anyone may propose; only named owners should commit memories that drive decisions. For low-stakes personal memory, automatic writes are fine as long as the user can see and delete them.

The developer tools we checked leave approval to you. mem0 extracts memories from messages, and its docs say “The automatic extraction path is additive”, with explicit update or delete calls when an application needs to correct something docs.mem0.ai. We found no approval step before storage on its pages. In LangGraph, writing to the long-term store is your application code. Its interrupts “pause graph execution at specific points and wait for external input before continuing” docs.langchain.com, which you could use to hold a memory write until a person approves it. Cognee describes session distillation that “curates accepted lessons into permanent memory” github.com/topoteretes, but we found no approval queue for new memories on its pages.

Keep the proposer and the approver separate: an agent that approves its own memory has no second reviewer, and nor does an admin who can skip review.

What should every remembered rule cite?

The smallest unit a reviewer can check: a document with page and line, a message ID, a ticket, or a system record. A link to a whole folder or a similarity score is not a citation a person can verify.

Cognee documents a provenance view of “tenants, users, agents, datasets, and files” docs.cognee.ai. We found no source citations attached to retrieved memories on mem0’s pages, or to store items on LangGraph’s memory pages. If you build on either, add a source field yourself, refuse writes without one, and pass the citation into the agent’s output so a reviewer can check the answer against the clause.

How should approved agent rules be versioned and reviewed?

Treat a rule change like a code change: a proposed diff with its source, a required review by the rule’s owner, a merge that creates a new version, and a rollback that adds another version and leaves history intact.

GitHub pull-request review is the familiar model. A CODEOWNERS file defines “individuals or teams that are responsible for code”, and code owners “are automatically requested for review when someone opens a pull request that modifies code that they own” docs.github.com. Branch protection can require a set number of approving reviews and dismiss stale approvals when new commits change the diff. By default, protection rules “do not apply to people with admin permissions”, unless you enable “Do not allow bypassing the above settings” docs.github.com, and a memory store needs its own answer to who can skip review.

For rollback, git revert records “new commits” that undo old ones instead of rewriting history git-scm.com. Apply that to rules: reverting rule AP-EXC-014 to version 2 creates version 4 with version 2’s text, and versions 3 and 4 both stay on the record.

mem0’s Platform API can “Retrieve the full change history of a specific memory” docs.mem0.ai. LangGraph’s checkpointers allow “time travel” over a thread’s past states docs.langchain.com, though we found no versioning of long-term store items. Trail-code keeps coding-agent learnings as files in the repo: “A repo learning is a file in your pull request, so it gets reviewed like the code it is about” github.com/trailhq. Business agents usually need the same review flow without asking finance staff to open pull requests.

Who can read which memories, and for how long?

Reads should be scoped by tenant, team, role and agent, defaulting to deny, and every memory class should carry an end date or a review date plus a real deletion path.

Postgres row-level security is a solid base for tenancy. Policies “restrict, on a per-user basis, which rows can be returned by normal queries or inserted, updated, or deleted”, and with RLS on and no policy, “a default-deny policy is used”. Watch the exceptions: superusers and roles with BYPASSRLS always bypass it, and table owners do unless you set FORCE ROW LEVEL SECURITY postgresql.org. Make sure the agent’s database role is none of those.

Cognee isolates memory with “per-dataset storage, dataset-level permissions, and tenants and roles” docs.cognee.ai. mem0’s docs index points to organizations and projects for multi-tenant isolation and to member roles docs.mem0.ai. For LangGraph deployed on LangSmith, custom auth handlers can cover all store operations, but a self-hosted deployment has “No default authentication” docs.langchain.com.

Retention needs two separate controls. Expiry stops a memory being used: mem0’s docs say “Expiration hides a memory, it does not delete it” docs.mem0.ai, which suits a lapsed exception you want to keep on record. Deletion removes data. GDPR Article 17 gives a data subject the right to erasure of personal data “without undue delay” where one of its listed grounds applies eur-lex.europa.eu. In mem0, you can delete by ID or by scope docs.mem0.ai, and Cognee’s forget() removes “one document, a whole dataset, or everything a user can delete” docs.cognee.ai. On LangSmith, “Setting a TTL automatically deletes or prunes expired data” for checkpoints and store items docs.langchain.com. Check that deletion also reaches derived copies: graph nodes, embeddings and caches built from the original.

How do you audit, resolve conflicts and test governed memory?

Log every read and change outside the store, flag contradictions instead of letting the newest entry win, and keep a test set where the right memory decides the outcome.

mem0’s homepage says “Every read and write logged” mem0.ai and its self-hosted server includes “a request audit log” docs.mem0.ai. We found no memory audit log on the Postgres or LangGraph pages we checked, so plan to build one. Record the memory version the agent read, not only its ID, so an incident review can reconstruct what the agent saw on the day.

Cognee’s improve(review_conflicts=True) finds “facts that disagree across dated sources” and stores the conflicts for inspection docs.cognee.ai. A conflict should name both sources and an owner who sets precedence once, in writing.

For evaluation, Trail’s research page argues that LoCoMo, LongMemEval and BEAM “measure retrieval recall, which is only one part of the actual deployment problem” trailhq.com. Build cases from your own exceptions, such as an expired vendor waiver or a threshold that changed in March. Rerun them whenever a memory is approved, edited or retired.

Which tools cover which governance controls?

None of the tools we checked covers all ten controls out of the box. Most cover access and some form of history; few cover approval before read.

Facts in this table were checked against the sources listed at the end of this page, between Oct 16, 2026 and Oct 21, 2026.

A common build is Postgres with RLS for tenancy, a memory framework for extraction and a review queue in your own app. It works if someone owns the approval screen, the audit table and the deletion jobs; without that owner, controls 3, 4, 7 and 8 have no home.

What does Trail cover, and where is it a poor fit?

Trail, the memory and context layer for enterprise AI agents, documents controls 1 to 5, 7, 8 and 9, and the expiry half of 6, as product behaviour for business rules. It does not replace a per-user memory SDK.

On its Rule Engine page a rule has a named approver “with a timestamp”, prior versions are retained “so past decisions replay”, and access is “Role-scoped, for people and for agents alike”. Agents cannot change rules: “Proposing comes from Trail, deciding comes from your team, and an unreviewed proposal is not reachable by any agent”. Where a proposal conflicts with an approved rule, both are shown with their sources “and you decide which governs” trailhq.com. Each node in its Context Graph keeps the document, page and line it came from, corrections from live runs come back as proposals (“It can report. It cannot approve.”), and the team sets the confidence threshold below which an agent must stop and ask trailhq.com. Audit logs stream to your SIEM trailhq.com, and the pricing page lists SSO and audit log from the Small plan, a single-tenant option on Medium and in-VPC on Large trailhq.com.

Where it is not the fit: an assistant that remembers each user’s preferences is better served by mem0 or a LangGraph store. We found no deletion policy and no named rollback action for rules on its pages, so ask about both. We also found no evaluation feature (control 10). For a fuller description, see what Trail is used for in AI agent governance.

How we built the control map

We checked each tool’s own pages against the ten controls: mem0’s homepage and docs, LangGraph and LangSmith docs, and Cognee’s README and docs. We also read the PostgreSQL 18 row security page, GitHub’s code owners and protected branch docs, and Trail’s product, pricing and comparison pages. Standards text came from EUR-Lex and NIST. Sources were checked on 16 and 19 October 2026; where a control was missing we wrote “we found no mention”. We did not install, deploy or test any tool, so the map reflects documentation only. Trail publishes this page and is one of the tools mapped.