ClawMMU: Protection-Coherent Virtual Memory for Stateful LLM Agents: what it means for business leaders
A design that tags every piece of agent memory with its owner, scope, origins and authority, so an agent harness can refuse actions driven by injected text even when the model itself has been fooled.
1. What the method is
ClawMMU is a design for a protection layer inside an agent harness, the software that runs the model and manages its memory. It attaches a protection descriptor to every piece of memory. The descriptor records four things: the owner who produced the content, the scope of tasks and sessions that may use it, the origins it was built from, and an authority level. Authority is ordered from Evidence, which covers tool outputs and web pages that the model may read but never act on, up to Policy, which covers content the owner approved. The harness checks these descriptors at four points: when content enters the model's context, when it is written to storage, when it returns from storage, and when it drives a tool call. The central rule is that authority never raises itself. Only the owner can raise it. The checks look at where content came from, not what it says, so they hold even when the model is fooled.
2. Why the method was developed
Production agents such as Claude Code and Codex keep memory across sessions: instruction files, tool results and compacted conversation summaries. None of them records who may act on that memory, so an instruction hidden in a fetched page carries the same weight as the user's own. The authors' example is a forged invoice that says to use a new bank account for all future payments. The agent summarizes it into memory and pays the attacker weeks later. Current defenses ask a model to tell good text from bad, either through training or through injection detectors. They lower attack rates but guarantee nothing, because legitimate documents also contain instructions and adaptive attackers bypass most published defenses. Persistence makes it worse: a poisoned entry can pass through several summaries until it reads like the agent's own notes. Approval prompts before risky tool calls exist, but they cannot tell where the call's arguments came from.
3. Who should care
Any team running agents that have long-term memory and real permissions should take note, because this paper treats prompt injection as an access-control problem rather than a model-quality problem. Platform and security engineering would own the change. It lives in the harness and needs a hook at each of the four checkpoints, stable identities for memory pages, and a reviewed schema for every tool that marks which arguments must trace back to trusted content. Product owners of agents that pay, send, delete or commit should expect a cost: more owner approvals whenever untrusted content supplies a sensitive argument, and standing permissions that stop applying once untrusted content has entered the context. Risk and procurement teams assessing vendor agents get a concrete question to ask. Does the harness track the source of tool arguments and revoke memory derived from bad sources, or does it rely on the model resisting injection?
4. How the method works
Map assigns a descriptor based on the source as content enters the context, so a tool result arrives as Evidence. Each context is a compartment built for one owner and one scope. Two compartments can share a context only through a token the owner grants, and that token raises the authority of nothing. Derive applies an inheritance rule when the model writes to storage. Derived memory takes the lowest authority and the narrowest scope among its inputs, and it lists all of them as origins. The model counts as a lowest-authority input, so anything the model writes stays Evidence. Reload enforces revocation. Every page has a counter that increases when the owner revokes or corrects it, and each descriptor records its sources' counters. A stale counter sends the memory back through map. The counters live outside checkpoints, so restoring an old checkpoint cannot bring revoked memory back. Authorize traces each security-relevant tool argument, such as a payee, to content with enough authority, and it gives values with no traceable source the lowest authority.
5. How it was evaluated
Nothing has been evaluated. This is a short workshop vision paper, and the authors state that ClawMMU is not yet implemented. Their comparison table lists design properties, not measured ones. The paper offers two things in place of experiments. The first is a walkthrough of the forged-invoice attack through all four checkpoints. The second is a qualitative comparison with MemGPT, ClawVM, CaMeL, TMA-NM, MemLineage, MemTX and ACRFence on seven guarantees, scored from what each of those papers claims: cross-session protection, how derived memory inherits labels, revocation of derived memory, safety across checkpoint restore, per-argument authorization, scoped sharing of contexts, and enforcement by labels alone. As future work, the authors plan to run attacks from the AgentDojo, InjecAgent and sleeper memory poisoning benchmarks through a ClawVM-based harness. They will measure attack success, the latency of the checks, and how often the owner must approve an action. For us, the approval rate is the number that decides whether the design is usable.
6. How it performed
There are no measured results. The claimed guarantee is that untrusted content can neither gain the user's authority nor trigger an external action such as a payment. The authors are explicit about what it does not cover. It does not guarantee that the model makes the right call, that derived memory is accurate, or that readable content stays confidential. The model can still pass a wrong value that happens to carry enough authority. The main remaining risk is a tool schema that wrongly marks an argument as safe, which is why the schemas need human review, and reviewing them at scale is listed as an open problem. So are authority in multi-agent systems, actions taken before a revocation, and auditing approvals that widen scope. The likely cost is friction: an agent whose job is to act on retrieved data will ask for approval often. Our call is to watch, while adopting the argument-provenance rule now for any agent of ours that moves money. (Source: arXiv 2610.28093, 2026)
← Back to dossier index