Verify your audit trail yourself

Last updated: July 2026.

The verifier

@praesidia/audit-verifier is a standalone, Apache-2.0 licensed command-line tool. It has zero runtime dependencies — it vendors its own cryptographic primitives — and it never calls Praesidia's servers. An auditor can run it entirely offline, on an air-gapped machine, with only the exported bundle and the tool itself.

praesidia-verify your-bundle.zip

The command exits 0 when every signature, chain link, and proof verifies; a non-zero exit code means verification failed or the bundle is malformed — never a silent pass. Every customer with compliance-bundle export access can request the verifier CLI from their Praesidia contact, or by emailing security@praesidia.ai.

What it checks

• Signatures. Every record, hash root, and the bundle's own manifest are validly signed by a key present in the bundle's signed key set — and that key was not revoked at verification time.
• Chain integrity. The records form a single, internally consistent hash chain, with no fork, no orphan, and no broken link — up to one accepted opaque anchor for a ranged export (a ranged export's chain is not proven back to genesis).
• Tamper detection. No record or hash root has been added, removed from the middle, or altered since it was signed — including a deleted trailing run of records inside a period that was already anchored, not just a truncated file.
• External anchoring. When enabled and not explicitly skipped, confirms each root's Sigstore Rekor transparency-log receipt is a genuine, cryptographically valid entry bound to the exact hash in the bundle — a public log Praesidia does not control and cannot quietly rewrite.
• Platform attestation. When present, confirms Praesidia's own platform — not just your organization's key — vouched for which signing keys belong to which organization.

What it does not check

We would rather a security reviewer find these limits stated up front than discover them later.

• That every action was captured in the first place. A signing outage produces an invisible gap — an unsigned record leaves no trace in the chain, the roots, or the bundle, with no marker that anything is missing.
• That a not-yet-anchored or boundary period wasn't truncated. The verifier only binds a period's record count once that period's anchor exists and falls fully inside the bundle's date range; the newest, not-yet-anchored tail of your history has no independent size commitment yet.
• That external anchoring exists at all, unless you check that result specifically. A bundle can still report an overall pass with anchoring absent or explicitly skipped — read the anchoring result, don't infer it from the summary line.
• That a revoked key's signatures made before revocation are trustworthy. The verifier rejects every signature under a revoked key outright, including genuinely pre-revocation ones, rather than judging case by case.
• That every privileged action reached the audit trail. The verifier only sees what's inside the bundle it's given.
• Anything about Praesidia's live uptime, or whether a data-retention process is about to affect signed records. This is a static, offline check of one exported artifact.

How you get a bundle to verify

Organization owners and users with the compliance-officer role can export a signed bundle for any date range up to 90 days directly from the platform's forensics view — no support ticket required. The export itself is logged to the audit trail. See tamper-evident audit logs with cryptographic proofs for how the signing, chaining, and anchoring work underneath.

Questions

Talk to your Praesidia contact, or email security@praesidia.ai. For the rest of our controls, see Security & Compliance.