Don’t trust the claim. Verify the pack.

This is a real Proofpane Evidence Pack — exported by the production code path and signed with Ed25519. Download it with the standalone verifier, disconnect from the internet if you like, and check it on your own machine: manifest signature, every file hash, and the full audit hash chain, re-computed locally. No Proofpane account. No API. No trusting us.

Download sample pack (.zip, 12 KB) Download verifier (verify_evidence_pack.py) Download signing key (signing-key.pem)

sha256(pack) = 88a097acb6ba453a8bc48ed1dd7189949d566034c0afd3e56cf02b8e1191da4c
sha256(signing-key.pem) = 92a517b7893084bb183299b40a4ba62a41af5655f6e1af43d047d60950d2d30b

Sandboxed, or egress allowlisted to developer domains only? If you can reach GitHub but not this domain, the identical pack + verifier (with instructions and the same sha256) are mirrored at github.com/Proofpane/releases → evidence/:
curl -LO https://raw.githubusercontent.com/Proofpane/releases/main/evidence/proofpane-sample-evidence-pack.zip
curl -LO https://raw.githubusercontent.com/Proofpane/releases/main/evidence/verify_evidence_pack.py

Verify it (two commands)

pip install cryptography        # the only dependency (Ed25519)
python3 verify_evidence_pack.py proofpane-sample-evidence-pack.zip --pubkey signing-key.pem --verbose

The --pubkey flag pins the publisher key you downloaded separately from the pack. Without it the verifier still checks the pack is internally consistent — but reads the signing key from inside the pack, which proves integrity, not provenance. See why that distinction matters below. Run it without the flag and the tool says so, and tells you how to upgrade.

What you should see — this is the verifier’s actual output for this exact file

Manifest version: evidence-pack/1.4
Exported at:      2026-07-09T21:38:57.121730Z
Records claimed:  16
Key fingerprint:  67ff4fa702e8eb1a

✓ Signature valid (Ed25519, key fingerprint 67ff4fa702e8eb1a)
✓ Signing key matches the pinned publisher key (provenance verified)
✓ All 12 file hashes match manifest
✓ Audit chain re-verified: 16 records, all hashes match
✓ Chain anchors line up with slice boundaries

Slice details:
  first id=1 at 2026-07-09T21:38:57.013539Z
  last  id=16 at 2026-07-09T21:38:57.102009Z
  audit.integrity.checked: 1
  budget.blocked: 1
  cp.dlp.redact: 1
  cp.egress.deny: 1
  cp.hitl.resolve: 2
  mcp.client.connected: 1
  mcp.tool_call: 3
  mcp.tools.discovered: 1
  risk_threshold.detected: 1
  skill.execute: 3
  validation.error: 1

PASS — bundle integrity confirmed.

Then try to break it

  1. Unzip the pack and open audit/records.json.
  2. Change any byte — a timestamp digit, one character of a payload.
  3. Re-zip and run the verifier again.

It fails. That is the entire product in one experiment: a record that cannot be quietly rewritten — not by an employee, not by an attacker with database access, not by us.

Integrity vs provenance — and the harder forgery

The tamper test above changes an existing pack, so its signature breaks. But a determined forger doesn’t edit the pack — they rebuild it: generate a fresh Ed25519 keypair, write whatever audit records they like, re-mine the whole hash chain so it’s internally consistent, re-sign the manifest with their own key, and drop that key into signatures/public_key.pem. If the verifier trusts the key inside the pack, that forgery passes.

This is a real limit, and we won’t paper over it. A self-contained pack proves integrity (nothing was altered after signing) but not provenance (who signed it). The fix is out-of-band: we publish the signing key separately from the pack — on this page, and mirrored on GitHub — and the verifier’s --pubkey flag pins it. A forged pack’s embedded key won’t match, so it’s rejected before any signature is even checked. Try it: rebuild the pack with your own key, then run with --pubkey signing-key.pem — it fails with “embedded key does NOT match the pinned publisher key.”

Where this sits against the prior art — stated plainly. Pinning a published key raises the forgery bar from “any key” to “the publisher’s key,” but it does not yet give you a timestamp you can trust against a backdated whole-chain rebuild by the publisher. The rigorous answer to that is an external anchor — committing the chain head to a system neither party controls: an RFC 3161 timestamp authority, a Certificate-Transparency-style log (RFC 6962), or a public transparency log such as Sigstore Rekor. Systems like AWS CloudTrail log-file validation and Google’s Trillian are mature at exactly this. Proofpane today hash-chains and self-signs chain-head anchors on a schedule; binding those anchors to an independent transparency log is on the roadmap, not shipped. Our reference architecture is explicit that independent evidence requires a rail the audited party cannot control — this is us holding our own spec to that line, in public, while the external anchor lands.

What’s inside

Sixteen audit records telling one afternoon of governed AI work: a coding agent (Cursor, via the MCP daemon) reads source files, then gets denied on .env by the policy gate; a human approves a review-gated retry and DLP redacts the AWS key before any model sees it; governance skills run with cost and tokens metered; a high-risk output triggers a risk-tier human review; an over-budget model call is refused — and the refusal itself is on the chain; an egress-gateway block stops a credit-card number leaving via an n8n workflow; and the daily integrity cron re-verifies the chain. Plus: the manifest, per-file hashes, chain anchors, Ed25519 notary anchors, skill snapshots, and the control-mapping coverage (NIST AI RMF · ISO/IEC 42001 · EU AI Act · GDPR · SOC 2) for the skills in the slice.

Honest labeling. The events in this pack are a seeded demo narrative (the same dataset class as the public demo org) — no real customer data. Everything else is production-real: the export code path, the hash chain, the manifest, the Ed25519 signature (a sample key; each deployment signs with its own), and the verifier — byte-for-byte the tool an auditor would run on a real engagement.

Trust Center · What is Proofpane? · Live demo (no signup)

Pack generated and verified 2026-07-09 · manifest evidence-pack/1.4 · verifier requires only Python 3 + the cryptography package · signing key published out-of-band for --pubkey provenance pinning