Roles and Permissions
The authoritative reference for NeMo Platform roles and their permissions. For background on how RBAC works, see Authorization Concepts. For managing workspace members, see Managing Access.
Role Descriptions
NeMo Platform provides human-facing roles for interactive users and a separate workload role for job runtime identities:
Viewer — For stakeholders who need visibility into resources but should not modify them.
- View all resources in a workspace (models, datasets, jobs, evaluations)
- Run inference on deployed models
- View job logs and evaluation results
- Cannot create, update, or delete any resources
Editor — For team members who actively work with resources.
- All Viewer permissions
- Create, update, and delete resources (models, datasets, evaluations, jobs)
- Run customization jobs, evaluations, and data design tasks
- Cannot manage workspace members or settings
Admin — For workspace owners who manage their team’s access.
- All Editor permissions
- Add and remove workspace members
- Change member roles
- Grant wildcard access (
*) to the workspace - Change workspace visibility
PlatformAdmin — For platform operators who manage the entire NeMo Platform deployment. This role bypasses all workspace-level authorization.
- All Admin permissions across every workspace
- Access all workspaces regardless of role bindings
- Manage platform-level configuration
- Create and delete any workspace
JobRunner — For workload identities used by running jobs, not interactive users.
- Upload job logs produced by workload containers
- Does not include Viewer, Editor, or Admin permissions
- Should be granted alongside the minimum human-facing role the workload needs, such as Viewer when the workload only reads workspace resources
Role Hierarchy
The human-facing roles include all permissions of the roles below them. JobRunner is intentionally outside this hierarchy.
Permission Matrix
Rows are operations; columns are human-facing roles. Read the hierarchy above first: each role inherits everything below it, and the tables call out the points where additional privileges appear. See Permissions Reference for workload-role permissions such as JobRunner.
Workspace Operations
Workspace creation is controlled by the WorkspaceCreator permission in the system workspace rather than by the workspace roles in the table above. By default, platform seed grants WorkspaceCreator to the wildcard principal *, so all authenticated users can still create workspaces until operators change that binding. The creator automatically becomes Admin.
Resource Operations (Models, Datasets, Projects)
Jobs (Customization, Evaluation, Data Design)
JobRunner can upload logs from workload containers but does not grant job creation, job management, or workspace read access by itself.
Inference
Deployment
Wildcard Principal Behavior
The wildcard principal * grants a role to all authenticated users. When both a wildcard binding and an explicit binding exist for a user in the same workspace, the highest role wins.
Example:
- Workspace
shared-datahas*→ Viewer alice@company.comhas explicit Editor binding inshared-data- Alice’s effective role: Editor (highest of Viewer and Editor)
Default Workspace Bindings
NeMo Platform automatically provisions wildcard bindings on built-in workspaces:
Admin Protection
Every workspace must have at least one Admin. The platform enforces this:
- You cannot remove the last Admin from a workspace
- You cannot change the last Admin’s role to Viewer or Editor
To leave a workspace where you are the only Admin, add another Admin first.
Related
- Authorization Concepts — Workspaces, roles, bindings, and the RBAC model.
- Managing Access — Add users, assign roles, manage workspace members.
- API Scopes — Token-level scope restrictions.
- Security Model — Trust boundaries and authorization layers.