Verify your AI agent audit trail without trusting us.
Praesidia records the decisions it makes in an append-only, hash-chained audit trail, signed under the default configuration; an operator can turn signing off. Export the trail 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 names the actor, the action, the rule and the decision; the trail is hash-chained and signed under the default configuration.
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. External anchoring is optional; without it, removal of the most recent records cannot be detected.
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, unanchored, 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.
- Nothing was added, altered or removed since signing, including removal of the most recent records in a period that is already anchored.
- 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
-
- A signed record shows it was not changed afterwards. It does not show that every action was captured. Calls that do not pass through Praesidia are not recorded.
- That the newest records are all there. External anchoring is optional; without it, removal of the most recent records cannot be detected. Even with anchoring on, records written since the most recent anchor are not yet covered.
- 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 retention removing older 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 · 4 discontinuous (when verifying a set of bundles) — the bundles do not chain into one another · 5 unanchored — no trusted platform key was available, so the bundle's origin is unproven. This is never a pass.
- 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.
- Try a public example
- The synthetic signed-audit lab demonstrates changed records, broken chains, and the need for a trusted checkpoint when detecting a missing tail. It is an independent teaching format and does not verify Praesidia exports.
Then: runtime enforcement · the evidence plane · the Trust Center.
Common questions about verifying the audit trail
No. The offline verifier runs on your own machine and never calls Praesidia. It checks the signatures and the hash chain in the bundle you give it, and the anchoring receipts when anchoring is on.
Anyone you hand the bundle to: your team, your auditor or a regulator. The verifier is Apache-2.0 and we give it to you directly.
A signed record shows it was not changed afterwards. It does not show that every action was captured. Calls that do not pass through Praesidia are not recorded.
No. External anchoring is optional; without it, removal of the most recent records cannot be detected. Read the anchoring line of the output rather than the overall result.
Yes. Every outcome has its own exit code, and an incomplete result, or one with no trusted platform key (unanchored), is never reported as a pass.
Go deeper
- The AI agent audit trail guide — what a trail should hold and how to judge one.
- Tamper-evident audit logs — hash chains, signatures and anchoring, explained.
- How to audit AI agent activity — a working method for reviewers.
- EU AI Act controls for AI agents — record-keeping and logging, mapped to Praesidia's controls.
- AI agent audit trail, defined in the glossary.
Put one agent under control and export its first bundle.
Create your workspace, record a week of decisions, then check them without us.