HDP token store

What this means

The same store as the content-reference row, with the recipient holding the other reference the implementation writes for every token: the version 4 UUID taken from the token's own header. Storing each token under both references is the reference implementation's default, not something the protocol requires. A UUID binds the token's id and nothing else, so it checks no content. Section 8.2 of the draft calls that a substitution point and steers implementers away from it wherever the resolving party does not control the store. The signature stops a forged token, or one whose signed content was changed, but not a different genuine one: extension keeps the token_id, and a chain cut at the tail still verifies, so an attacker with no key can put another snapshot of the same chain under the UUID and it resolves and verifies. That is the substitution 8.2 names, and none of the ten edits makes it; HDP's own suite tests it (PR #41). On the edits this board does make, the altered token fails hop 1's signature on verify, the forged token and the metadata edit fail the root signature, and the reordered, moved and rolled-back tokens fail because the UUID under which they were found does not match the header they carry. The result is the same six refused and three served as the content-reference row, with two of the six reached by a different check: the altered token and the metadata edit, which the digest refuses on that row and the signature refuses on this one. The tail and middle deletions are served for the same reason as on that row: the recipient asks only for the references the store still holds, and what remains resolves and verifies. The whole-store rollback needs stating rather than scoring, and the reason is in the draft's own rule for the reference: the store is write-once per reference, a UUID reference identifies one immutable snapshot and must not be used as a pointer to the latest chain, and a later extension lives only under its own content digest. A recipient resolving by UUID therefore sees that one snapshot by design, and a rollback of the whole store to an earlier set of snapshots cannot be told from normal operation. The cell reads served because that is what the read path did; the draft treats that as a property of the reference, and separately prefers the content reference because a reference by token_id is a substitution point. Level L0 for the same cumulative reason as the content-reference row.

The 10 verdicts

Detection point: the read path. 6 of the ten edits were refused there, 3 served as genuine, 1 not applicable.

Level L0. What L0 means.

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 and rewrites entries beneath the TokenStore API, as a backing database, a mounted volume or process memory would allow, so the write-once check in put is not in his way. He holds no signing key.

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
git clone https://github.com/Helixar-AI/HDP
cd HDP && git checkout b753ba9 && npm install && npm run build   # Node 22
export AGMI_HDP_REPO=<that checkout>
python agmi/full_runner.py --json results/scorecard.json   # every row, this one included
python -m agmi.agent --target hdp-token-uuid --families at-rest