Verify a receipt yourself.
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…
Pin the key
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.
Read the receipt
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
The published checkpoint
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.
Run the verifier
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 second arbiter: the endpoint
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.
Verify your own
Paste any Glacis receipt and the key you were given for it. Nothing leaves this tab — you can do this with the network unplugged.
Read the verdict honestly
What a green verdict proves — and what it does not
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.
A green verdict proves
- Faithful recording, under an enrolled identity. The evidence this receipt records — the hashes and counters in the signed payload — is bit-for-bit what the holder of the pinned key signed when the action was recorded. Change one byte of that evidence, or one character of the key you pin, and verification fails, as you saw above.
- Inclusion in an append-only log. The receipt is provably one leaf of the Merkle tree committed by the signed checkpoint, and the consistency proof shows the log only grew — no history rewritten — between the two checkpoints bundled here.
- Verifiable without trusting Glacis. No Glacis system took part in what you just did. The math answers to the key you pinned, not to us.
- One verifier, two arbiters. The same verifier checked receipts from two independent signers — the network proxy and the endpoint guard — each under its own pinned key. Verification does not care who produced the receipt; only whether the math holds.
It does not prove
- Completeness. Receipts prove faithful recording, not that every action was captured. An action that never produced a receipt leaves no trace in any log. Detecting gaps takes the surrounding controls — enrollment, epochs and heartbeats, oversight — not any single receipt.
- Correctness of the action. A receipt attests that a governed action was recorded under a policy decision. It does not certify that the AI’s output was right, safe, or compliant — it makes the record trustworthy so those questions can be examined honestly.
- Anything beyond the pinned key. Pin the wrong key and you verify against the wrong identity. Receiving the right key, once, out of band, is a procedural control — not a cryptographic one.
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.