Introduction to the audit log
A vault is only as trustworthy as the record of who used it. If you can't tell what was accessed, by whom, and when — or worse, if that record can be quietly edited after the fact — then "we keep an audit log" means very little.
Clavitor treats the audit log as evidence, not as a convenience feature. Two ideas drive the design.
Everything that touches a secret leaves a row
There is no path to a credential that doesn't get recorded. A manual read, an autofill, a TOTP code, an agent fetch through the proxy, a login, an administrative change — all logged, the same way. Just as importantly, so is every denial: a blocked agent, a rate-limited burst, a refused connection, a failed login. For an auditor, what was stopped is often more interesting than what succeeded.
The record can't be quietly rewritten
Most logs ask you to trust that no one edited them. Clavitor's audit trail is a cryptographic chain: each event is bound to the one before it, so altering, deleting, or reordering any record breaks the chain — visibly, and detectably. And the check needs no secret key, so you (or an outside auditor) can run it independently. The chain's position is also witnessed on separate infrastructure, so even wiping the tail of a local log is caught.
What this section covers
- The exact shape of what's recorded — What gets logged
- Day-to-day use: reading, filtering, exporting — Reading the log
- Proving the record is intact — Verifying integrity
- The honest limits — retention, and what the log deliberately does not contain — Limits