HDP token store

What this means

The token-by-reference store of HDP (draft-helixar-hdp-agentic-delegation-03, Section 8.2) keeps one stored token per record, each holding the whole delegation chain to that point, and reads a token back by a reference. This row holds the content reference: a sha256 digest of the token, recomputed on every read and compared before the token is returned. That one check refuses any substitution under the reference the recipient holds. An altered token, a reordered one, a token moved in from another context, an older token written over a newer one and a token with its metadata changed all come back as a digest mismatch before the read path returns anything, and a forged token fails the root signature one step later. What the reference cannot see is absence. The recipient asks for the references the store still holds, so a token deleted beneath the store is never asked for, and what remains resolves and verifies: the tail and the middle of the store can be removed and the read path serves what is left as genuine. The whole-store rollback is the same gap at larger scale: an older copy resolves exactly as the current one did. Six of the nine applicable edits refused on the read path, three served; the level rule is cumulative and L1 needs the middle deletion refused, so the row sits at L0 while refusing more edits on read than most rows on this board. The row was measured after the draft's author asked for the reference implementation to be run through the method, with the results posted to the IETF RATS list before publication; section 8.2 of the draft names the content reference as the one a resolving party should hold wherever it does not control the store.

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-content-ref --families at-rest