Tamper-evident audit
A record that can't be quietly rewritten.
A log you can edit is not evidence — it's a suggestion. Clavitor's audit trail is a cryptographic chain: every event is hashed into the one before it, the chain's position is witnessed on separate infrastructure, and a single pass re-walks the whole thing to prove nothing was changed, deleted, or reordered. Not "we promise we didn't touch it." Verify it yourself.
Every action is on the record.
A credential vault is only as trustworthy as the record of who used it. Clavitor logs every credential read, every autofill, every TOTP request, every login, every administrative change — and every denial. Each event carries who, what, when, from where, and how it ended.
Who, and what kind
Every event is attributed to a specific actor and tagged with actor type — human, browser extension, or AI agent. Agent activity stands apart from human activity on the same line, so a harvesting skill can't hide in the noise of normal use.
The full lifecycle
Create, read, update, delete — and every use. Autofill and proxy injection are logged the same as a manual read. Nothing touches a credential silently; there is no path to a secret that doesn't leave a row behind.
Outcomes, not just successes
Every event records how it ended — success, failure, or denied — with a reason code. A blocked agent, a rate-limited burst, a refused IP, a failed login: all logged. Auditors care more about what was stopped than what succeeded.
The chain
Hashed into history.
Each audit row is bound to the one before it by a hash. Change any earlier row — edit a field, delete an event, reorder two lines — and every hash after it stops matching. The tampering isn't hidden; it's structural, and it's loud.
# every row carries the hash of the row before it row_hash = SHA256( prev_hash | event_id | created_at | data ) # any edit, delete, or reorder breaks the recomputation # rows are append-only — never UPDATEd, never DELETEd
This is the same append-only principle the entire vault is built on — the audit log doesn't get a weaker version of it. Why nothing is ever overwritten →
Witnessed off-box
Rewriting it locally isn't enough.
A chain alone defends against edits inside the log. But the operator who holds the disk could, in theory, recompute the whole chain from a forged starting point. So the chain doesn't only live on the box that writes it.
The head of each vault's chain is anchored to separate infrastructure — a one-way witness that records where the chain was at each tick. To rewrite history convincingly, you'd have to defeat the log and the witness, in lockstep, without ever disagreeing.
A second system remembers the position
The POP that writes the log pushes its chain head — sequence and hash — to central as a best-effort witness. Central is never in the write path, so it can never slow the vault down; it only remembers what it was last told the chain looked like.
If the local log ever gets shorter than the witnessed position, that's a rewind. If a witnessed position comes back with a different hash, that's a fork. Either one is a truncation or a rewrite attempt — and either one trips an operator alert the moment it's seen.
Verify on demand
One pass. Intact, or broken.
You don't take our word for any of this. The vault re-walks the chain from the first row, recomputes every hash, and tells you the result — a verification badge that reads intact or, if a single byte moved, broken. There is no amber, no "probably fine." A security check that fails must fail loudly; this one does.
Encrypted, and still queryable
The record proves who acted — without exposing what they touched.
The audit log is encrypted at rest with the same field-level scheme as the credentials it tracks. Only the structural columns — event id, entry id, timestamp — stay in plaintext, because that's all a query needs. A stolen disk yields opaque tokens, not a map of your IPs, actors, and access patterns.
Pivots still work without giving that up. Each row carries keyed-hash bucket tokens, so "everything this IP did" or "every denied read" runs as an indexed lookup and decrypts only the matching rows — never the whole corpus, never a plaintext index a disk thief could read. You get the query. The attacker gets noise.
The report
Compliance evidence, on tap.
The audit log is a first-class page in the vault — not an export you reconstruct after the fact. Filter by actor, entry, IP, or date range. Click any cell to pivot. Sort by any column. Group by day, action, outcome, or actor. Facet chips show live counts as you narrow. Export the result to CSV for your SIEM or your auditor.
CMMC LEVEL 2
Audit and accountability evidence
NIST SP 800-171 controls 3.3.1 (record what's needed), 3.3.2 (link to identity), and 3.3.8 (protect log integrity) ask for per-event identity, IP, and timestamp, stored protected and tamper-resistant. Clavitor records all three, encrypts the log, and chains it.
SOC 2 · ISO 27001
Monitoring evidence, queryable
Trust Services criterion CC7.2 and ISO/IEC 27001 A.8.15 want logs of authentication and privileged actions. Every credential access is one such event — actor-typed, outcome-stamped, encrypted, filterable, and exportable.
HIPAA · GDPR
Accountability, by design
HIPAA §164.312(b) audit controls and GDPR Article 32 accountability obligations are answered by the same log. No separate compliance module, no add-on fee — the audit trail is part of the product. Enterprise plans add cross-vault export to your SIEM.
Policy becomes evidence.
Without a trustworthy record, every claim about access control is just policy — "we don't look," "agents are scoped," "nothing leaks." With a chained, witnessed, verifiable log, those claims become things you can check. That's the difference between asking you to trust us and letting you prove us.
See the other half of the record.
The audit trail proves who acted. Immutability proves the data they acted on was never quietly changed underneath them.