Role-based access control (RBAC)

Role-based access control (RBAC) is an access model in which permissions are granted to roles, and people get permissions only by being assigned a role. Instead of deciding access person by person, you decide it once per role.

What it is

RBAC has three parts: permissions (an allowed action on a kind of resource), roles (named sets of permissions) and assignments (who holds which role). The model was formalised by NIST and later standardised as ANSI INCITS 359. Two ideas usually come with it: least privilege, where each role gets only what its job needs, and separation of duties, where conflicting powers, such as writing a change and approving it, sit in different roles.

Why it matters

Roles make access reviewable. An auditor can read nine roles; nobody can read a thousand individual grants. When someone changes job, you change one assignment. With AI in the loop, roles also set who may start AI work, who may approve its output and who may change the rules the AI runs under.

In AI CodeOps

Everyone in a workspace has one role, and each permission unlocks one kind of action. Permissions are named resource:action, for example:

workflow_run:manage     start, cancel and re-run AI sessions
approval:decide         approve or reject AI changes
finding_triage:manage   change a finding's status
policy:manage           edit the workspace policy
workspace:audit.read    read the audit log
secret:manage           manage workspace secrets
deployment:manage       merge, record and mark deployments

There are nine built-in roles. Owner, Admin, Developer, Member and Viewer cover the usual levels. Four are separation-of-duties roles, each limited to one area so a single compromised account can do less:

• Security Admin: policies, the audit log, approvals and finding triage. No billing, secrets or sessions.
• DevOps Admin: projects, runbooks, schedules, deployments, incidents, MCP servers, agents and notifications.
• Billing Admin: billing, budgets and usage.
• Secret Manager: workspace secrets only.

Built-in Developers can run sessions but can't approve them, so the person who writes a change with AI and the person who approves it hold different permissions.

On the Enterprise plan, owners and admins can create custom roles under Configure → Settings → Roles & Permissions. You can't grant a permission you don't hold, a role still assigned can't be deleted, and only an owner can change or assign a role with administrative permissions.

Roles govern people. What AI sessions may do on their own is set by the policy engine. Every role change is a role.changed entry in the audit log.

Related terms

• Single sign-on (SSO): sets the default role for people who arrive through your identity provider.
• Audit log: the record of who changed which role.
• Human-in-the-loop: the approval that approval:decide controls.