Audit Logs Are Not Metrics
Metrics answer operational questions.
Is the service healthy? Are requests failing? Is latency increasing?
Audit logs answer human questions.
Who accessed the credential? Who approved the request? What changed before the incident?
Those are different systems with different failure modes. Request metrics can be aggregated, sampled, and forgotten. Audit events have to survive review. Vault keeps those concerns separate: telemetry explains service health, while the audit trail explains sensitive actions such as secret reads, sharing, rotation, workspace deletion, session registration, and master-password reset.
Append-Only by Design
An audit log that can be edited is a diary, not evidence. Vault treats audit history as append-only. Sensitive events are never rewritten to make the story cleaner later. If context changes, that context should be appended as another event.
The same mindset appears in access history. A grant is not erased when it is revoked. A revoke closes the active period. This distinction matters during offboarding. If a contractor had access to a restricted secret for three weeks, the system should not pretend that access never existed just because the grant is no longer active.
Immutability is not a silver bullet. Database administrators and infrastructure operators still have power over systems. But append-only behavior raises the default quality of the application trail. The normal code path cannot silently fix, delete, or massage the record when the record becomes inconvenient.
Secret Read Events
The most important audit event in a secrets product is the read. Storage matters. Sharing matters. Rotation matters. But the moment someone decrypts a value, the secret has crossed from protected storage into human or client memory. That action deserves a record.
Vault logs decrypted reads as secret.read. A copied credential and a revealed credential are
operationally different events. Both expose the value. But one usually means the secret is leaving the system boundary.
That distinction matters later during incident review. The event still does not include plaintext. The point is to explain behavior without reproducing the sensitive value. That boundary is easy to violate when debugging, and it is one of the boundaries a secrets system has to defend most aggressively.
Correlation IDs Help Review
Correlation IDs are not security features. They are operational memory.
During incident review, they help connect sensitive actions to surrounding request context without relying entirely on human recollection. When someone asks why a restricted secret was copied at 02:13, the review should not depend on full-text archaeology or one person's memory of the request path.
Metadata Discipline Is the Design
The hardest part of audit logging is deciding what not to log. Engineers want details because details reduce uncertainty. Security systems need details that preserve uncertainty in the right place. A secret value should remain unknown to the log even if that makes debugging less convenient.
That is why metadata discipline is the design. The log should describe the action and its security meaning. It should not mirror request bodies wholesale, include key material, or capture content that may contain operational details outside the event being audited.
The Questions the Log Must Answer
Good audit systems are designed backwards from incident questions.
Who accessed the secret? Was the access approved? Did the credential rotate afterward? Did related account or session changes happen nearby?
The schema exists to preserve answers to those questions later, when memory is unreliable and pressure is high.
The conclusion is not that audit logs make secrets safe. They do not prevent a leak, and they do not undo a copied value. They make the aftermath less dependent on folklore. In sensitive systems, that is not bureaucracy. It is operational memory written down before the team needs it.