§1The recall problem is solved. The authorisation problem is not.
The framing in this paper deserves more attention than it will get, because it names the part of agent memory that vendors keep quietly skipping. Memory agents do not fail in institutional deployment because they forget the wrong things or recall too little. They fail because a single memory store is being read and written by multiple principals with different authorisation contexts, and almost no current architecture models that.
Put plainly: when one caseworker's agent writes a note about a vulnerable resident, and a second caseworker's agent later reads from the same memory, who decided the second caseworker was allowed to see it? In most shipped memory systems the answer is nobody. The memory is a flat key-value or vector store. Retrieval is governed by semantic relevance, not by access rights. The paper's contribution is to treat that as the central engineering problem rather than a deployment afterthought.
That is a substrate problem, and it is the one we keep flagging. The interesting work in agent infrastructure right now is not making models remember better. It is making memory enforce who is allowed to remember what, on whose behalf, for how long.
§2Access control and forgetting are the same problem wearing two hats
The paper's sharpest move is putting access control and forgetting in the same frame. Treat them separately and you build two leaky systems. Treat them together and the design constraint becomes obvious: a memory entry is not a fact, it is a fact plus a principal plus an authorisation context plus a retention condition. Drop any of those four and you cannot reason about whether retrieval is lawful.
Consider what "forgetting" actually means in a shared store. A right-to-erasure request under UK GDPR Article 17 does not ask the system to forget a fact globally. It asks it to forget a fact about a specific data subject, possibly while preserving derived aggregates, possibly while retaining it for a separate legal basis held by a different principal. A flat memory store cannot satisfy that, because it has no representation of which principal's authorisation kept the entry alive. You end up either over-deleting (breaking another principal's lawful record) or under-deleting (failing the erasure request). Both are reportable.
The paper frames utility, access control, and forgetting as a three-way balance that current agents cannot hold. The honest reading is that they cannot hold it because the data model underneath was never built to carry per-principal authorisation through the retrieval path. Retrieval optimises for relevance; authorisation is bolted on at the API boundary, if at all. By the time a relevant memory has surfaced, the leak has happened.
§3What this means for a regulated buyer running shared agents
If you are an FCA-regulated firm or a local authority planning to run agents over shared institutional memory, this paper is a warning about an architecture you may already be buying. The vendor demo shows a single user, a single agent, clean recall. The procurement question nobody asks: when two principals with different permissions share the store, what stops one agent surfacing memory the other principal had no right to write into a context the first principal can read?
Under the FCA's SS1/23 expectations on model risk management, you are accountable for the data a model acts on, not just the model. A memory agent that retrieves across principals without authorisation context is a model acting on data it should not have. Under ICO guidance on AI and data protection, purpose limitation and data minimisation apply to what the agent can recall, not only to what you originally collected. A shared store with no per-principal scoping fails both, quietly, the first time two teams use it.
The practical test we would put to any vendor: show me a retrieval where the same query, run by two principals, returns different memory because their authorisation contexts differ. If the system cannot do that, it has no access control. It has a search index with a login screen in front of it. Those are not the same thing, and an auditor will eventually find out which one you bought.
This is the producer-versus-guardian separation we keep returning to. The agent that writes memory and the layer that decides who may read it must not be the same component, because an agent optimising for its own utility will always find a relevance-maximising reason to surface a memory it should have left buried.
§4What the paper does not solve
The framing is right; the solution is not here yet. The summary names the problem and asserts that current agents cannot balance the three concerns, but a clean problem statement is not an architecture. We do not see a worked mechanism for carrying authorisation context through a vector retrieval path at production latency, and that is the hard part. Attaching a principal and a policy to every memory entry is easy on paper and expensive at scale: every retrieval becomes a policy evaluation, and policy evaluation over millions of entries is not free.
The paper also leaves the conflict cases open. When principal A's retention obligation and principal B's erasure right point at the same memory entry, something has to adjudicate. That adjudication is a governance decision, not an engineering one, and no memory architecture will make it for you. What the substrate can do is surface the conflict and refuse to silently resolve it in favour of utility. Whether anyone builds that refusal in is the open question. We will be watching for the follow-up that turns this framing into a retrieval path you could actually put in front of an FCA audit.