Every workspace uses a two-layer role model.
  1. Workspace-tier role — coarse, sets what a member can do across the whole workspace.
  2. Module-scoped roles — layered on top, one per product (CLM, PAM, Secrets Manager, NHI Governance). Grant tighter permission to just that module.
A member’s effective permission set is the union of their workspace-tier role and every module-scoped role attached.
RBAC

​
Workspace-tier roles

RoleIntent
ownerFounding member. Full control, cannot be locked out. Every workspace has at least one.
adminFull workspace control — settings, billing, members, every module.
userDay-to-day operator. Read/write on modules the member is enrolled in.
accountantRead-only + billing. Can view invoices, plans, and subscriptions. No product-module access.
module_onlySentinel for members who hold only module-scoped roles — no workspace-tier permission at all. Used for contractors invited into a single module.

​
Module-scoped roles

Layered on top of the workspace-tier role. A member can hold at most one role per module.
ModuleRoles
CLMclm_admin, clm_user
PAMpam_admin, pam_approver, pam_user
Secrets Managersm_admin, sm_user
NHI Governancenhig_admin, nhig_user

​
CLM

  • clm_admin — CAs, templates, policies, workflows, approval configuration.
  • clm_user — issue, renew, revoke, deploy certificates within the workspace’s CAs and templates.

​
PAM

  • pam_admin — enroll resources, define roles, mint join tokens, review recordings.
  • pam_approver — approve/deny access requests. Cannot enroll resources or edit roles.
  • pam_user — connect via tash ssh, tash kube, tash db, tash rdp to resources the member’s bindings cover.

​
Secrets Manager

  • sm_admin — enable engines, write policies, manage auth methods, configure rotation.
  • sm_user — read/write secrets, request dynamic credentials within policy limits.

​
NHI Governance

  • nhig_admin — configure discovery sources, define finding rules, run review campaigns.
  • nhig_user — attest identities they own, respond to review campaigns, view findings.

​
Assigning roles

Settings → Workspace → Members → Invite / Edit:
  1. Pick the workspace-tier role first — admin, user, accountant, or module_only.
  2. Attach module-scoped roles for each product the member should touch.
  3. Save.
Contractors invited into one module get module_only + the specific <module>_user role. They can’t see other modules’ pages at all.

​
Effective permissions

At request time the platform computes: 
effective = tier_permissions(workspace_role)
          ∪ module_permissions(each attached module role)
Owners and admins short-circuit — every request is allowed. module_only members get exactly the union of their module roles and nothing else.

Workspaces

How workspace membership frames the role model.

Policies

Cross-cutting policy enforcement layered on roles.

Audit

Every role change is captured in the audit trail.

API keys

Programmatic access with per-key scopes.