OpenClaw Main Tightens Verified Identity and Delegated Run Authority

OpenClaw has merged a broad authority-hardening sequence into main. The common theme is not a new role or permission: it is preserving one canonical identity and owner context as work moves from ingress through internal turns, delegation, retries and channel-specific approval delivery.

This deserves operator attention because identity bugs rarely look dramatic. They look like a valid request gaining the wrong scopes, an approval appearing on the wrong account, or a retry being authorised from reconstructed context that no longer matches admission.

Availability: the changes are merged to main; the reviewed sources do not establish a containing stable release. They are hardening changes, not evidence that every earlier revision is exploitable in every deployment.

Scope comes from verified identity

PR #121531 moves Gateway scope grants toward verified identity context. A client-visible connection shape or claimed header should not be enough to select operator authority; the trusted ingress mechanism must establish the identity first.

This is especially relevant for trusted proxies and multi-user Gateways. The reverse proxy must strip untrusted identity headers, authenticate the user and forward only the documented identity fields over a network path that cannot bypass it.

Delegated work keeps admission context

PR #120534 introduces a canonical admitted-run context and preserves it across retries and delegated execution boundaries. The merge also fences legacy launch dialects and narrows where delegated authority proof can be validated.

PR #121715 removes synthetic RPC clients and fabricated wire frames from ten Gateway-internal agent-turn callers in favour of a typed process-internal facade. The landed sequence explicitly preserves typed-turn authorisation, request validation and lifecycle parity.

Interpretation: avoiding loopback-shaped internal calls is not just a performance refactor. It reduces the number of places where trusted in-process work can be mistaken for an external client—or where a fabricated external frame can accidentally become an authority source.

Approvals stay with the owning account

PR #121673 binds native approval requests to the channel account that owns the operation. On installations with several accounts for one provider, the destination account is part of the authorization context, not merely a delivery preference.

PR #121532 similarly restricts Matrix verification-management actions to trusted sender context identifying an owner. The action must be hidden and denied for non-owners; UI omission alone is not enforcement.

What operators should test

Use non-production identities and harmless commands:

1. connect directly and through the real trusted proxy; prove spoofed identity headers never grant scopes;
2. admit a turn, retry it and delegate a subtask; verify the original owner and policy context remain stable throughout;
3. attempt to supply delegated authority fields through plugin or client input and require Gateway-owned context to win or the call to fail;
4. configure two accounts on one channel, request an approval through each and verify prompts and receipts remain bound to the initiating account;
5. test owner and non-owner Matrix users against both advertised commands and direct dispatch; the non-owner must be denied in both places;
6. restart during a delegated run and verify recovery does not manufacture a broader identity context; and
7. retain admission, approval and provider delivery identifiers together for incident review.

Do not log raw bearer tokens, proxy assertions or full identity payloads while performing this test.

Bottom line

OpenClaw is replacing reconstructed authority with carried authority. Operators should treat the containing upgrade as an authorization migration: validate trusted-proxy headers, delegated retries and multi-account approvals end to end before relying on the new identity record in production.