Verify your audit trail without trusting us.
Every governed call leaves a signed, hash-chained record. Export it as a bundle and check it on your own machine with an offline verifier that never calls Praesidia.
$ praesidia-verify finance-2026-q3.zip
[VALID ] manifest 1 checked
[VALID ] row signatures 412 checked
[VALID ] chain integrity 412 checked
[VALID ] root signatures 3 checked
[VALID ] rekor receipts 3 checked
[VALID ] platform attest. 1 checked
RESULT: OK exit 0Exit 0 means every signature, chain link and proof verified. A failure exits non-zero and says which component failed — never a silent pass.
Evidence that stands on its own
Signed at the source
Each record is signed and hash-chained under the default configuration, naming the actor, the action, the rule and the decision.
Checked offline
An Apache-2.0 command-line verifier with no runtime dependencies. It runs on an air-gapped machine and never calls our servers.
Anchored outside us
With external anchoring enabled, each hash root is receipted in the public Sigstore Rekor log — one we cannot rewrite.
From a governed call to a check your auditor runs
- 1
A governed call is evaluated and its decision is written to the append-only trail.
- 2
An owner or compliance officer exports a signed bundle for any range up to 90 days. The export is itself logged.
- 3
You hand the bundle and the verifier to whoever needs to check it — your team, your auditor, a regulator.
- 4
They run praesidia-verify on their own machine, offline.
- 5
The result is a status word and an exit code a script can act on: valid, invalid, incomplete, or a malformed bundle.
Several bundles from one organization can be checked as a set, so a missing quarter or a forged boundary between two exports is reported as a named finding rather than passed over.
What it proves, and what it does not
- What it checks
-
- Every record, hash root and the bundle manifest is signed by a key in the bundle's signed key set, and that key is not revoked.
- The records form one unbroken hash chain — no fork, no orphan, no missing link.
- Nothing was added, altered or removed since signing, including a trailing run of records deleted inside an anchored period.
- When anchoring is on, each root's Sigstore Rekor receipt is a genuine log entry bound to the exact hash in the bundle.
- When present, Praesidia's platform attestation vouches for which signing keys belong to which organization.
- What it does not check
-
- That every action was captured. A signing outage leaves an unsigned record and no marker in the chain.
- That the newest, not-yet-anchored tail of your history was not truncated. Record counts are bound only once a period's anchor exists.
- That anchoring was on at all. Read the anchoring line; an overall pass does not imply it.
- Signatures made under a key that was later revoked. They are rejected outright, not judged case by case.
- Anything outside the bundle it is given, including our uptime or a retention process affecting live records.
- Exit codes
- 0 valid · 1 invalid · 2 malformed bundle or I/O error · 3 incomplete — a piece of evidence was legitimately redacted, so the verdict is undecided rather than failed.
- Getting the verifier
- Customers with bundle export obtain it from their Praesidia contact or from security@praesidia.ai. How signing, chaining and anchoring fit together is explained in tamper-evident audit logs with cryptographic proofs.
Then: runtime enforcement · the evidence plane · the Trust Center.
Put one agent under control and export its first bundle.
Create your workspace, record a week of decisions, then check them without us.