Event reference

The Action column of the audit log holds one of the names on this page, spelled exactly as here. They come from three places:

Storage events — the vault's storage engine seals one for every read that hands data out and every change it makes.
Vault events — the vault adds its own for things storage alone can't see: a search, an export, a TOTP code, a sign-in.
Refusals — a request the vault turned down is recorded under the name of the request itself, with outcome denied.

Who appears as the actor

Actor	Meaning
`agent:<name>`	A connected client, by the name you gave it: the CLI, the browser extension, the proxy, an AI agent. The vault page is a client too — its reads, searches and exports show as `agent:Vault holder`.
`agent:<name>#<id>`	The client that wrote an `app_event`: name and client id, so two clients with the same name stay apart.
`agent:<id>`	A client without a name, or a refused token whose client the vault doesn't know.
`web`	Sign-in and lock (`login`, `logout`) from the vault page.
`system`	The vault acting on its own account. Changes (`put`, `tombstone`, `create_dossier`) are currently recorded with this actor rather than the client's; their source IP still shows where the request came from. Also the client lookup that opens every request, and every failure row.

Reads

These are sealed before the data leaves the vault. If the event can't be written, the data isn't returned.

Action	Means	Caused by	Who
`get`	One entry's current content was returned. Entry is its name.	Opening an entry; a client fetching a credential; the fetch behind a vault-computed TOTP code; one per entry in an export.	web · extension · agent
`list`	Every entry of one type was enumerated. Entry is the type name (`credential`, `note`, `agent`…), Reason the count.	Loading the entry list (one row per type); a search (one row per type searched); URL matching and the extension's picker; scopes and import checks; the clients page. Every request also starts with one `list` of type `agent`, actor `system`: the vault looking up the calling client.	web · extension · agent
`history`	An entry's full revision history was returned. Reason is the revision count.	Opening an entry's history; one per entry in a full export.	web
`list_deleted`	The ids of deleted entries were returned. Reason is the count.	A full export.	web

Changes

Action	Means	Caused by	Who
`put`	An entry was created (version 1) or revised (each new version). The event carries the version it produced.	Creating, editing or upserting an entry; changing its scopes; each entry an import creates or updates; a new scope; creating, renaming or changing a client (clients are entries too); the vault's default category.	web · extension · agent
`tombstone`	An entry was deleted. Its history stays; the event carries the deleting version.	Deleting an entry; removing a client. Both need a hardware-key tap.	web
`create_dossier`	The vault's root record was created.	Setting up a new vault — once.	the vault itself

Vault events

Action	Means	Caused by	Who
`search`	A search ran. Entry is the query text, Reason the number of hits and whether it was an exact match.	A search from the CLI, the proxy or the extension. Written only when the answer goes out; the extension's picker list (an empty query) writes its `list` rows instead.	extension · agent
`export`	The vault was exported. Entry is the mode (`migration` or `full`) and the entry count.	Exporting from the vault page, which needs a fresh hardware-key tap.	web
`totp`	The vault computed a live TOTP code. Entry is the entry's name.	A client asking the vault for a code (the CLI's TOTP command). Codes computed on your own device appear only as the `get` that fetched the entry.	agent
`login`	The vault page was unlocked. Entry is how: `unlock`, `register` (a new vault's first device) or `switch_vault`.	Unlocking with your hardware key.	web
`logout`	The vault page was locked. Reason is `manual` or `idle`.	Locking, or the idle timer. Sent as the page closes, best effort.	web
`app_event`	A client's own note in the chain. Entry and Reason are the text the client sent.	A client calling `audit.log_event`. With an entry named, the client must be able to read that entry.	agent

Refusals

A refused request is recorded under its request name — entry.get, entry.create, search.query, vault.export, agent.create, session.event and so on — with outcome denied, the client as actor, its source IP, the entry if the request named one, and a Reason of the form <code>: <why>:

Code	Why
`CLAV-AUTH-002`	Out of the client's scope, or an admin-only action from a non-admin client.
`CLAV-AUTH-003`	No such client in this vault — revoked, or never created.
`CLAV-SEC-001`	Client locked by the two-strike read limit.
`CLAV-SEC-002`	Source address is not on the client's IP whitelist.
`CLAV-RATE-003`	The client's read quota is used up.
`CLAV-RATE-004`	Too many operations per minute.
`CLAV-SEC-004`	An import tried to create clients or scopes.
`CLAV-TAP-004`	The action needs a hardware-key tap and none valid came with it.
`CLAV-WL3-REVOKED` · `CLAV-WL3-NOT-FOUND` · `CLAV-WL3-UNCONFIRMED`	The tapping device was removed from the vault, is unknown, or could not be confirmed with central.

A burst doesn't flood the log: identical refusals of one client for one code within a minute fold into one row, and the next row recorded carries the count — (+12 identical since the last one recorded).

Failures

A failure row means the vault allowed the request but something carrying a security signal went wrong. Two exist, both with actor system:

get · integrity check failed — an entry's stored data didn't verify.
put · unique name — a second scope with a name already taken.

What leaves no row

A wrong vault key or an unknown vault: there is no vault open to write into. These count against the caller's address instead.
A malformed request, a missing entry, or a storage error — none is a refusal.
Unlocking a locked client, and removing a hardware key (that is recorded at central, not in the vault).

Next: read and filter the log →