> This page is for version 0.10.
> For other versions, use one of these documentation indexes:
> - Latest (default): https://docs.nvidia.com/nemo-helix/latest/llms.txt
> - 0.10: https://docs.nvidia.com/nemo-helix/v0.10/llms.txt
> - 0.9: https://docs.nvidia.com/nemo-helix/v0.9/llms.txt
> - 0.8: https://docs.nvidia.com/nemo-helix/v0.8/llms.txt
> - 0.7: https://docs.nvidia.com/nemo-helix/v0.7/llms.txt
> - 0.6: https://docs.nvidia.com/nemo-helix/v0.6/llms.txt
> - 0.5: https://docs.nvidia.com/nemo-helix/v0.5/llms.txt

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/nemo-helix/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/nemo-helix/_mcp/server.

# Roles and Permissions

The authoritative reference for NeMo Helix roles and their permissions. For background on how RBAC works, see [Authorization Concepts](/nemo-helix/v0.10/documentation/access-control/concepts). For managing workspace members, see [Managing Access](/nemo-helix/v0.10/documentation/access-control/authorization/managing-access).

## Role Descriptions

NeMo Helix 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

**HelixAdmin** — For platform operators who manage the entire NeMo Helix 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

## Service Entity Storage

`ServiceEntityStore` grants direct service principals `entities.create`,
`entities.read`, `entities.update` and `entities.delete` in the bound workspace.
It does not grant workspace metadata, IAM or dependency-service permissions.
Human roles and the creator default are unchanged: every authenticated
workspace creator receives Admin.

Applications configure their own additional roles through the workspace member
API. Scaled Evals adds Admin and ServiceEntityStore in its private workspace,
preserving other existing bindings. Admin supplies workspace reads and role
management; the plugin owns the storage assignment on creation and restart.
The member API is idempotent and uses the existing role-propagation option.
There is no core backfill or database migration.

Raw role-binding and access-key entities require IAM permissions in addition
to entity permissions. This role does not change legacy service fallback in
other workspaces or establish ownership isolation inside shared workspaces.

## Role Hierarchy

The human-facing roles include all permissions of the roles below them. JobRunner is intentionally outside this hierarchy.

```mermaid
flowchart BT
    Viewer["Viewer
+list
+read
+inference"]
    Editor["Editor
+create
+update
+delete
+cancel"]
    Admin["Admin
+manage members
+change visibility"]
    HelixAdmin["HelixAdmin
all workspaces
all operations"]

    Viewer --> Editor
    Editor --> Admin
    Admin --> HelixAdmin
```

## 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](/nemo-helix/v0.10/documentation/access-control/authorization/permissions-reference) for workload-role permissions such as JobRunner.

### Workspace Operations

| Operation                         | Viewer | Editor | Admin | HelixAdmin |
| --------------------------------- | :----: | :----: | :---: | :--------: |
| List workspaces (visible to user) |    ✓   |    ✓   |   ✓   |      ✓     |
| Delete workspace                  |        |        |   ✓   |      ✓     |
| List workspace members            |    ✓   |    ✓   |   ✓   |      ✓     |
| Add / remove members              |        |        |   ✓   |      ✓     |
| Change workspace visibility       |        |        |   ✓   |      ✓     |

> **Note**
>
> Workspace creation is controlled by the `WorkspaceCreator` role 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. The same role includes `workspaces.deletion.read`, so the original creator can read deletion status for a name that is still reserved after delete. A platform admin can read any deletion status.

### Resource Operations (Models, Datasets, Projects)

| Operation            | Viewer | Editor | Admin | HelixAdmin |
| -------------------- | :----: | :----: | :---: | :--------: |
| List resources       |    ✓   |    ✓   |   ✓   |      ✓     |
| View / read resource |    ✓   |    ✓   |   ✓   |      ✓     |
| Create resource      |        |    ✓   |   ✓   |      ✓     |
| Update resource      |        |    ✓   |   ✓   |      ✓     |
| Delete resource      |        |    ✓   |   ✓   |      ✓     |

### Jobs (Customization, Evaluation, Data Design)

| Operation        | Viewer | Editor | Admin | HelixAdmin |
| ---------------- | :----: | :----: | :---: | :--------: |
| List jobs        |    ✓   |    ✓   |   ✓   |      ✓     |
| View job / logs  |    ✓   |    ✓   |   ✓   |      ✓     |
| Create / run job |        |    ✓   |   ✓   |      ✓     |
| Cancel job       |        |    ✓   |   ✓   |      ✓     |
| Delete job       |        |    ✓   |   ✓   |      ✓     |

> **Note**
>
> JobRunner can upload logs from workload containers but does not grant job creation, job management, or workspace read access by itself.

### Inference

| Operation                                                 | Viewer | Editor | Admin | HelixAdmin |
| --------------------------------------------------------- | :----: | :----: | :---: | :--------: |
| Run inference (chat completions, completions, embeddings) |    ✓   |    ✓   |   ✓   |      ✓     |

### Deployment

| Operation         | Viewer | Editor | Admin | HelixAdmin |
| ----------------- | :----: | :----: | :---: | :--------: |
| List deployments  |    ✓   |    ✓   |   ✓   |      ✓     |
| View deployment   |    ✓   |    ✓   |   ✓   |      ✓     |
| Create deployment |        |    ✓   |   ✓   |      ✓     |
| Update deployment |        |    ✓   |   ✓   |      ✓     |
| Delete 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-data` has `*` → Viewer
* `alice@company.com` has explicit Editor binding in `shared-data`
* Alice's effective role: **Editor** (highest of Viewer and Editor)

## Default Workspace Bindings

NeMo Helix automatically provisions wildcard bindings on built-in workspaces:

| Workspace | Wildcard Role            | Effect                                                                        |
| --------- | ------------------------ | ----------------------------------------------------------------------------- |
| `default` | Editor for `*`           | All authenticated users can create and manage resources                       |
| `system`  | Viewer for `*`           | All authenticated users have read-only access to system resources             |
| `system`  | WorkspaceCreator for `*` | All authenticated users can create workspaces until operators rebind the role |

## 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](/nemo-helix/v0.10/documentation/access-control/concepts) — Workspaces, roles, bindings, and the RBAC model.
* [Managing Access](/nemo-helix/v0.10/documentation/access-control/authorization/managing-access) — Add users, assign roles, manage workspace members.
* [API Scopes](/nemo-helix/v0.10/documentation/access-control/authorization/api-scopes) — Token-level scope restrictions.
* [Security Model](/nemo-helix/v0.10/documentation/access-control/security-model) — Trust boundaries and authorization layers.