PrivacyAutomated.ai
Public verifier · no account required

Verify a PrivacyAutomated seal

Paste the JSON contents of an evidence packet below. We’ll re-check the Ed25519 signature against the transparency key published at /api/audit/transparency-key — without your account, an API key, or contacting us.

What is this for? When a regulator, auditor, or opposing counsel receives a sealed packet from a PrivacyAutomated customer, this page is where they confirm the packet is authentic and unaltered since sealing.

Three ways to convince yourself, in order of setup cost

1Read the verdict
Zero setup

The verifier above re-canonicalizes the packet you pasted (sorted keys, compact separators), prepends the domain prefix PA-EVIDENCE-PACKET-V1\n, and Ed25519-verifies the embedded signature against the public key at /api/audit/transparency-key. If the result above says authentic, the packet’s bytes haven’t changed since the customer sealed it.

2Check our side offline
One terminal, no network round-trip

Download the public Ed25519 verification key once, then verify any packet bytes locally — without ever talking to our servers afterwards:

# Once: fetch the public key
curl -o pa-transparency.pem \
  /api/audit/transparency-key

# Per packet: canonicalize, prepend domain, verify
python3 -c "import json, sys; \
  d = json.load(open('packet.json')); \
  sig = bytes.fromhex(d.pop('signature_hex')); \
  body = b'PA-EVIDENCE-PACKET-V1\n' + \
    json.dumps(d, sort_keys=True, separators=(',',':')).encode(); \
  open('/tmp/sig', 'wb').write(sig); \
  open('/tmp/body', 'wb').write(body)"
openssl pkeyutl -verify -pubin -inkey pa-transparency.pem \
  -rawin -in /tmp/body -sigfile /tmp/sig

Signature Verified Successfully = same answer as the verdict above, no trust in our server required after the initial key fetch.

3Verify against Bitcoin without trusting us
Requires a Bitcoin node (yours or a public RPC)

The packet’s seal references the daily audit-event Merkle root, which is itself anchored to Bitcoin via OpenTimestamps. The full verification chain — packet → audit chain → daily Merkle root → Bitcoin block height → block in YOUR Bitcoin — is documented step-by-step at privacyautomated.ai/trust-architecture.html (Invariant 3). Most regulators don’t need to go this deep, but the option exists, and it’s the answer to “but how do I know you didn’t just sign a fake timestamp?”

What the seal proves

  • The packet bytes are unaltered since sealing.
  • The sealing happened on the embedded date.
  • The named human signed off.
  • Any AI inference that touched the record was running the named system prompt at the named SHA-256 hash.
  • The audit-event chain is intact from the start of the record to the seal.

What the seal does not prove

  • Legal correctness. The seal proves the DSAR closed in 21 days; it does not prove 21 days satisfied the regulatory obligation. That’s a separate claim involving deadline math + legal judgment.
  • Truth of the inputs. The seal proves nothing was altered after sealing. It does not prove the privacy team did the underlying work correctly. Garbage in, signed garbage out.
  • What a court would conclude about the underlying records. That’s for your counsel.

The full engineering substrate behind these claims is documented at privacyautomated.ai/trust-architecture.html.