Projects / 02
Memory Contract Specification
An experimental specification for runtime contracts that decide when a memory record is allowed to influence an agent. Principle: Trust Before Recall.
Overview
We investigate whether the security properties of agent memory can be expressed as an explicit contract that is evaluated at runtime, rather than as implicit behaviour of a retrieval pipeline. The organising principle is Trust Before Recall: a memory record must satisfy a policy at the moment it would influence a decision, not merely at the moment it was written.
Most memory systems check nothing at recall. A record is retrieved because it is semantically close to the current context, and semantic closeness carries no information about who wrote the record, whether they were authorised to, whether it is still valid, or whether it belongs to this tenant at all. The contract makes those questions explicit and answerable.
The specification is descriptive rather than prescriptive. It names the dimensions a memory policy has to decide on; it does not claim there is one correct value for any of them.
The problem
Agent memory inverts the usual direction of trust. Ordinary data stores are read by code that treats content as data. An agent reads memory as instruction-adjacent context, so content written into memory acquires influence over later behaviour, in later sessions, for possibly different users.
This creates a write-once, influence-many pattern with no natural expiry. A record written during a low-stakes interaction can shape a high-stakes one months later. Nothing in a similarity search distinguishes a fact the operator asserted from text an attacker persuaded the agent to store about itself.
The gap is not detection of bad content — that is hard and probably partial. The gap is that there is usually no place to put the decision at all. Retrieval pipelines have no policy evaluation point between the vector search and the prompt, so even a correct trust judgement has nowhere to be enforced.
Architecture
A contract attaches to a memory record and is evaluated at three moments: when the record is written, when it is recalled, and when it is mutated. Each evaluation is a policy decision with a recorded outcome, which means recall becomes an auditable event rather than an invisible one.
- Provenance
- Where the record came from — which identity, which session, which source system, and whether the content originated from a person, a tool response or the agent's own output.
- Trust level
- A graded assertion about how much influence the record may have, distinct from whether it is retrievable at all.
- Scope
- The set of tasks, agents or contexts in which the record is eligible to be recalled.
- Tenant
- The isolation boundary the record belongs to, evaluated on recall so that semantic similarity cannot cross it.
- TTL
- An explicit validity period, so that stale assertions expire instead of accumulating influence indefinitely.
- Write authorisation
- Which identities may create a record of this kind, and under what conditions.
- Recall authorisation
- Which agents and contexts may have this record placed into their working context — the core of Trust Before Recall.
- Mutation authorisation
- Which identities may amend or supersede an existing record, and whether the prior version is retained.
- Human approval
- Conditions under which a write or a recall is suspended and routed to a person rather than resolved automatically.
- Drift
- Detection of records whose content or influence diverges over time from what the contract assumed when they were written.
- Telemetry
- The record of contract evaluations — what was recalled, for whom, under which decision — retained for audit and investigation.
The dimensions are deliberately orthogonal. Provenance answers where a record came from; trust level answers how much it should be allowed to matter. Conflating those two is the most common modelling mistake we encounter, and it is why records from a trusted system are often granted influence they were never intended to carry.
Security model
The specification assumes memory content is attacker-influenceable. Any record whose content derives, directly or indirectly, from model output, tool responses or user input is treated as untrusted data regardless of which component wrote it.
- Trusted
- The contract metadata, the policy that evaluates it and the evaluation log — all of which must be stored and enforced outside the agent's ability to modify.
- Untrusted
- Memory record content, embeddings derived from it, and any summary of it produced by a model.
- Assumed but unverified
- That the identity presented at write time is authentic. The contract depends on the surrounding identity system; it does not establish identity itself.
The property the contract aims for is containment rather than purity. It does not attempt to determine whether a record is true. It attempts to ensure that an untrustworthy record cannot silently acquire influence outside the scope, tenant and validity period it was written under.
Current status
The specification is experimental. The policy dimensions are stable enough to be useful as an analysis vocabulary, and we use them to reason about memory designs. The enforcement semantics — precisely what a recall denial means for an agent mid-task — are not settled.
There is no reference implementation offered for use, no conformance suite and no external adoption. Nothing about this work should be cited as a standard.
Limitations
One limitation is that recall-time evaluation costs latency on the hot path of every agent turn. The more expressive the policy, the worse this becomes, and we have not established what a workable budget looks like.
A second is drift. We can define drift as a dimension, but detecting it in practice requires a stable notion of what a record is supposed to mean, and embeddings do not provide one.
A third is that the contract governs whole records. Influence in practice can arrive through a fragment of a record, a summary of several records, or a derived embedding, and fragment-level provenance is not addressed.
A fourth is that denying a recall changes agent behaviour in ways that may themselves be exploitable. An attacker who can cause denials can shape what the agent does not know, and we have not analysed that channel.
Roadmap
- Fix the evaluation semantics for the write, recall and mutation points, including the behaviour of a denied recall.
- Define a minimal metadata schema and the separation requirements between metadata and content storage.
- Build a lab harness that replays recall traces against candidate policies to compare outcomes.
- Study fragment-level and summary-level provenance as an extension rather than a core dimension.
- Measure recall-time policy evaluation latency against realistic retrieval volumes.
- Publish the dimension set for external critique and revise it in response.
Detail
Topics
- agent memory
- memory contracts
- provenance
- trust levels
- recall authorisation
- specification