Skip to content
KOR IT

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?

ExperimentalAgent SecurityAli Korsi · June 2026

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.