A production run of 1,000 governed write decisions. Each one produced a real cryptographic receipt, issued via TBN Protocol and enforced by Shango MID's write-governance layer — verifiable by anyone, server-side and offline, without trusting our servers.
tbn_vr_ receipts · random sample 40/40 valid: truetbn2_ receipts — now attests the authorisation context, not just the decision: independently signed, fail-closed ON, and reconciled with TBN. See below ↓Most "AI governance" can show you what an agent did. The harder question — the one auditors and the new agentic-AI governance frameworks ask first — is whether it was authorised, under which rules, and whether you can prove the authorisation itself, not just the action.
Every governed decision now seals — into the independently signed receipt — the full
authorisation context as it stood the moment the write bound: the constraints that evaluated and
their results, the policy state in force, the authorisation chain (who authorised, under which scope, bounded by a
human), and how any conflict resolved. It's committed via input_hash = SHA-256(canonical(envelope)),
so a reviewer can reconstruct "what was allowed, under whose authority, against which rules" — and check it without
trusting us. The published envelopes carry a real authoriser and a non-empty policy snapshot (not placeholders).
Independently attested. Each receipt was signed by TBN Protocol (the
independent authority). Every one verifies two ways: the RSA-PSS signature is valid against TBN's
published key, and the published authorisation envelope hashes to the attested input_hash
with matching controls[]. The authorisation chain
(authorized_by = team@shango.in, real permission_scope,
bounded_by_authorising_human = true) and the policy snapshot
(policy_snapshot_hash ≠ SHA-256("{}")) are populated for every receipt — not placeholder text.
Merkle root (v2 run, 2026-06-25):
580ad28ab3643faf5de73ba98e36df138d28138a41091bf9ac85eafc95dd5bfb
Construction (RFC 6962-style with domain separation): leaf =
SHA-256(0x00 ‖ canonical signed body) (every field except signature,
sorted-keys / no-whitespace); internal node = SHA-256(0x01 ‖ left ‖ right); duplicate-last on odd
levels; hex of the final node. Receipts use schema tbn-receipt/2.0, key id
tbnkey_d9d2b0c3ab2e8aa3, verifiable offline against TBN's published key. Reproduce with
python proofs/mint_v2_direct.py --n 500 --out <dir> --fail-closed or verify the published
artefacts at production_runs/20260625_185419_v2/.
Trust boundary, plainly: TBN attests what Shango
asserts — the receipt is an independent authority's signature over the decision and its sealed context, not
proof that an external write actually happened or was blocked. Enforcement holds for writes routed through the
connector; writes outside it are not attested. fail-closed was ON for this run: an ALLOW with no
TBN receipt is downgraded to BLOCK. RFC 3161 trusted timestamps are an opt-in flag
(TBN_RFC3161=1) and were not enabled for this run — timestamps are TBN-self-asserted.
These are real v2 receipts from the latest run. We don't ask you to trust us — we ask you to check.
Live endpoint gap, honestly: TBN's public /api/v1/verify currently accepts only v1 IDs (tbn_vr_…) and returns HTTP 400 "Invalid receipt_id format" for v2 IDs (tbn2_…). v2 verification is therefore offline-only against TBN's published RSA-PSS key (see "How verification works" below). v1 receipts remain live-verifiable; sample links at the bottom of this section.
Offline (v2 — the run featured on this page): 12 sample receipt IDs from the 2026-06-25 run. Run the reference verifier:
python proofs/verify_v2.py production_runs/20260625_185419_v2/receipts_v2.jsonl --key zenodo_deposit/tbn_public_key.pem
Live (v1 — earlier run, still server-side verifiable):
production_runs/20260625_185419_v2/receipt_ids.txt; v1 list at zenodo_deposit/receipt_ids.txt.Server-side — any receipt ID checks against TBN Protocol's public endpoint:
GET https://tbn.hardinai.co.uk/api/v1/verify/tbn_vr_0011754392069005d53bef2e9c50963a
→ { "valid": true, "receipt": { ... } }
Swap the ID for any receipt above — each returns its own signed record. ({receipt_id} is just a placeholder for a real ID.)
Offline (v2 receipts) — verify the RSA-PSS signature yourself, without contacting anyone:
signature, JSON with sort_keys=true and no whitespace (separators=(",",":")).GET /api/signing/public-key. Derive key_id = "tbnkey_" + SHA-256(pem)[:16] and confirm it matches the receipt's key_id.RSA-PSS / SHA-256 / MGF1 / salt = max over the canonical bytes. Signature is hex-encoded.SHA-256(canonical(authorisation_envelope)) and confirm it equals the receipt's input_hash; confirm controls[] matches the envelope's constraints.leaf = SHA-256(0x00 ‖ canonical signed body); node = SHA-256(0x01 ‖ left ‖ right); duplicate-last on odd levels.Reference prover at proofs/mint_v2_direct.py; verifier at proofs/verify_v2.py and proofs/verify_auth_context.py. Published artefacts at production_runs/20260625_185419_v2/.
Each receipt is independently verifiable via TBN — server-side or offline, as above. What a receipt proves: an independent authority's signature over the governed decision and its sealed context, checkable by you against the published key without trusting us. It attests the decision Shango made and the context it was made in; enforcement holds for writes routed through the connector. ShangoVault is a separate append-only, hash-chained ledger; the hash-chained portion is linkage-verified, and full content-recompute is in progress (so we say linkage, not content-tamper-proof).
We label every number. This is the whole audit trail, not a curated slice.
| Record set | Nature | Count |
|---|---|---|
| v2 authorisation-context receipts (2026-06-25 run, synthetic inputs, real signer) | independently signed (TBN) · fail-closed ON · auth + policy populated | 500 |
| v1 decision receipts (2026-06-04 run, synthetic inputs, real signer) | independently signed (TBN) | 1,000 |
| ShangoVault audit entries (snapshot 2026-06-04) | append-only · hash-chained subset, linkage-verified | 225,574 |
| — of which carry hash-chain fields | linkage-verified; content-recompute in progress | 10,234 |
| — cryptographically attested (TBN test API) | test-API attested | 182,040 |
| — labelled local simulation | simulation | 43,534 |
On latency, honestly: the governance decision is sub-millisecond, and the RSA-PSS signature itself is ~1 ms. The end-to-end time you measure is a round-trip to TBN's independent signer — and that hop is the point: a second party signs the receipt, not us, which is what makes it verifiable rather than self-asserted. Where high frequency matters, signing runs local/async. We optimise for proof you can check, not a number you take on faith.
A 15-minute demo on your own systems — then you verify the receipts yourself. No slides.