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
  • Navigation: AI Security in the sidebar, then Memory Integrity under All tools, in the Agent findings group

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