Memory Access Control

What it is

Deciding which principals may read and which may write which memories. Every stored item was formed within a scope — a person, a workspace, a thread, an agent — and this capability is the machinery that keeps reads and writes inside it. What makes it its own problem is where the enforcement point sits: inside a similarity query rather than at an API boundary, over content that will be paraphrased by a model rather than returned verbatim. Identity, roles, and organisation-wide authorization are decided elsewhere and consumed here; what is specific to memory is the scoping of items and the enforcement of it during retrieval.

Why it matters

A memory store is usually the densest concentration of cross-subject content an AI product holds, and the natural way to search it ranks by similarity, which knows nothing about ownership. If scope is not a hard constraint on the query, the system's isolation depends on a ranking function, and ranking functions do not fail closed. The exposure is also one-way: once content has been retrieved into a prompt, nothing downstream can un-tell the model, and the leak may surface as a paraphrase that no output filter is looking for.

Key decisions

• Whether scope is applied as a pre-filter in the query or a post-filter on results. Post-filtering leaks through the candidate limit: the correct items are displaced by items the principal may not see, and the symptom is a thin answer rather than an error.
• Who the principal is when an agent acts on a person's behalf, and whether the agent's own authority is permitted to exceed that person's at any point in the chain.
• Whether writes are scoped as tightly as reads. A memory learned in a private thread and written at account scope is a disclosure created at write time that no read-side control will catch.
• How sharing is expressed: copying an item into the recipient's scope, or granting a reference to the original — which determines what revocation can actually achieve afterwards.
• Whether a denied retrieval is distinguishable by the agent from an empty one, given that the distinction is itself information about what exists.
• How administrative and support access to someone's memories works, what it is recorded as, and whether the subject is told.

Failure modes

• Filtering happens after ranking, so the candidate set is spent on items that are then removed, and the user receives a worse answer with no indication why.
• The agent runs under a service identity that can read everything, and the only thing keeping it inside a scope is an instruction in its prompt.
• A memory written during an impersonated support session is attributed to the support agent's scope, so the subject can never see or correct what was recorded about them.
• Access to a workspace is revoked and memories derived from that workspace remain in the departing person's individual scope.
• The vector index and the metadata store have separate access paths, and the embedding neighbourhood discloses the existence and approximate content of records the filter removed.
• Scope is enforced on interactive retrieval but not on the consolidation job, which reads across scopes and writes a derived item that mixes them.
• A shared item is implemented as a copy, the original is later corrected, and the copy continues to assert the old value to a different audience.
• Retrieval is scoped correctly and the prompt logs are not, so the content is isolated in the store and pooled in observability.

Related capabilities

• Memory Retrieval — the query where this is enforced or lost
• Shared Agent Memory — write authority across multiple agents
• Long-term Memory — the partition key this ultimately depends on
• Memory Provenance — the origin scope a derived item must continue to satisfy
• Memory Deletion — what revocation cannot achieve once content has been copied

Applies: Production readiness · Design questions