Verify a real signed receipt.

Every ZLAR decision — allow, deny, or human-authorized — produces a signed receipt. The receipt below is a real v1 envelope generated by the reference implementation against a simulated write to /etc/sudoers. The gate denied it under rule R032. The record is signed and verifiable with only the public key and bin/zlar-verify. No call to a ZLAR server is required.

A v1 envelope.

receipt.json is the full artifact. The payload field is a canonical JSON object base64-encoded; the sig field is an Ed25519 signature over that payload. The audit event's operational detail (the path, the attempted content) is hashed into detail_hash and does not appear in the envelope — the dual-layer receipt architecture preserves chain verifiability without exposing content.

{
  "v": 1,
  "id": "000069eb686d4ea342fe654a6b42d212ef750197a2d8",
  "kid": "bd8cbe32df788172",
  "iat": 1777035373,
  "type": "governed-action",
  "payload": "eyJhdWRpdF9ldmVudF9pZCI6ImRlbW8tcmVjZWlwdC12ZXJpZnktMDAxIiwiYXVkaXRfcHJldl9oYXNoIjoiZ2VuZXNpcyIsImF1dGhvcml6ZXIiOiJwb2xpY3kiLCJkZWxlZ2F0aW9uX2NoYWluIjpbXSwiZGV0YWlsX2hhc2giOiI0Y2Q0NjU3NDQwMzUwNjcwMjhiY2UyMWFmYjY5OTVhZWY4N2M1MTEwNTUyOTI2NmZhNWEyMjJiYjNkNDdhYmIyIiwiZG9tYWluIjoid3JpdGUiLCJtYW5pZmVzdF9hZ2VudF9pZCI6bnVsbCwibWFuaWZlc3RfcHJpbmNpcGFsIjpudWxsLCJvdXRjb21lIjoiZGVueSIsInBvbGljeV92ZXJzaW9uIjoiMS4wLjAiLCJydWxlIjoiUjAzMiIsInRvb2wiOiJXcml0ZSIsInRzIjoiMjAyNi0wNC0yNFQxMjo1NjoxMy4wMDBaIn0",
  "sig": "w7Oqctyi1mHnogRJyR6bXZNwWwBBppsHHAKDcAy5lw3ZF6ZIQeHvLgJHalX0Z6R935fgG_tQCeDH2BFjfZ-eBQ",
  "prev": null
}

Raw file: demo/receipt.json

Ed25519, PEM, 113 bytes.

The key that signed the receipt. Verification requires nothing else. No ZLAR infrastructure, no network call, no account.

-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAKMpK9MhgPiyZExlIOf6fL98C5baux+xWD4+DEL7IR8U=
-----END PUBLIC KEY-----

Raw file: demo/receipt-signing.pub

One clone, one command.

Expected output:

VALID

Verified. Action "Write" in domain "write" was deny by policy at 2026-04-24T12:56:13.000Z.

--- Receipt Details ---
  ID:         000069eb686d4ea342fe654a6b42d212ef750197a2d8
  Version:    v1 (v1)
  Tool:       Write
  Domain:     write
  Outcome:    deny
  Rule:       R032
  Authorizer: policy
  Timestamp:  2026-04-24T12:56:13.000Z
  Policy:     1.0.0
  Audit ID:   demo-receipt-verify-001
  Signed by:  bd8cbe32df788172 (Ed25519)

Five structural facts.

• A specific action (write to /etc/sudoers) was attempted through an interception surface that reports to the gate.
• Deterministic policy evaluated the attempt. Rule R032 matched. No AI was involved in the decision — the gate pattern-matches signed rules.
• The authorizer was policy, not a human. A human-authorized receipt would name the approver's signing key.
• The record is cryptographically sealed. Any modification to the payload invalidates the signature.
• The receipt is anchored to the audit chain via audit_prev_hash (here "genesis" — the first entry). A production chain links each receipt to the previous receipt's hash; reordering or dropping a receipt breaks the chain and is detectable.

The receipt does not prove the policy was correct, or that the agent had good intentions. It proves the governance event happened: a decision was made by the stated authority, against signed rules, at the stated time, and the record has not been tampered with since.

Demo keys, throwaway, reproducible.

The project's operational signing keys are scheduled to rotate from software-rooted to hardware-rooted (YubiKey) in a planned maintenance window. During the overlap, verifiers will accept both keys, and the changeover will be announced with the new fingerprint. This page is not affected by that rotation — it uses demo keys, not operational keys.

Reproduce this receipt yourself: bash scripts/quickstart.sh generates fresh keys, runs the real gate against four tool calls, and verifies a v1 receipt. Nothing is simulated.