Memory Audit Protocol

Introduction: the problem

AI systems are accumulating persistent memory about the people who use them. That memory sits inside the platform running the model, and the platform decides how long it is kept, what it is used for, and what deletion means in practice.

1.1The defaults belong to the platform

Controls exist. Temporary chat modes, training opt-outs, and retention settings are all offered. They are switches the platform owns, sets, and can change, and a person using them has no way to confirm the state on the other side.

1.2Memory is consolidating

As assistants take on more of people's work, the record of what they know about a person grows and concentrates with a small number of providers. That concentration is happening now, while the defaults are still being set - which is the point at which earlier internet markets became difficult to reverse.

1.3Deletion cannot be verified

Once data has been read, copies may persist in caches, logs, derived models, and downstream systems. A deletion request is answered with an assertion. Nothing in the architecture produces evidence either way.

1.4The law grants rights the architecture cannot evidence

European law already gives people rights over data held about them. The GDPR provides a right to erasure.[1] The Data Act, applicable since 12 September 2025, provides rights of access to data generated by connected products and rights to switch between data processing services.[2] The Digital Markets Act obliges designated gatekeepers to provide effective portability of the data they hold.[3]

Why this matters now

The architecture is not yet fixed. Foundation models are being built at a scale measured in hundreds of billions, and for most participants that race is already settled. The memory layer is not. It is still being designed, and the defaults set now are the ones that will be hardest to revisit later.

The pattern is familiar. When social media and cloud computing emerged, a small number of platforms set the architecture before the rules arrived, and the years since have been spent trying to catch up. The rules that eventually came could describe the harm precisely and do comparatively little about the structure that produced it.

There is a second reason the timing matters. The argument is already being won on the enterprise side. Large firms are negotiating for trust boundaries around their own use of AI, for control over the traces and adapted weights their usage generates, and for the ability to move between providers without surrendering what they have accumulated. The exposure for an individual is the same in kind. The difference is that a person has neither the leverage to negotiate those terms nor a mechanism through which to exercise them.

The interests that converge here are not usually in the same room. A data protection regulator gains a way to check compliance rather than infer it. A competition authority gains lower switching costs. A smaller firm gains the ability to build on memory it did not have to accumulate first. A person gains the ability to see what was read about them, and when. The memory layer is where those conversations meet.

None of this requires the systems people already use to stop working. That property is worth protecting deliberately. An architecture that demanded the replacement of what exists would not be adopted, and would not deserve to be.

Proposed architecture

The Memory Audit Protocol separates the reasoning system from custody of the memory it uses. Under this design an AI system holds no persistent memory of its own. Memory stays with the institution that already holds the relevant records: a hospital for medical history, a bank for financial records, a university for academic records, or a service the person chooses for themselves.

When an AI system needs context, it requests scoped access for a stated purpose, receives only what it was authorized to receive, and returns to a stateless condition when the session ends.

The design does not put everything about a person in one place. A single store for everything would recreate the concentration the protocol exists to address. The realistic shape is many custodians, each already responsible for the data it holds, connected by a common way of asking. Email works this way, and it is the closer analogy.

Protocol mechanics

The protocol requires no new infrastructure and defines no new network. It is a set of obligations about how an AI system and a custodian deal with each other, expressed on top of the Model Context Protocol.[4]

4.1Access is scoped and bound to a purpose

A custodian divides memory into categories and issues access for a declared purpose, one session at a time. A request that reaches past what it was granted is refused rather than quietly satisfied, and widening it requires going back to the person. Categories differ by institution, because a hospital and a bank hold different things, but the obligations attached to them do not.

4.2Every access is written down

The custodian records what was released, to whom, under what authorization, and when, in an append-only log that cannot be altered without the alteration being evident. The record is held on the custodian's side, not the platform's, and is meant to be read by the person it concerns and by whoever regulates them. This is the part of the design that does not exist anywhere today.

4.3Everything else is ordinary internet infrastructure

Transport is HTTPS. Endpoints are found the way any other service is found. The protocol deliberately introduces no central directory: a custodian is reachable because whoever operates it publishes it under a domain they control, not because an intermediary agreed to list it. That property is the requirement. The mechanism that satisfies it is not novel and is not meant to be.

Remark: MCP vs. MAP It is worth saying plainly, because it is the first question technical readers ask. MAP is a governance profile on top of MCP rather than a competing stack. MCP defines how an AI system talks to an external service. MAP defines what has to be true about that exchange for it to count as governed: how access is scoped to a declared purpose, what the custodian is obliged to record, and what the person and the regulator can inspect afterwards.

What this does not solve

One limitation should be stated openly, because it bounds what the architecture can claim.

Once a custodian releases data to an AI system, the protocol cannot stop that system from keeping a copy. Encryption in transit does not help, because the receiving system has to be able to read what it was sent.

What the architecture provides instead is evidence. A record exists of what was released, to whom, under what authorization, and when. That makes improper retention detectable and attributable after the fact, which is what an enforcement action requires. It does not make the retention impossible. Closing that gap is a legal question rather than an engineering one, and the protocol's contribution is to make the obligation checkable.

Status and pilot

A pilot is being built during 2026 to test whether the architecture holds in practice and to measure what it costs to run. The pilot places a stateless inference agent on commercial cloud compute and a memory custodian on separate sovereign infrastructure, with memory divided into scoped categories and every access written to the ledger. Running the model on foreign compute is deliberate: if the separation holds under those conditions, it holds under easier ones.

The questions the pilot is meant to answer:

- how much latency and overhead authorization adds to a session;
- how finely access can be scoped before the design becomes unusable for the person granting it;
- whether an operator can run a custodian without specialist help.

The specification will be published openly, and the protocol layer is intended to stay royalty-free, following the pattern set by OAuth[5] and TLS.[6]