OpenClaw audit history

When something went wrong last Tuesday, an operator wants to know which agent ran, when, how the run ended and which tool actions it executed, without the ledger becoming a second copy of every conversation. OpenClaw’s Gateway keeps exactly that: a bounded, metadata-only audit ledger in the shared state database, plus, when message auditing is enabled, whether an accepted inbound message reached dispatch and whether an outbound message reached a terminal delivery state. Here is what a record carries, what it never stores, the opt-in identity layer and its evidence states, the approval receipts, the message lifecycle modes, the privacy model, and the limits the docs insist on.

What is recorded

• The ledger stores identity, ordering, provenance, action, status and normalised outcome codes; it never stores prompts, message bodies, tool arguments, tool results, attachments, filenames, URLs, command output or raw error text.
• Two record families are on by default, agent run started and finished and tool action started and finished; the message family, inbound processed and outbound queued, platform-started and finished, is off by default. Every record carries a stable event id, a monotonic owner sequence, a lifecycle timestamp, an actor, an action, a status, a schema version and a metadata-only redaction marker.
• Message auditing has three modes, off, direct for direct conversations only, and all for direct, group and channel messages; inbound rows are written when an accepted message reaches core dispatch, outbound progress when durable delivery takes custody and starts platform delivery, and terminal rows record sent, suppressed, failed or an explicit unknown for a crash-ambiguous send.
• Direct mode is a privacy boundary: a message is classified direct only when destination facts prove it, weaker signals can only classify it as group, and anything unproven is unknown and not recorded in direct mode, so channels that do not declare chat types record fewer rows there than in all mode.

Absence of a row proves nothing.

Execution identity and receipts

Alongside the ledger the Gateway can keep an execution identity context for newly admitted runs, off by default on fresh installs and upgrades and enabled explicitly with a logging setting plus a restart; it is authoritative for the identity facts it contains but does not make the ledger lossless or turn audit records into authorisation evidence. Each admitted outer turn receives a new opaque execution id and a context id for its immutable evidence record, while the run id remains a possibly shared correlation, so the inspector never picks the first or latest execution silently: a run with several retained executions returns ambiguous with at most fifty candidates. Inspection reports the trust domain, invoker and ingress, the agent principal, definition and runtime instance, the represented subject and sponsor, grants and assurance evidence, and lineage when available, and it answers with typed states rather than invented facts: unknown, unsupported, ambiguous, unattributed when no invoker principal exists, and attribution-only when attribution exists but was never evaluated for authorisation. Terminal operator approvals stay in their own table and are adapted into decision receipts with stable reason codes, allowed once or always, denied by reviewer, expired, cancelled by run abort or Gateway restart, no delivery route, malformed verdict, corrupt storage, and missing, malformed or mismatched execution bindings; only an exact context, execution and run tuple projects an approval as enforced, and the receipt never includes the command, arguments, path, environment or reviewer device.

Privacy and limits

• Message records never store raw platform identifiers: account, conversation, message and target ids are exported only as installation-local keyed pseudonyms whose HMAC key is generated on first use, domain-separated per identifier kind, and kept in the same database. The docs call this correlation, not anonymisation, since anyone who can read the database also holds the key, and if the key is missing or corrupt while rows are retained the Gateway fails closed and drops new message records rather than rotating and splitting correlation.
• The ledger is best-effort and deliberately bounded: writes go through an asynchronous process-owned queue that can drop records under saturation, storage failure or a bounded shutdown timeout with one operational warning, crash-ambiguous sends are recorded as unknown, and pre-admission drops or sends through plugin-local paths can leave no row at all. It is not a lossless compliance archive; for that the docs point to an external system fed by OpenTelemetry.
• Records live in the shared state database off the delivery hot path, queries never return rows older than thirty days, the ledger is capped at a hundred thousand rows, identity contexts at a hundred thousand, outbound progress at two hundred thousand and generic decision facts at two hundred and fifty thousand, with pruning limited to 1,024 rows per transaction and maintenance that keeps running even when collection is disabled.

The OpenClaw agent loop is the run whose start, finish and tool events land here, and OpenClaw exec approvals the owner-native decisions the inspector adapts into receipts.

Who can read it

The activity and inspection calls require operator read access, and every client with that scope in the same Gateway operator domain may receive the retained identity category; the docs are explicit that this scope already covers logs and session reads and is not a hostile multi-tenant boundary, so operators who must not share diagnostic data need separate Gateway trust domains. OpenClaw multi-user setups covers those boundaries, and OpenClaw doctor the command that migrates an older run-and-tool-only ledger at startup.

On Diali

On Diali the ledger sits in the assistant’s state database on its volume with the upstream defaults, runs and tool actions on, message lifecycle off, identity recording off, and nothing in it leaves the instance. Hosted OpenClaw on Diali is the assistant and Diali security describes the boundary around it.

• Identity, ordering, outcome codes; never content.
• Pseudonyms correlate; they do not anonymise.
• Thirty days, bounded rows, evidence of what was recorded.