Identity and roles

Device-authenticated control-plane clients present signed identities and go through pairing. Reconnecting with broader device scopes requires approval. Other admission paths include verified front doors and configured local or shared-secret access. With DM policy set to pairing, unknown senders get a pairing code, not the agent. Identity-aware front doors (Tailscale, trusted proxy, Cloudflare Access) map verified identities to scopes.

Eight operator scopes — read, write, admin, plus narrower ones for pairing, approvals, questions, and talk — are derived per request from the actual parameters before dispatch, and methods with no scope classification are denied rather than allowed. Write and admin operations require their corresponding scopes. gateway.roles assigns named person-level roles: visibility into other people's sessions, an agent allow-list, and a scope ceiling that is intersected with whatever connection auth granted, never added to it. Profiles without a valid assignment receive the configured default role; configure that role as deny-all for a hardened deployment. Omitting gateway.roles leaves the role boundary disabled. Multi-user sessions record an immutable creator, an assignable owner, and a bounded participant history, and verified GitHub identity can flow through to Co-authored-by trailers and PR-linked session transcripts (user model).

Our security docs define the scope: one gateway is one trust domain. Roles organize collaboration between people who already trust each other. For tenancy, you run one gateway per tenant; openclaw fleet automates this with one hardened container cell per tenant with its own state, credentials, and network (currently experimental), and the multi-tenant guide documents the isolation ladder above it, through gVisor and Kata up to separate machines.