Access, passkeys, and roles
This page describes how operator access to the Control console works today, the current limitations you should plan around, and the role/scope model the product is building toward. The planned role model is published here so operators can plan — it is not a description of enforced behavior.
Current access model
Section titled “Current access model”The following operator access flows are supported:
- Sign-in to the Control console through the identity provider (Auth0).
- Passkey registration for a signed-in operator.
- Invitation delivery and acceptance for new operators.
- Initial sign-in by an invited operator.
Today, all console users share broad organization visibility. There is no least-privilege separation between operators within an organization — this is a current limitation, and the planned model below describes the separation the product is building toward.
Role and scope boundaries
Section titled “Role and scope boundaries”Recovery codes are a current limitation. Recovery codes cannot currently be generated after passkey registration, so losing the passkey device risks losing access. Affected users should keep their passkey device available and contact their administrator if they lose access. Keep more than one owner-capable operator per organization, and do not treat a passkey as the sole credential for an account you cannot afford to lose.
Fine-grained role and scope enforcement is not currently supported. All console users share broad organization visibility, and the console does not enforce per-role or per-scope restrictions. Until fine-grained enforcement is available, verify sensitive outcomes through audit evidence rather than UI feedback.
Both limitations are listed in Availability and product boundaries.
Planned access model
Section titled “Planned access model”| Role | Intended scope |
|---|---|
| Organization owner | Organization-wide: membership, recovery, ownership, and billing. |
| Organization admin | Organization administration minus owner recovery, optionally minus billing. |
| Security admin | Trust anchors, passkeys, revocation, and security/audit controls; no billing. |
| Billing admin | Billing and subscription only. |
| API owner / Auth Site admin | Lifecycle, protected surfaces, route policy, and clients — within assigned Auth Sites only. |
| Client user | The exact assigned Auth Site and client; client metadata and approved key lifecycle only. |
| Audit reader | Audit/evidence plus safe operational context; no client material, no trust-anchor configuration, no policy mutation. |
| Developer reader | Explicitly scoped read-only; no write forms and no ambiguous action buttons. |
Scope hierarchy
Section titled “Scope hierarchy”Scopes nest strictly:
organization → environment → fleet → Auth Site → client
A role grant attaches at one level of this hierarchy and confers nothing outside it.
One permission model everywhere
Section titled “One permission model everywhere”The target model requires that server authorization, query filtering, navigation visibility, disabled/hidden mutation controls, and explicit error/success feedback all share one permission model. A single source of truth must decide what an operator can do, what they can list, what they can see in navigation, which controls are disabled or hidden, and what feedback a denied or successful action produces.
Where to go next
Section titled “Where to go next”- Availability and product boundaries — the consolidated list, including both access limitations above
- Settings and Billing — operator identity, sessions, and subscriptions
- Enrollments — where role-gated approval actions surface today
- Audit — verify outcomes with evidence rather than UI feedback