Users & roles
Access in Gamut is governed by roles. A role maps to a precise set of namespaced permissions
(for example system.update, finding.export, agent.approve), and every state-changing action
checks for the permission it requires. Roles are not free-form; they are a defined catalogue,
enforced the same way in the interface and behind every API call.
Three scopes of role
Section titled “Three scopes of role”Roles exist at three scopes, and a user’s effective access is the combination.
Tenant roles
Section titled “Tenant roles”What a user can do across the organisation:
| Role | Access |
|---|---|
| Administrator | Full tenant access, user management and the admin console. |
| Advanced | All assessment modules, AI analysis, the agentic stack and exports. |
| Standard | Core frameworks and limited AI. No control testing, workpapers or agentic stack. |
| Subscriber | Login only. No product access. |
Workspace (assessment) roles
Section titled “Workspace (assessment) roles”Additive permissions scoped to a single assessment, layered on top of the tenant role:
| Role | Access within the assessment |
|---|---|
| Lead Assessor | Full read/write, can share and delete, can approve agents and export. |
| Contributor | Create and update records. Cannot delete or export. |
| Reviewer | Read access plus notes and comments. Cannot delete. |
| Viewer | Read-only. |
Platform roles
Section titled “Platform roles”For Gamut’s own operators, split for least privilege: Platform Ops Admin (tenant provisioning, billing, lifecycle) and Platform Support Admin (cross-tenant visibility and time-boxed support-access grants only, no provisioning, no billing).
Permission and entitlement: both must pass
Section titled “Permission and entitlement: both must pass”A role granting a permission is necessary but not always sufficient. Sensitive product capabilities are gated by both an RBAC permission and a plan entitlement. A tenant administrator is deliberately not exempt: administration authority never unlocks a capability the tenant has not purchased. So “can this user do X” is answered by two questions: does their role grant the permission, and does the plan include the feature.
Object ownership
Section titled “Object ownership”Independently of role, the owner of an object gets read and update on that object, for systems, risks, findings, evidence and agents. Ownership never escalates to delete or to audit-sensitive actions; it is a deliberately narrow grant so owners can maintain their own records without broad access.
Least privilege
Section titled “Least privilege”Assign the least privilege needed for someone to do their job. It is easier to grant more access later than to recover from over-sharing, and the additive workspace roles mean you can give someone broad read access at the tenant level and write access only on the assessments they work on.
Managing users
Section titled “Managing users”Administrators manage users from Administration → Users:
- Invite colleagues by email and assign a role. See Invite your team.
- Adjust roles as responsibilities change.
- Suspend a user to immediately revoke access. An inactive user fails every permission check, and suspension ends their active sessions.
Sessions
Section titled “Sessions”Administrators can review active sessions and revoke them individually, useful for offboarding or responding to a concern. Sessions also expire on their own over time.
Accountability
Section titled “Accountability”Granting or revoking a role is itself an audited action, and every state-changing action a user takes is written to the audit log, so access and activity remain accountable and reviewable.
Single sign-on
Section titled “Single sign-on”For organisations with an identity provider, SSO governs authentication (proving who someone is) while roles continue to govern authorisation (what they can do).
- Plans & entitlements: the second half of the access gate.
- Single sign-on: connect your identity provider.
- Audit log: the record of who did what.