Audit logs

Every meaningful action in VaultTerm lands in an append-only audit log. The log is not just write-once; it is tamper-evident, backed by a checkpoint chain that lets you detect after the fact whether any record was altered, removed, or reordered. This is the accountability half of being an audited access broker: the server decrypts secrets in memory for authorized actions, and each of those actions leaves a record that cannot be quietly rewritten.

The log

The audit log captures who did what, when, and against which resource — reads, brokered sessions, configuration changes, and security events. Entries are written once and never updated in place.

Search and filtering are scoped to the caller’s organization by row-level security. An operator querying audit data only ever sees rows whose org_id matches the authenticated tenant context; the isolation is enforced at the database, not in application code. See Tenant isolation for how the scoping works.

The checkpoint chain

On top of the raw log sits a license-rooted checkpoint chain. Periodically, a checkpoint is written that:

• Seals a contiguous range of audit rows with a hash over that range.
• Hash-links to the prior checkpoint, so the checkpoints form a chain — altering an old record changes its range hash, which breaks every checkpoint after it.
• Is stamped with the license counter, a monotonic anti-rollback value, rooting the chain in the deployment’s license rather than in a value an attacker could freely reset.

Because each checkpoint depends on the one before it and on the license counter, you cannot rewrite history without rewriting the entire downstream chain — and you cannot fabricate a fresh chain that matches the license root.

Verifying offline

The chain is designed to be checked independently of the running server. The repository ships a verification script:

# from server/
npx tsx scripts/verify-audit-chain.ts

The script walks the checkpoints, recomputes each range hash and link, and confirms the license counter sequence. If verification fails, the server raises an AUDIT_CHAIN_BROKEN event — a critical anomaly indicating the checkpoint chain integrity has been broken. The admin console surfaces the current chain status in its System view; see admin console.

The cryptographic construction behind the checkpoints (envelope encryption, hashing, and the license-rooted design) is described in Cryptography.

Retention by plan

How long audit records are kept depends on the plan:

Plan	Retention
Free	7 days
Pro	30 days
Team	365 days
Enterprise	Unlimited

Self-hosted deployments derive their tier from the signed license rather than a billing catalog; see Billing and plans.

Related pages

• Cryptography — the tamper-evident construction in detail.
• admin console — where audit-chain status is reported.
• Tenant isolation — how audit search is scoped per organization.