Who can do what: roles and permissions

7 min read·Updated Sep 2026

Pick a role based on the work someone needs to do. An Owner runs the organisation. A Member works across the register and can make formal risk decisions. A Contributor writes and updates findings without those governance powers. An Auditor reads. A Restricted collaborator sees only observations an Owner has shared with them.

The permissions at a glance

This table describes the five roles you can assign to people. “Shared only” and “Edit grant only” apply to Restricted collaborators, whose access is set separately for each observation.

Actions available to each organisation role
ActionOwnerMemberContributorAuditorRestricted
View the full register and observation detailsYesYesYesYesShared only
Create observationsYesYesYesNoNo
Edit observations and mitigation progressYesYesYesNoEdit grant only
Reassess riskYesYesYesNoNo
Accept risk or delete observationsYesYesNoNoNo
Write comments and upload evidenceYesYesNoNoEdit grant only
Create or edit observation relationsYesYesYesNoNo
Use AI content featuresYesYesNoNoNo
Manage the organisation and teamYesNoNoNoNo

Reading comments, relations and evidence follows observation access. Restricted collaborators see a relation only when both observations are shared with them. Contributor can read all three and can create or edit relations, but cannot write comments or upload evidence. Auditor can read all three without changing them.

Which role should I choose?

Owner is for people who administer the organisation. Owners invite and remove people, change roles, manage settings and billing, control sharing, and have the full observation permission bundle. You can have several Owners, but the last Owner cannot be removed or demoted.

Member is for people doing the full day-to-day security work. Members can create and edit findings, add comments and evidence, use AI features, accept risk and delete observations. They cannot manage the organisation or read the audit event feed.

Contributor is for people who maintain findings but should not make formal risk decisions. They can create, edit, progress and reassess observations, and manage relations. They can read comments and evidence. They cannot accept risk, delete findings, add comments or evidence, use AI content features, or administer the team.

Auditor is for review. Auditors can read the register, observation details, comments, relations and evidence, but cannot create or change findings or collaboration content.

Restricted collaborator is for someone who needs access to specific findings. They start with an empty “Shared with me” list. An Owner grants read or edit access to each observation. They cannot browse the wider register, accept risk, delete, reassign responsibility, manage sharing, use AI or access the programmatic API and MCP tools.

How sharing one observation works

An Owner can choose No access, Can read or Can edit for a Restricted collaborator on an observation. A read grant opens the observation, its comments and evidence. An edit grant also allows ordinary content and scoring edits, mitigation progress, comments and evidence uploads.

An edit grant still does not allow formal risk acceptance, deletion, reassignment or sharing changes. Assigning someone as responsible for a finding does not grant access by itself. Removing a grant takes effect on subsequent requests; it cannot undo content the person already read or downloaded.

API and SIEM access

API tokens and OAuth grants can only narrow the permissions the underlying role already has. They cannot turn a Contributor into a Member or give a Restricted collaborator access to an unshared finding. Owner API tokens cannot be created; owner administration stays in the signed-in app.

The SIEM role is a special token role for reading the audit event feed. It cannot be assigned to a person, and the feed requires a SIEM token even though Owners hold the underlying audit permission. For setup details, see the SIEM integration guide.