This page contains signed receipts from two arbiters — one from the network proxy of a synthetic demo tenant, one from Glacis Pulse on an endpoint — the public keys that signed them, and the same verifier Glacis ships, compiled to WebAssembly. Verification runs entirely in your browser. No account, no server, no call to Glacis: disconnect from the internet and every check below still runs.
Loading verifier…
Every verification starts from one thing you control: the public key you choose to trust. Below is the signing key of this demo’s transparency log. In a real deployment you receive this key once, out of band, and pin it — after that, nobody (including Glacis) can forge a receipt that verifies against it.
fingerprint — SHA-256 of the key bytes, first 16 hex characters
This log and its key are synthetic, created for this page. Production keys are provisioned inside the customer’s environment and never published like this. The receipt below also carries an embedded copy of the key, but verification trusts only the key you pin here — never that embedded copy — which is exactly why a forged embedded key cannot pass off a receipt as something it is not.
One governed action, one receipt. This one belongs to
nimbus, a synthetic demo tenant, and was entered into the
demo log as leaf index 5 of an 8-leaf Merkle tree. Look for something to
leak: every field is a hash, a counter, a key, or a label. Receipts carry
no prompts, no model outputs, no personal data — that is the
design, not a redaction.
Raw files: receipt.nimbus.json · checkpoint.nimbus.json
A signature alone proves who wrote the receipt. The checkpoint proves membership: it is the log’s signed statement — root hash, tree size — of everything recorded up to a moment in time. The verifier requires the receipt to prove its place in exactly this tree, and to prove the log only grew (history not rewritten) since the previous checkpoint.
In a deployment you would receive checkpoints from the log on a cadence and compare them over time. Here one is bundled with the page, so verification makes zero network calls.
One click. The WebAssembly build of glacis-verify checks the
signature, the Merkle inclusion proof, the checkpoint signature, and the
append-only consistency proof — locally, in this tab.
“Corrupt one byte” flips a single hexadecimal character of the recorded evidence hash — the smallest possible lie a record can tell. Watch which guarantees fail, and how loudly.
The receipt above came from the network arbiter — the proxy in front of model traffic. This one came from the endpoint: Glacis Pulse, the guard that watches AI tools on a developer’s machine — the traffic no proxy can see. Different signer, different key, same receipt shape, same verifier. That is the point: one verifier, both arbiters.
The claim rides outside the signed receipt, as a sibling; the receipt
commits to it by hash (attestation_hash = SHA-256(JCS(claim))).
The verifier checks the hash inside the signed payload; this page
recomputes the binding for display — labeled, and not part of the
wasm verdict.
Raw files: receipt.pulse.json · claim.pulse.json · corpus.pulse.json · pulse-public-key.txt
Everything in this section is synthetic too — a demo endpoint key, demo actions. The receipt format, the tree, and the verifier are the real ones.
Paste any Glacis receipt and the key you were given for it. Nothing leaves this tab — you can do this with the network unplugged.
This panel is the point of the page. Cryptography proves narrow things precisely. Treat any vendor — including us — who claims more than the math supports with suspicion.
Everything on this page is synthetic: the nimbus demo tenant with a demo-only log key, and the Pulse endpoint receipt with a demo-only endpoint key. Production receipts from either arbiter verify the same way, against production keys.