Docs

Memory integrity

Your agent's memory is an input to every future run, so a quiet edit to it is a durable attack. Every sanctioned write to a brain file or your instructions file is signed, and the current content is verified against that signature. A file that changed with no matching signature is flagged as a memory-poisoning candidate rather than trusted because it looks fine.

Where to find it

  • Localhost: /memory-signing.html
  • API: GET /api/memory-integrity
  • CLI: repoops memory sign and repoops memory verify
  • Sidebar: Guard, then Memory Integrity

What it does for you

It fails closed, so unknown never reads as clean.A missing signature, a blank one, or an invalid one all read as suspect. Only a valid signature over the current content reads verified. This is the distinction the whole surface exists for: "we checked and it is fine" and "we could not check" must never render the same.
It uses the attestation trail you already have.Signing runs through the same signer and append-only transparency log RepoOps already keeps, so memory integrity is one more thing anchored in that trail rather than a parallel system with its own trust story.
Signing is a deliberate act, not a side effect.The sanctioned write path is the CLI. The tab is read-only over the signature ledger, so opening it can never quietly bless a change by observing it.

Built vs. planned

Signing, verification and the fail-closed states ship today, local-only with no network and no LLM. Worth being precise about the boundary: the signature detects a change made by something that does not hold the install key. A local key holder can still re-sign a file they edited themselves, so this is a poisoning-detection control rather than a guarantee against the operator. This is also distinct from the memory proof surface on the Brain tab, which covers brain-pack versioning, export and lineage; this one is the trust path over agent memory specifically.

Last updated