Skip to navigation
DocumentationAccess Control

Authorization

View as Markdown

NeMo Helix authorization controls what authenticated principals can do. Every API request is evaluated against the principal’s role bindings, and against token scopes when the token carries NeMo Helix API scopes.

The authorization model has four building blocks:

  1. Workspaces — the authorization boundary. All resources belong to a workspace.
  2. Roles — permission bundles (Viewer, Editor, Admin) granted per workspace.
  3. Role bindings — the link between a principal, a role, and a workspace.
  4. Scopes — token-level restrictions that limit what the token can do, independent of the principal’s role.
Request → PDP → Scope check → Role binding check → Allow / Deny

For a request to succeed, the role check must pass. If the token contains platform API scopes such as intake:write or platform:read, the scope check must pass too.

For the full conceptual background, see Authorization Concepts. For the security architecture, see Security Model.

Key Pages

Roles & Permissions

Complete permission matrix — what each role can do.

Managing Access

Add users to workspaces, assign roles, manage members.

API Scopes

Token-level scope model and two-layer authorization.

Permissions Reference

Complete list of all permissions with role assignments.

Policy Engine

OPA / WASM policy engine internals and configuration.