Book demo Start free
Audit & Evidence

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.

Secure your first agent Try the public teaching lab
One bundle, checked offline Illustrative — selected component checks 
$ praesidia-verify finance-2026-q3.zip

[VALID      ] manifest            1 checked
[VALID      ] row signatures      412 checked
[VALID      ] chain integrity     411 checked
[VALID      ] root signatures     3 checked
[VALID      ] rekor receipts      3 checked
[VALID      ] platform attest.    1 checked

RESULT: OK
$ echo $?
0

Exit 0 means the applicable checks passed for the supplied evidence and trust configuration. Optional evidence can be absent; read each component status and caveat. A failure, incomplete evidence or unproven origin exits non-zero.

What you get

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.

How it works

From a governed call to a check your auditor runs

  1. 1

    Export persisted decisions and recorded activity from a supported capture path; a successful model response alone is not a Decision receipt.

  2. 2

    An owner or compliance officer exports a signed bundle for any range up to 90 days. The export is itself logged.

  3. 3

    You hand the bundle and the verifier to whoever needs to check it — your team, your auditor, a regulator.

  4. 4

    They run praesidia-verify on their own machine, offline.

  5. 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.

Audit log table: ten rows, each naming the action, the actor, the timestamp and a details payload. The top four are hourly audit root computations, then Protected Action Closed, Gateway Budget Reservation Committed and Billing Usage Logged; every visible row was recorded by the system itself.
The rows an export carries: the action, who took it, when, and the payload it went out with.
Technical details

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.
  • Platform attestations bind tenant signing keys to an organization, using a trusted platform key. Confirm the key fingerprint through an independent channel; never trust a key merely because the bundle includes it.
  • When supplied, decision disclosures are checked against signed commitments and policy references. This verifies the disclosed identifiers and outcomes, not the policy text or its correctness.
  • Target-signed receipts can be checked with independently obtained target key pins. A missing receipt or pin is not proof of an external action's completion.
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 — required evidence is missing, redacted or insufficient to decide · 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
Run the verifier on a sample bundle for source-build instructions, expected output and the limits of the public test keys and anchoring checks. The public Apache-2.0 verifier source requires Node.js 22.12 or later. Packaged distribution is available through your Praesidia contact or security@praesidia.ai; a public registry package and tagged release were not available when checked on 11 October 2026. How signing, chaining and anchoring fit together is explained in tamper-evident audit logs with cryptographic proofs.
Build from public source
git clone https://github.com/praesidia-ai/audit-verifier.git
cd audit-verifier
git checkout d7c830f89acaad7b9dc5feb6efc5d0a84b595e84
npm ci
npm run build
node dist/cli.js /path/to/bundle.zip --summary \
  --trust-anchor /path/to/independently-obtained-trust-anchor.json
Setup needs network access; verification runs locally. Obtain the trust-anchor file through a channel independent of the bundle and confirm its platform key fingerprint with the deployment operator. The verifier reads this local file without fetching it. Public source does not establish a production trust pin by itself; missing trusted platform keys produce an unanchored result. Read the per-proof statuses: a valid overall result does not mean every optional proof was present.
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.

FAQ

Common questions about verifying the audit trail

No. The offline verifier runs on your own machine and never calls Praesidia. It checks signatures, chain integrity and supplied inclusion and anchoring proofs using trusted keys. Confirm platform and target key fingerprints independently; the bundle cannot establish its own key provenance.

Anyone you hand the bundle to: your team, your auditor or a regulator. The verifier has public Apache-2.0 source that you can build locally; you can also request packaged distribution from us.

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

Put one agent under control and export its first bundle.

Create your workspace, record a week of decisions, then check them without us.

Start free Review the Trust Center