Roles and permissions

NuBench uses a fixed set of platform roles. Every user holds exactly one role per organisation, and the role is enforced at two layers: the console router (which surfaces a user can open) and the governance gateway (which API operations succeed).

The roles

| Role | Consoles | What it's for | | --- | --- | --- | | End user | Chat | Daily AI work: conversations, files, model selection within policy | | Team lead | Chat | End-user capabilities plus visibility into their team's usage | | Dept head | Chat | Team-lead scope across a department, including budget visibility | | Auditor | Admin (read-only surfaces) | Read access to the audit trail and policy configuration — no ability to change anything | | IT admin | Chat, Admin | Technical administration: SSO, providers, DLP configuration | | Org admin | Chat, Admin | Full organisation administration: users, budgets, policies, retention | | Super admin | All, incl. Super-admin | NuBench platform operators. Not assignable to customer accounts |

Enforcement model

• Console gating. The admin console requires an admin-tier role (org admin, IT admin, or super admin). The super-admin console requires super admin. Users without the role receive a 403 — not a hidden menu, an actual refusal.
• API gating. The governance gateway re-checks the role claim on every request as part of its authentication step, before any model is called. Role changes take effect at the next sign-in.
• Least privilege by default. New users are end users unless explicitly granted more. There is no "everyone is admin during the trial" mode.

Practical guidance

• Assign org admin sparingly — it can change budgets, policies, and membership. Two per organisation is a common pattern (primary + deputy).
• Use auditor for compliance staff who need evidence, not control. The audit trail is readable without granting any write permission.
• Map roles from your IdP groups where possible (see Single sign-on) so joiners and leavers are handled by your existing lifecycle processes.