> ## Documentation Index
> Fetch the complete documentation index at: https://docs.atlasent.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 4. Export the audit bundle

> Download a signed, offline-verifiable audit bundle.

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

```bash theme={null}
curl -X POST "$ATLASENT_API_URL/v1-export-audit-stream" \
  -H "Authorization: Bearer $ATLASENT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"projection":"v5"}' \
  > chain.ndjson
```

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](/trust/audit-signing-key) page, not a key returned by the same channel as the export:

```bash theme={null}
atlasent-audit-verify --chain chain.ndjson --keys atlasent-audit-key.pem --require-signatures
```

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

<Tip>
  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.
</Tip>

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

<CardGroup cols={3}>
  <Card title="TypeScript SDK" icon="js" href="/sdks/typescript" />

  <Card title="Python SDK" icon="python" href="/sdks/python" />

  <Card title="Go SDK" icon="golang" href="/sdks/go" />
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.