Administration
Roles and permissions
A role is a set of permissions. inline ships eight that cover the usual shapes, and you can build your own from the same pieces.
Granting a role is an admin task. To work out why part of the portal is missing for you, see What your role changes on screen.
#How a permission is put together
Every permission names a module and an action on that module. Reviews is a module, and reading a review is an action on it. A role is a list of those pairs, and a grant gives a teammate a role somewhere.
A role permits only the actions it names, so widening someone's access is always a deliberate edit.
#Where a role applies
| Scope | What it applies to |
|---|---|
| Workspace | Everything in that workspace. The usual choice. |
| Repository | Only work that names one of the repositories you picked. Good for a contractor, or a team that owns part of your codebase. |
| Platform | The deployment itself, held by whoever runs it rather than by anyone in a workspace. |
Repository scope suits the product modules: reviews, repositories, walkthroughs, visual plans, conversations, security, compliance, CI/CD monitoring, pentest, prompt evals and the code graph. Workspace governance stays workspace-wide.
#The eight built-in roles
Roles & permissions
A role is a set of permissions, granted per module and action. Built-in roles cover the common shapes; duplicate one to build your own.
| Role | Scopes | What they can do |
|---|---|---|
| Owner | Workspace | Full control of the workspace, including deleting it and transferring ownership. |
| Admin | Workspace | Manages repositories, members, connections and every product module. |
| Security lead | Workspace, repository | Owns security, pentest and cloud posture. Reads reviews; no workspace governance. |
| Developer | Workspace, repository | Sees reviews of their own pull requests, comments on walkthroughs and plans. |
| Auditor | Workspace, repository | Read-only across every module, plus the audit log. Cannot change anything. |
| Role | What it is for |
|---|---|
| Owner | Full control of the workspace, including deleting it and transferring ownership. |
| Admin | Manages repositories, members, connections and every product module. |
| Security lead | Owns security, pentest and cloud posture, and reads reviews. |
| Compliance officer | Owns vendor agreements and compliance findings. Read-only elsewhere. |
| Developer | Sees reviews of their own pull requests, comments on walkthroughs and visual plans, and manages their own registered-agent credentials. |
| Auditor | Read-only across every module, plus the audit log. |
| Billing | Usage and subscription only. |
| Platform administrator | Runs the deployment itself. |
Developer is what most engineers want. It gives a teammate the member view described in Reviews in the portal.
#Building your own role
Duplicate a built-in role and edit the modules and actions it names. A custom role can express only permissions that already exist, so it can never grant more than the model allows.
Custom roles and per-repository grants are included with Enterprise. See Plans and billing.
#Registered agents are principals too
A registered agent has its own credential and its own scopes. What that registered agent can actually do is its scopes narrowed by the permissions of the person it acts for, worked out for every call and every repository.
Granting a registered agent broad scopes gives it the access its owner already had, and no more. Governance stays with people: no registered agent can manage members, roles, connections or the workspace itself.
#What your role changes on screen
Your rail shows the groups your role lets you open, so your portal and a teammate's can look different. Opening a page your role does not cover takes you back to the dashboard, and opening a single item it does not cover returns a not-found.
A section your workspace's billing plan does not include stays visible with a padlock, and opening it shows you what that section does and what switching it on would take.