Skip to main content
AtlaSent’s audit export is a tamper-evident, offline-verifiable evidence artifact. Evaluation records are hash-linked in chain order; the exported bundle carries the applicable signature and manifest material needed for independent verification. A successful bundle verification establishes the integrity properties the verifier actually checks — it does not, by itself, prove downstream execution, effect, global completeness, or regulatory compliance.

​
Export via API

The quickstart key’s audit:read scope is sufficient. The export is newline-delimited JSON — one chain-ordered audit entry per line, carrying the hash-link and signature fields the offline verifier checks. See Verify the audit chain for the full field list and for large exports.

​
Verify the bundle offline

Use the public atlasent-audit-verify CLI (install and usage). Verify against the public key you pinned from the Audit signing key page, not a key returned by the same channel as the export:
--require-signatures makes an unloaded or wrong key a failure rather than a silent skip. Verification is performed without trusting a live AtlaSent decision at verification time. A successful verification should be read narrowly:
  • the checked chain/hash relationships are intact;
  • the checked signature/trust-root relationship is valid;
  • the checked manifest/digest relationships are consistent;
  • no unsupported verification claim is implied beyond those checks.
It does not mean:
  • an allow was executed;
  • a Permit was necessarily verified at an execution boundary;
  • the provider/native effect occurred;
  • the bundle contains every record that should exist globally;
  • a regulated system is validated or compliant merely because the evidence verifies.
Give the bundle and the applicable public verifier instructions to a reviewer or auditor so they can reproduce the integrity checks independently. For regulated use, keep your validation protocol, procedural controls, record-retention obligations, and trust-root procedures in the review scope as well.

​
How this supports common control requirements

A tamper-evident, attributable, independently verifiable evidence chain can support controls mapped to requirements such as record protection, secure audit trails, and data-integrity expectations. The exact compliance conclusion remains environment-, procedure-, retention-, configuration-, and validation-dependent. See the relevant compliance mapping pages for the specific AtlaSent control mapping and the customer responsibilities that remain outside the product.

​
You’re done with this quickstart stage

At this point you should be able to distinguish four separate facts:
  1. ✅ an authorization Decision was recorded;
  2. ✅ a bounded Permit was issued when required by the exercised path;
  3. ✅ Permit Verification succeeded when the quickstart exercised that boundary;
  4. ✅ the resulting audit bundle can be checked for the integrity properties supported by the verifier.
None of those facts should be used to infer a native execution or effect unless the applicable provider/observer evidence establishes it separately. Next: pick an SDK and wire this into a real protected execution topology.

TypeScript SDK

Python SDK

Go SDK