The OpenClaw audit

Most audit features promise more than they deliver. The OpenClaw gateway takes the opposite line: it keeps a bounded, metadata-only ledger in the shared state database and is explicit that the result is evidence of what was recorded, not proof of what happened. The ledger answers operational questions such as which agent ran, when, and how it ended, plus which tool actions a run executed. It stores identity, ordering, provenance, action, status and normalized outcome codes, and it never stores prompts, message bodies, tool arguments, tool results, attachments, filenames, URLs, command output or raw error text.

What the ledger records

• Agent run records covering started and finished events are on by default whenever auditing is enabled, as are tool action records for started and finished tool calls.
• Message lifecycle events are opt-in and disabled by default, with inbound rows written when an accepted message reaches core dispatch and outbound progress rows written when shared durable delivery accepts queue custody and starts platform delivery.
• Every record carries a stable event id, a monotonic owner sequence, a lifecycle timestamp, an actor, an action, a status, a schema version of one and a redaction marker stating that the row is metadata only.
• Records live in the shared state database, are written off the delivery hot path, are never returned by queries once older than 30 days, and are capped at 100,000 rows, with expired rows pruned during startup, hourly maintenance and later writes.

Execution identity recording is off by default, including on fresh installs and upgrades.

Identity, receipts and evidence states

Alongside the activity ledger the gateway keeps an execution identity context for newly admitted agent runs, and it is careful to say that this context is authoritative only for the identity facts it contains. Collection requires both the audit ledger and execution identity recording to be enabled, and no environment variable alias or silent migration turns the feature on. Each admitted outer turn receives a new opaque execution id, a context id identifying its immutable evidence record, and a run id that remains a possibly shared routing, session or recovery correlation. That distinction does real work, because when a run id has several retained executions, inspection returns an ambiguous result with at most 50 candidate execution ids and requires an exact selection, since the gateway never chooses the first or latest execution silently. Terminal operator approvals stay in their own table and are adapted into decision receipts rather than copied into the ledger, with a fixed mapping from each recorded approval result to a stable reason code. A receipt is marked enforced only when the owner changed the outcome and the exact context, execution and run tuple validates. Where evidence is thin the inspector returns a typed diagnostic instead of inventing facts, including unknown, unsupported, ambiguous, unattributed and attribution-only. Persistence itself remains best-effort, so queue saturation, storage failure, shutdown timeout and process crashes can lose evidence, and they log only a bounded operational warning rather than aborting the run.

The privacy model

• Message activity and progress records never store raw platform identifiers, and account, conversation, message and target identifiers are exported only as installation-local keyed pseudonyms.
• The HMAC key is generated on first use, is domain separated per identifier kind and lives in the same state database as the ledger, which makes this correlation rather than anonymisation, because anyone with read access to that database also has the key.
• If the key material is missing or corrupt while message rows are retained, the gateway fails closed and drops new message records instead of silently rotating to a new key, which would split correlation.

Run and tool records retain a session key and session id for correlation, and canonical session keys can themselves contain platform account or peer ids, which is exactly why message records omit both. Read this page beside the OpenClaw security model for the wider model, and beside device pairing if you want to understand why a paired device adds device assurance but never becomes a person.

Stating the limits plainly

The most useful part of this page is the section that tells you what the ledger cannot do. Absence of a row proves nothing: pre-admission inbound drops, sends from plugin-local or direct-send paths that bypass shared durable delivery, a dropped admission envelope and crash-lost queued work can all leave no record at all. Writes go through a bounded asynchronous queue, so saturation, storage failure or a bounded shutdown timeout can drop records and log one operational warning. Crash-ambiguous outbound sends are recorded as unknown rather than given an invented outcome. The page then says the quiet part out loud, that this is a debugging and operational review surface and not a lossless compliance archive, and that an external system is the answer when you need one. The same honesty explains why reader scope is discussed openly, since every client with the operator read scope in the same gateway operator domain may receive the retained identity category, and separate gateway trust domains are the remedy when operators must not share it. Read operator scopes next to this page, and sandboxing if you are thinking about isolation more broadly.

On Diali

On Diali each customer runs their own assistant, and state lives on a persistent volume, so a ledger written today is still there next week; daily snapshots and one-click restore are available through the Backups add-on (included on Max). The runtime configuration is generated from the dashboard and replaced at each release. See Hosted OpenClaw on Diali for what we host, and Diali pricing for what it costs.

• Metadata only: no prompts, no message bodies, no tool arguments, no command output.
• Message lifecycle auditing is opt-in, while run and tool auditing is on by default.
• Absence of a row proves nothing, and the page says so in as many words.