Documentation

Two lines in. One command to check us.

Start with the verify step. If a record we produced doesn't survive a command run on your own machine, with no account and no network, nothing else on this site is worth reading.

Install

The SDK activates OpenTelemetry auto-instrumentation in-process, so tool calls, model calls and decisions are captured without touching your agent's logic.

python
pip install auditant

import auditant
auditant.init(api_key="ats_…", log_id="tenant_acme/prod")
Optional: your existing gateway

Spend analysis and budgets are computed natively, from the chain — Auditant never depends on another vendor for its own numbers. But if you already run a gateway, this adapter picks up every model call from every agent for free, including agents whose source you do not control. Enforcement runs in the request path; the evidence write does not.

config.yaml
# Point your gateway's callback at Auditant. Adapters ship for
# the common ones; the ingest API is open if yours isn't among them.
callbacks: auditant.gateway.handler
stamp the join key on the request
curl $GATEWAY/v1/chat/completions \
  -H "Authorization: Bearer sk-agent-loan-underwriter" \
  -H "traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01" \
  -H "x-auditant-agent: loan-underwriter" \
  -H "x-auditant-session: sess_b0f9c646" \
  -d '{"model":"claude-sonnet-4-5","messages":[…],"user":"cust-77"}'
Verify a bundle

This is the part to try first. It runs entirely offline — no account, no network, nothing from us. Point it at any bundle and it recomputes every hash from the raw events, checks every link, validates the checkpoint signatures, and reports what is proven.

shell
npx @auditant/cli verify ./evidence.json --offline
a clean record
Auditant — verification report
────────────────────────────────────────────────────────────────
Log       tenant_acme/prod
Period    2026-08-14T00:00:00Z  →  2026-08-14T23:59:59Z
Events    4183

✓ VERIFIED — chain intact, checkpoints signed and timestamped

  Chain verified: 4183 events, sequence 0–4182
  Anchored through sequence 4182, countersigned by a timestamp authority
a record someone edited
✗ TAMPERED — this record has been altered

  FAIL seq 4182: Content altered at 4182: stored bb1074a2c9e1…,
                 recomputed 0e41f7d3ba58…

What this means
  One or more events do not match their recorded hash. Either the
  stored records were modified after the fact, or the export is
  corrupt. Treat this log as unreliable until explained.
Exit codes
  • 0 — verified and anchored
  • 1 — tampered, or unreadable
  • 2 — usage error
  • 3 — chain intact, but nothing anchors it
What leaves your environment

Metadata + hashes (default)

Who acted, which tool, when, the outcome, the policy decision, and the SHA-256 of every input and output. Never the payload. Integrity is still fully provable — the hashes are what chain.

Customer-held payloads

Raw payloads land in your own bucket; we hold the chain and metadata. For teams that want drill-down without granting custody.

Full custody

Payloads with us, for teams that prefer the convenience. Available once the security posture justifies it — not the default, and never for health or cardholder data.

Payload deletion uses a tombstone: the content is destroyed, the hash remains, and the chain still verifies. A GDPR erasure does not break the record.

Threat model, stated plainly

Events are provably unaltered from the moment their checkpoint anchors. The exposure window equals the checkpoint interval — five minutes by default. That is the same trust structure as the audit logging your cloud provider already ships, twelve times tighter.

Verification proves records were not altered. It does not prove completeness: an action that never reached Auditant is not in the log, and no signature can say otherwise. Coverage is answered by your deployment configuration, and the report never conflates the two.