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

Roles exist at three scopes, and a user’s effective access is the combination.

Tenant roles

What a user can do across the organisation:

Role	Access
Administrator	Full tenant access, user management and the admin console.
Runtime Policy Approver	Approval-only access to inspect and decide submitted Runtime Access Policies in explicitly assigned workspaces.
Advanced	Advanced-tier frameworks, AI analysis, Agentic CISO, simulation and exports; Enterprise runtime and licensed ISO access remain separately gated.
Standard	Core frameworks, bounded AI and workpaper/report capabilities. No control testing, AI Consultant or agentic stack.
Subscriber	Login only. No product access.

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.
Runtime Policy Approver	Read supporting agentic context and approve or reject submitted Runtime Access Policies only.
Contributor	Create and update records. Cannot delete or export.
Reviewer	Read access plus notes and comments. Cannot delete.
Viewer	Read-only.

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

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

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.

Runtime Policy Approver

Runtime policy decisions can change the authority exercised by AI agents. Gamut therefore provides a dedicated Runtime Policy Approver rather than requiring reviewers to hold an administrator role.

When creating an approver account, the administrator selects the exact workspace the person may review. Additional workspace assignments must be granted explicitly. A policy is visible only when it belongs to an active, assigned workspace.

The role can:

• inspect submitted Runtime Access Policies and relevant supporting context;
• use the pending-approval inbox;
• approve and publish a pending policy;
• reject a pending policy with a recorded reason.

The role cannot:

• draft, edit, delete or submit a policy;
• suspend or revoke active authority;
• create or change agents, tools, connections, approval gates or data flows;
• manage users, roles, workspaces or tenant settings;
• operate Gateway or bypass plan entitlements.

The restriction is enforced behind the interface as well as in it. Account-security actions such as changing the approver’s own password and enrolling MFA remain available.

Both approval and rejection require the approver’s password and current MFA code through a short-lived step-up verification. The person who created or submitted the policy cannot approve that version. Every assignment and decision is audited.

See Runtime Access Policies for the review checklist and policy lifecycle.

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.
• Assign approvers to the exact workspace containing the policies they may review.
• Suspend a user to immediately revoke access. An inactive user fails every permission check, and suspension ends their active sessions.

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.

Privileged controls and break-glass

The admin console holds the most sensitive controls, behind both a permission gate and a step-up re-authentication. They include the runtime break-glass switches:

• Disable Gateway Runtime (the Gateway kill switch): blocks every agent action across the tenant, fail-closed, until reactivated. See Gateway.
• Suspend Agent Runtime: halts a single agent’s actions until it is reactivated.
• Gateway approval review, connector and integration configuration.

Every one of these is audited. They are deliberately kept out of the normal app and behind step-up so a break-glass action is always a deliberate, attributable decision.

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

For organisations with an identity provider, SSO governs authentication (proving who someone is) while roles continue to govern authorisation (what they can do).

Next

• Plans & entitlements: the second half of the access gate.
• Single sign-on: connect your identity provider.
• Audit log: the record of who did what.