OpenClaw Enforces Memory Provenance in Automatic Context Injection

If you treat OpenClaw’s memory system as a privacy boundary — some memories for the main assistant, others restricted to specific commands or runtimes — a merged fix this week deserves your attention: automatic context assembly was not consistently respecting memory provenance, meaning content that should have stayed scoped could surface in automatically injected context (PR #127469, merged August 21).

What provenance does, and what was missing

Memory provenance is OpenClaw’s bookkeeping for where a memory came from and what may consume it — which runtime recorded it, whether it was captured from a user command, and which recall paths are allowed to inject it. The guarantee only matters if every consumer checks it. The gap: the automatic context path — the one that quietly assembles background context for turns without an explicit recall command — was not enforcing those rules uniformly. Provenance was respected on explicit recall but could be bypassed when memories entered context implicitly.

The fix closes that path with several deliberate design choices visible in the diff:

1. Enforcement at injection time — automatic context now filters through the same provenance rules as explicit recall.
2. Legacy repair before recall — older stores whose records predate strict provenance metadata get repaired into valid shapes rather than silently included or silently dropped.
3. Fail closed on unsupported runtimes — memory runtimes that cannot express provenance constraints are refused instead of being served with best-effort semantics; bootstrap behavior without a runtime is documented separately in concepts/memory-architecture.md.
4. Command exclusions are recorded — so that what a command chose not to expose remains auditable.

Why operators should care

This is a scope-integrity fix, not a performance tweak. Two failure modes existed before it:

• Over-exposure: memory entries with restricted provenance could reach model context through the automatic path, undermining operator assumptions about what the model sees. Anyone using memory scoping as a compartmentalization control (client work vs. personal, prod diagnostics vs. daily chat) was not getting the separation they configured.
• Under-detection: because nothing failed loudly, both over-inclusion and silent omission of memories would look like normal operation. You could neither rely on the boundary nor notice its absence.

After the fix, violations become explicit errors or repaired states you can inspect — consistent with where OpenClaw’s broader August hardening trend has been heading (secrets failing closed, status surfacing invalid configs, streaming refusing to fake success).

What to do

• Upgrade, then re-run any workflow that depends on memory scoping and verify restricted memories stay out of unrelated conversations.
• Expect first-boot repair activity on long-lived stores; legacy records will be normalized before they are eligible for recall again.
• Check your memory runtime version. If your deployment uses a runtime that predates provenance support, the gateway will now fail closed rather than approximate — plan that migration consciously rather than discovering it as a startup error.
• Treat provenance as part of your privacy review, not just retrieval tuning: what can be injected automatically is now exactly what provenance says may be.

Interpretation note: the description of the automatic-context gap follows the PR’s stated problem and commit sequence (“enforce provenance,” “repair legacy provenance before recall,” “fail closed for unsupported memory runtimes”); privacy-risk framing is our analysis.