OpenClaw Main Adds Opt-In Execution Identity Inspection for Audit Trails
Operators can correlate one admitted agent execution without mistaking a multi-turn run ID for an execution ID, with bounded pseudonymized retention.
OpenClaw has merged an opt-in audit feature for answering a narrow but important incident question: which identity evidence was available when this exact agent execution was admitted?
PR #117034 introduces a distinct executionId for each admitted outer turn and a bounded, pseudonymized execution-identity record. That avoids treating public runId as an execution identifier when one run can correlate several turns.
Collection is off by default under logging.audit.executionIdentity. The feature is on main; the upstream record does not establish a containing package.
The operator decision
Enable this only when exact execution attribution materially improves incident response, compliance evidence or delegated-authority review—and only after the storage, access and retention policy has an owner.
Leave it off if ordinary audit events already answer your questions or if retaining pseudonymized identity context creates more governance cost than investigative value. “Pseudonymized” does not mean anonymous, harmless or exempt from access control.
What the feature records
Each admitted outer execution receives a distinct internal execution identifier. Public run IDs remain unchanged and are used only for bounded discovery; they are not silently promoted into proof of one exact turn.
Upstream describes the captured context as bounded and pseudonymized. Persistence runs through the asynchronous audit writer so an audit-storage failure does not block an agent execution. Exact retries and enabled durable recovery retain the original execution identity instead of manufacturing a new attribution record for the same admitted work.
The optional identity table is created only after the first enabled capture. Fresh or upgraded installations with collection disabled should not create it merely because the Gateway starts.
Retention and trust boundary
The merged policy reports:
- a 30-day expiry window, enforced on reads;
- bounded maintenance work of up to 1,024 rows at a time;
- a cap of 100,000 retained contexts; and
- continued bounded cleanup of an existing table after collection is disabled.
The public Plugin SDK ingress path also strips caller-supplied recovery identity at runtime, including inherited JavaScript properties. Only the Gateway-owned recovery path may carry the private admission token.
That is essential. If a plugin or external caller could inject identity context, the audit record would describe an assertion rather than authoritative admission evidence.
Interpretation: execution identity is correlation evidence, not proof that a person intended, approved or caused every downstream effect. Preserve provider-side message IDs, approval records and destination audit logs alongside it.
Safe rollout checklist
Use synthetic identities and disposable state:
- start with the setting absent and explicitly off; prove no new execution-identity table or records appear;
- enable collection and admit two turns under one run; prove they receive distinct execution IDs;
- retry one admitted execution through the supported recovery path; prove it retains the original identity context;
- attempt to inject recovery identity through a plugin or plain JavaScript object; prove Gateway-owned values win;
- query by exact execution ID and verify run-ID discovery cannot silently select the wrong turn;
- cross the retention cutoff and confirm expired rows are unreadable and maintenance remains bounded; and
- disable collection, prove no new captures occur, then verify existing retained rows continue through the documented cleanup lifecycle.
Restrict inspection to trusted operators. A read API can expose sensitive correlation even when values are pseudonymized and raw identity material is not stored.
Evidence and limits
The official PR and landed commit establish the opt-in setting, execution-versus-run distinction, worker-owned persistence, bounded retention and private recovery boundary. The upstream record reports focused recovery, storage, SDK-ingress and QA coverage. OpenClaw Academy did not inspect a production audit database or independently assess a regulator-specific compliance posture.
Collector IDs 38521, 38487 and 38511 identify the merged PR, commit and documentation-bearing change.
Bottom line
Enable execution identity because you have a defined attribution question, not because more logs feel safer. The containing build should prove exact-turn correlation, non-forgeable recovery context, bounded retention and zero capture while disabled before the records are admitted into an incident or compliance workflow.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF