ZeroClaw records an identity architecture whose full rollout is still unfinished

A September 13 ZeroClaw documentation proposal gives its inbound-authentication program an explicit architecture record. ADR-016 describes three jobs that should not be collapsed: a provider verifies credentials, a shared resolver maps the verified actor into a canonical principal and grants, and privileged runtime surfaces enforce that result. The earlier governing RFC is accepted; the new ADR itself remains proposed until its implementation conditions are met.

That distinction matters because the current tracker mixes foundation work already merged with later slices still under review or draft. Its wording sometimes says a capability landed while also labeling the corresponding PR draft. The safe reading is that reviewable implementation work exists, not that the entire identity system is available in a stable release.

The facts

- ADR-016 is documentation-only: it implements no authentication, changes no configuration and does not mark itself accepted. - The governing RFC keys OIDC identities by validated issuer and subject, not subject alone. - Service credentials resolve to service principals rather than inheriting human sessions or private memory. - Provider claims do not become runtime grants without the shared permission-profile mapping. - Native pairing and local peer credentials are required compatibility paths so operators are not forced to deploy an identity provider. - The tracker lists merged foundation seams but later principal resolution, RPC enforcement, storage ownership and integration work as staged review surfaces.

Why it matters

An agent platform can support several login methods while still lacking one coherent answer to who owns a session or may read its memory. ZeroClaw’s direction is to make that answer independent of the credential used at the front door. The architectural record is useful precisely because it names unfinished enforcement and recovery conditions. Treating an accepted design as shipped isolation would erase the distinction the document is trying to establish.

Current

Inspected on 2026-09-14. The ZeroClaw stable-channel baseline is v0.8.5 published 2026-09-05T07:31:19Z. The primary source was open (not merged) when captured. Mainline merges, open proposals and packaged releases are distinct availability states; the release baseline does not establish that a proposal has shipped.

Evidence

Primary evidence: zeroclaw-labs/zeroclaw PR #10831 (https://github.com/zeroclaw-labs/zeroclaw/pull/10831). Supporting context: zeroclaw-labs/zeroclaw issue #7141 (https://github.com/zeroclaw-labs/zeroclaw/issues/7141); zeroclaw-labs/zeroclaw issue #8289 (https://github.com/zeroclaw-labs/zeroclaw/issues/8289). Public source bodies and linked documentation were inspected. Contributor test results remain attributed reports, not independently reproduced experiments.

Operator take

Review the ownership path end to end: credential verification, principal mapping, tool and configuration grants, session access and private-memory storage. For a migration, test reconnects and a local recovery path before depending on a new identity provider. The RFC also warns against accidental account linking through equal strings across providers; validate issuer boundaries and explicit roster mappings rather than assuming that two accounts named alike are the same operator.

Caveat

This is a design-direction and rollout-status brief, not a claim that current ZeroClaw installations have complete new enforcement or that a vulnerability was reproduced. The ADR was open and proposed. The tracker contains mixed delivered/draft language, so individual merge and release status remains necessary before operators rely on a particular boundary.