What gets logged
Every event answers five questions: who, what, when, where, and how it ended.
Who — the actor
Each event names the actor:
web— you, signing in to or locking the vault page.agent:<name>— a connected client, by the name you gave it: the browser extension, the CLI, the proxy, an AI agent. The vault page's own reads show asagent:Vault holder.system— the vault acting on its own account.
Every client has its own name, so one integration's activity never blends into another's. If a connected integration starts reading more than it should, it stands out on its own line. The event reference lists which actor appears on which event.
What — the action
The full lifecycle of a credential, plus the actions around it:
| Group | Actions |
|---|---|
| Read | get, list, history, list_deleted |
| Use | search, totp, export |
| Change | put (create, update, scope change, client changes, import), tombstone (delete), create_dossier (a new vault) |
| Session | login, logout |
| Client notes | app_event |
| Refused | the request's own name — entry.get, search.query, … — with outcome denied |
Reads and uses are logged the same as edits — there is no silent path to a secret. Every name, what causes it and who can: Event reference.
When — the timestamp
Every event is stamped with the time it occurred, to the millisecond.
Where — the source
The source IP the request came from, so access from an unexpected location is visible.
How it ended — the outcome
Every event records its outcome, not just the successes:
- success — the action completed.
- failure — it was allowed, but went wrong in a way that matters for security: data that didn't verify, a name already taken.
- denied — it was refused by policy, with a reason: out of scope, rate limited, client locked, IP refused, hardware-key tap missing, and so on.
Filtering for denied is often the fastest way to see whether anything is probing at your vault's edges.
What's tied to what
Change and history events link to the exact entry — and, for versioned changes, to the specific revision they produced. An update event points at the revision it created; a delete points at the tombstone. The audit log and your version history line up, event to revision.