harnessbench-semantic-clean-room
guard/destructive-execution · pass · T2 · rekor 2493890211
the record
| subject | harnessbench-semantic-clean-room |
|---|---|
| subject digest | 725234580e4ced4d639e3df1685725170d0d93b6edcf9b48d4e2ce1c1e5e17c3 |
| check id | guard/destructive-execution |
| result | pass |
| score | not scored |
| grade | B |
| enforced binding | enforced |
| ran at | 2026-08-16T00:00:00Z |
| tier | T2 |
| rekor log index | 2493890211 · integrated 2026-08-16 |
verify it yourself
The seal is portable on purpose. Nothing here asks you to trust this page: fetch the bytes below and run the check on your own machine.
checkseal verify-keyless harness-config.sigstore.json \
--subject harnessbench-semantic-clean-room.config-manifest.jsonthe files
- the T2 Sigstore bundle harness-config.sigstore.json
- the T1 DSSE seal harness-config.intoto.jsonl
- the verify key (PEM) harness-config.verify-key.pem
- the sealed subject harnessbench-semantic-clean-room.config-manifest.json
verify it here
A dark window through the paper: your browser fetches the seal, the key, and the sealed subject, then checks the signature itself. The second card is the same seal with one byte of config_ref flipped inside the signed payload, so it must refuse.
the real seal · verify it here
Your browser recomputes the subject digest, checks subject coupling, and verifies the Ed25519 signature over the DSSE payload.
Verifying in your browser…
the forged seal · one byte of config_ref flipped
Same subject, same coupling. But config_ref lives inside the signed payload, so the signature no longer verifies. This is the refusal.
Verifying in your browser…
The browser checks the honest subset: subject digest, coupling, signature. Full re-execution and enforced_proof resolution are the CLI's job. Walk the whole chain on /verification.