Store, measured at rest
inspeximus
receipts on, attacker holds the store directory
inspeximus was seeded through its own API and edited behind its back nine ways. 0 edits served as genuine, 8 reported on audit, 0 rejected on read, 1 not measured.
- Measured on
- inspeximus 3.0.0, Darwin arm64, Python 3.12
- Date
- Source
- github.com/DanceNitra/inspeximus
- Attack versions
- tamper@v1, truncate@v1, delete_middle@v1, reorder@v1, forge@v1, cross_replay@v1, rollback_replay@v1, metadata_tamper@v1, snapshot_rollback@v1
What this means
The agent acts on an edited memory first; the operator finds out only if the audit is run. 8 of the nine edits are reported by that audit. Run the audit on a schedule, or move the check onto the read path.
The 9 verdicts
Detection point: the audit, a separate call the operator has to make; the read path serves the edit first.
Level L0, Measured. The store has a published row. Any verdicts. What L0 means.
| Edit | Verdict | What the tool said |
|---|---|---|
| T1 Content tamper | reported | detected on reload (verify_writes: ['memory 57959039fa: its TEXT or KEY no longer matches its write receipt (edited after write)']) |
| T2 Tail truncation | reported | detected on reload (verify_writes: ['write log shrank below the head kept outside the store: 3 < 5 (rolled back or truncated, receipts included); a deliberate restore is accep) |
| T3 Middle deletion | reported | detected on reload (verify_writes: ['receipt 2: broken chain link (a prior receipt was altered/removed)', 'write log shrank below the head kept outside the store: 4 < 5 (rolle) |
| T4 Reordering | reported | detected on reload (verify_writes: ['memory 0f13eb2405: its TEXT or KEY; its VALUE (`object`); WHEN the fact became true (`valid_from`), or where that time came from no longer) |
| T5 Forged insertion | reported | detected on reload (verify_writes: ["1 record(s) are covered by NO write receipt, so nothing here vouches for them: ['f0fecf4efe']. They were inserted out of band, or written ) |
| T6 Cross-context replay | error | edit did not land: seeding the second context changed the first context's records |
| T7 Rollback replay | reported | detected on reload (verify_writes: ['memory 10677daee2: its TEXT or KEY; its VALUE (`object`); WHEN the fact became true (`valid_from`), or where that time came from no longer) |
| T8 Metadata tamper | reported | detected on reload (verify_writes: ['memory 073965583d: a field its receipt commits to no longer matches its write receipt (edited after write)']) |
| T9 Snapshot rollback | reported | the store noticed it was older than its last committed state (verify_writes: ['write log shrank below the head kept outside the store: 5 < 6 (rolled back or truncated, receipts included); a deliberate restore is accep) |
A verdict is what the tool did, not an opinion. "Accepted" means it loaded the altered store, raised nothing, and the agent carried on from the altered memory as if it were true. Every cell has a control that proves the edit landed before the verdict counts.
Where the attacker stands
The attacker holds the store (a file, a table, a bucket, or the data-plane role of a managed service) and edits it outside the tool's API, then the tool is reopened the way its users would reopen it.
Reproduce this row
Everything runs offline unless the store is a managed cloud service, in which case the row needs a project of your own. The run seeds a fresh store, applies each edit, confirms it landed, reopens the store and records what came back.
pip install agent-memory-integrity
python agmi/full_runner.py --json results/scorecard.json # every row, this one included
python -m agmi.agent --target inspeximus-rcpt+dir --families at-rest # this row through the storage-side hunt
python -m agmi.agent --target inspeximus-rcpt+dir --compose # composite moves against this rowBadge
Maintainers can link their row from their README. The badge points here and changes nothing on your side:
[](https://agentmemoryintegrity.org/stores/inspeximus-rcpt-dir.html)