Research
Memory Contract Specification
Experimental research, not a standard: can a runtime contract decide when a stored memory entry is permitted to influence an agent's reasoning?
Abstract
Memory Contract Specification (MCS) is early exploratory research at KOR IT into runtime security contracts for agent memory. It asks whether the decision to let a stored entry influence an agent can be expressed as an enforceable policy evaluated at recall time, rather than as an implicit property of the storage layer. The working principle is Trust Before Recall. The work is unproven, has no reference implementation we would put in front of a production system, and is not a standard.
Topics
- Memory Security
- Policy
- Provenance
- Runtime
- Agent Security
This research explores a narrow question. If persistent agent memory is a security boundary, can the crossing of that boundary be governed by an explicit, machine-evaluable contract — and if so, what would that contract need to express?
Trust before recall
Most existing thinking about memory hygiene concentrates on the write path: validate content before it is stored, filter what looks adversarial, keep the store clean. That instinct is sound but structurally limited. At write time the system does not yet know what the entry will later be used for, so it must make a trust decision without knowing the stakes. Content that is harmless when it informs a summary may be consequential when it informs a decision to call a privileged tool.
Trust Before Recall.
The working principle inverts the emphasis. An entry may be stored liberally, but it earns influence only at the moment it is about to be recalled, and only against the specific operation it is about to influence. The recall point knows both sides of the transaction: what the entry is, where it came from, how old it is, and what it is about to shape. That is where an enforcement decision has the most information available to it.
Candidate policy dimensions
A contract needs a vocabulary. These are the dimensions we are currently carrying as candidates. They are not final, several of them overlap, and at least one is likely to turn out to be an implementation detail rather than a policy concern.
- provenance
- The recorded origin of the entry, captured at write time and preserved through any later mutation.
- trustLevel
- The standing the entry is granted on recall, expressed as a level rather than a boolean so that partial trust is representable.
- scope
- The agents, workflows, and sessions permitted to recall the entry.
- tenant
- The isolation boundary the entry belongs to, enforced by the store rather than by the retrieval query.
- ttl
- The lifetime of the entry, after which recall is refused regardless of whether the entry has been deleted.
- writeAuthorisation
- Which principals or processes may create the entry in the first place.
- recallAuthorisation
- Which operations may be influenced by the entry — evaluated separately from write authorisation.
- mutationAuthorisation
- Whether and how the entry may be rewritten, merged, or summarised, and what happens to its provenance when it is.
- humanApproval
- Whether a recall into a defined class of high-risk operation requires an out-of-band human decision.
- drift
- The observed behavioural change attributable to the entry, fed back as an input to future recall decisions.
- telemetry
- What the runtime is obliged to emit on write, recall, mutation, and expiry for the contract to be auditable at all.
Open questions
The questions below are the ones currently blocking progress. We do not have satisfying answers to any of them.
- Where does the contract live? A policy attached to each entry is expressive but expensive at scale; a policy attached to the store is cheap but too coarse to distinguish a working note from a durable claim.
- How is provenance preserved through summarisation? Consolidation processes that merge many entries into one must combine their provenance somehow, and every combining rule we have considered either over-trusts or discards information.
- What is the failure mode? Refusing a recall degrades the agent's usefulness in ways that are hard to explain to a user, and a control that is routinely disabled provides no protection.
- Can trust levels be assigned without a human in the loop, given that the classifier assigning them is subject to the same manipulation as the agent?
- Is drift measurable in practice, or only observable after the fact in aggregate?
- How does a contract interact with model context that is assembled outside the memory subsystem entirely, such as retrieval over a document corpus?
Limitations
One limitation is that this work is unproven. There is no evaluation, no benchmark, and no evidence that a recall-time contract reduces real-world risk more than a well-implemented write-time filter. A second is that the approach presumes provenance is recoverable, which holds only if every writing path in the runtime cooperates; a single component that writes without recording origin undermines the whole model. A third is cost: evaluating policy on every recall sits directly in the latency path of agent reasoning, and we have not established that the overhead is acceptable.
A fourth limitation is conceptual. The model assumes that entries are discrete and individually attributable. Where memory is stored as embeddings and recalled as a blended set of nearest neighbours, the notion of an individual entry influencing an individual decision may not survive contact with the implementation.