Roles and permissions
What admins, editors, and viewers can see and do, which capability each action needs, and how MCP scopes follow roles.
Every member of an organization holds exactly one of three roles, and every action checks a capability derived from that role. Pages are gated by customer segment rather than role, so the difference between roles is almost entirely about writing, settings, and billing.
Roles
| Role | Label | Description |
|---|---|---|
| Admin | Admin | Full access to all organization features and settings |
| Editor | Editor | Can manage content and workflows, limited settings access |
| Viewer | Viewer | Read-only access to organization data |
Roles are ordered: anything an editor can do, an admin can do too.
Capabilities
| Capability | What it gates | Admin | Editor | Viewer |
|---|---|---|---|---|
org.read | Reading any organization data; every page in the sidebar | ✓ | ✓ | ✓ |
org.write | Creating, editing, linking, and deleting records; Cortex write tools | ✓ | ✓ | — |
settings.manage | The whole /settings page: general, billing, context, members, MFA, frameworks, privacy, developer, integrations | ✓ | — | — |
billing.checkout | Starting a checkout | ✓ | ✓ | — |
Where roles apply
| Area | Who | Note |
|---|---|---|
| Sidebar pages | All roles | Every item requires only viewer; what appears depends on the customer segment (compliance, privacy, or both), not the role |
/settings and every tab under it | Admin | Editors and viewers are redirected to the overview |
| Creating and editing records | Editor, admin | Viewers see the same pages with the actions disabled or rejected |
| Cortex actions that change data | Editor, admin | Viewers can ask Cortex questions but it cannot write for them |
| API keys | Admin | Created and revoked under SettingsDeveloper; a key acts as its creator |
| MCP OAuth scopes | Capped by role | See the table below |
| Removing the last admin | Nobody | An organization always keeps at least one admin |
| Deleting the organization | Admin | Requires typing the organization name; cannot be undone |
Pages by customer segment
| Segment | Pages |
|---|---|
| Compliance only | Overview, Controls, Assets, Policies, Security (Certificates, Findings), Vendors › Questionnaires, Personnel (People Directory, Training & Acknowledgement), Audit (Audit Calendar, Internal Audit, External Audit), Trust Center (Builder, Requests) |
| Privacy only | Privacy plan dashboard, Privacy (Overview, Inbox, Data map, Records, Assessments, Monitoring) |
| Both segments | Evidence Vault, Risk Management (Risk Register, Reports), Vendors › Vendor Register, Data Sources |
MCP scopes by role
| Role | Scopes an OAuth token may hold |
|---|---|
| Admin | Every read:* and write:* scope |
| Editor | Every read:* and write:* scope |
| Viewer | read:* scopes only |
The cap is applied on the consent screen, at token issue, on every validation, and on refresh. API keys are not capped this way because only admins can create them. Full scope list: API keys.
Sign-in role mapping
The role Noru holds for you is authoritative. When a member is synced from the sign-in provider, the provider's organization role is mapped into a Noru role:
| Sign-in provider role | Noru role |
|---|---|
| Admin | admin |
| Member | editor |
| Viewer | viewer |
| Anything else, or missing | viewer |
Related
- Members settings to change a member's role
- Under the hood: RBAC and security model
- MCP server
Last updated on