Access control

Nanami uses two customer-facing layers of access control:

1. Workspace role — the primary built-in or custom role that defines baseline workspace access.
2. Department override — an optional additive role for one department when that scope is enabled.

Account roles (customer-facing)

• Owner (super_admin) — full access across workspaces (SaaS).
• Admin (admin, legacy tenant_admin) — workspace-level admin access.
• Member (member) — default user role.
• Viewer (viewer) — read-only workspace access where enabled.

Account roles control platform-level operations (bootstrap, SSO, billing).

RBAC roles and permissions

RBAC roles define permission keys such as:

• network.read, network.write
• gateway.read, gateway.write
• agents.read, agents.update
• membership.manage

The supported customer-facing scope model is:

• Workspace role: baseline access across the workspace.
• Department override: extra access inside one department, additive on top of the workspace role.

Legacy lower-level assignment primitives may still exist in backend compatibility paths, but the default release contract is the workspace-role-plus-department-override model above.

Managing users & access

In the WebUI:

• Go to Users & Access.
• Assign one primary workspace role.
• Add or remove department overrides where that scope is available.
• Use reset password when onboarding users.

Community vs SaaS

• Community: the customer-facing role model still stays workspace-first. Advanced RBAC capabilities such as custom roles or department overrides may be edition/plan gated.
• SaaS: owners manage platform-wide resources; workspace admins manage workspace roles and department overrides within their workspace.

RBAC boundaries

• Workspace admins cannot grant super_admin/Owner or global-scope permissions.
• Workspace admins cannot remove the last active workspace admin.
• System roles are immutable; custom roles are workspace-scoped in the default customer-facing contract.

See the Roadmap for upcoming improvements.