AI Agent Memory: The Data Governance Gap Nobody Is Talking About

You have thought about what goes into your AI. Have you thought about what it is writing down?

Most AI Security work concentrates on two surfaces: the prompts and documents that enter a model, and the responses that come back. A third surface has arrived in production, and few data governance policies mention it. Agents built on the Model Context Protocol can now hold persistent memory, recording entities, relationships and observations to a store that survives between sessions and shapes later behaviour. That store is a data asset. In most organisations it has no classification, no named owner and no retention rule, which means it sits outside every control your data governance policy was written to apply.

Inputs, outputs and the store in between

Persistent agent memory is a writeable knowledge graph that an AI agent maintains about your people, systems and cases. The reference Memory server published in the Model Context Protocol examples implements precisely this pattern: entities, relations and observations that accumulate across sessions so an agent can resume work with continuity. The MCP Server Stack review published on Towards Dev in January 2026 lists it among ten open-source MCP servers in active use this year, which places it in the category of components your engineering teams may already be running.

The governance consequence is straightforward. The agent decides what to write. Nobody reviews the schema, nobody classifies the contents and the store grows quietly with every workflow it supports. A memory store serving a case-handling agent in a local authority or a triage assistant in an NHS trust could, within weeks, come to contain a structured record of named individuals, their circumstances and the judgements the agent formed about them.

Five questions your current policy cannot answer

Work through these against any agentic deployment already live in your organisation.

• Where is the memory stored? On a container filesystem, in a managed database or in a developer’s local environment that never appeared on an asset register.
• What classification applies? Memory inherits the sensitivity of everything written to it, so a store fed by casework data carries casework classification even if it was provisioned as a technical component.
• Who can query it? Access to the memory server is usually access to the entire store, with no per-record restriction and no distinction between the team that created the data and the team reading it.
• What retention applies? Persistent memory persists by design. Absent an explicit rule, it retains indefinitely, which conflicts directly with the retention schedules you have already published.
• Does it appear in your DPIA or AI register? If the memory store was treated as infrastructure rather than as processing, the answer is almost certainly no.

Unanswered questions on a live system are the definition of a control gap.

Why memory behaves differently from an audit log

An audit log records what happened. A memory store records what the agent concluded, and those conclusions influence future decisions. That distinction produces three risks that log-oriented controls do not address.

Accuracy becomes a live obligation. An incorrect assertion in the store does not sit inertly in an archive. It shapes how the agent handles the next interaction with that person. UK GDPR gives data subjects rectification rights over inaccurate personal data, and regulatory guidance treats recorded opinions and inferences as personal data in scope for that right, so you need a route to correct a stored observation and evidence that the correction propagated.

Aggregation raises sensitivity over time. Individual observations may look innocuous when written. Accumulated across months of sessions, they combine into a profile that would, on most readings of DPIA triggers, warrant assessment had anyone proposed building it deliberately.

Access quietly widens. Memory stores are frequently shared across agents to improve continuity, which turns a single-team data asset into a cross-organisational one without a corresponding access model or approval.

What to do before the next agent goes live

These steps require no new tooling.

1. Ask your engineering and data teams which agentic workflows are running and whether any of them persist state between sessions. Treat an unclear answer as a yes.
2. Add persistent memory stores to your asset register as a named class, with an owner drawn from the business function whose data they hold.
3. Classify each store at the level of the most sensitive item written to it, then apply the corresponding controls rather than the controls appropriate to a cache.
4. Set a retention rule and prove deletion works, including deletion of a single entity rather than the whole store.
5. Restrict query access and log it, so you can answer who read what.
6. Record the store in your DPIA and AI register, describing what it holds and why retention is necessary.

Organisations that complete these steps before deployment absorb the work into normal change control. Those that complete them afterwards do so under audit pressure, usually with a live service they cannot pause.

What clients ask us about agent memory

Do we need a separate policy for agent memory?

No. Extending existing documents works better than writing new ones. Name persistent memory as an asset class in your classification policy, add it to your retention schedule and reference it in your AI register template. Three amendments to approved policies carry more weight with auditors than a standalone document nobody has ratified.

Who should own agent memory in practice?

Ownership belongs to the business function whose data the store holds, matching how you assign ownership for any other repository. The platform or engineering team remains accountable for the technical controls, encryption, access logging and deletion capability. Splitting ownership from control operation prevents memory being treated as a purely technical concern.

How do we handle a subject access request that touches agent memory?

Assume it is in scope and confirm you can act on it. That requires the ability to query the store for all entities and observations relating to one individual, export them in an intelligible form and explain any inference the agent recorded. Test this capability before your first live deployment, not on receipt of the first request.

When should this reach the board?

Raise it at the next review of your AI register or ahead of any procurement involving agentic tooling, whichever comes first. Framing matters. This is an extension of existing data governance to a new storage location, which is a far easier conversation than presenting it as a novel category of AI risk.

Where this fits in a wider assessment

Agent memory is one concrete instance of a broader pattern, namely AI systems creating and retaining data outside the scope of your governance framework. Our AI Security Gap Analysis examines data governance as a core domain and surfaces exactly this kind of undeclared persistence alongside Shadow AI use, unmanaged integrations and absent assurance evidence. If you are deploying agentic workflows this year, book a discovery call and we will walk through what your current controls cover and what they do not.

This article is general guidance rather than legal advice. Consult qualified counsel on your specific DPIA, retention and AI register obligations.