Key concepts
Permission group
A permission group is a named bundle of permissions. OASM ships with three built-in groups — Owner, Admin, and Read only — and you can create custom groups for any recurring team role. Assigning a group to a member grants exactly the permissions the group contains.Viewing vs. changing
Every capability has two levels: viewing (seeing data) and changing (modifying it). A member who can change something can always view it as well — you never need to grant the view half of a pair explicitly. This keeps groups compact and prevents broken setups where someone can modify what they cannot see.All permissions
The Owner group holds every permission, current and future. Owners never lose access when new capabilities ship.Built-in permission groups
The Admin group covers the everyday management surface — workspace settings and configuration, the workspace API key, members, invitations, workflows, permission groups, and targets. The Read only group grants the minimum needed to see pending invitations and inspect assets.The Permissions screen
The Settings → Members page has three tabs; the Permissions tab is where groups live:1
Open Settings → Members
Navigate to the Members section of your workspace.
2
Open the Permissions tab
The tab lists existing permission groups with their assigned permissions.
3
Inspect a group
Select a group to open its detail page, where you can review or change its permissions.
Create a custom permission group
1
Open the Permissions tab
Navigate to Settings → Members → Permissions.
2
Click Create group
The Create group button opens the group editor.
3
Name the group
Give the group a name that matches the role it serves, such as “Vulnerability Analyst” or “Scan Operators”.
4
Select permissions
Choose the permissions the group grants. Remember: a member who can change something can also view it.
5
Save the group
Submit the form. The group is now available when assigning members or sending invitations.
Assign a group to a member
1
Open the Members tab
Navigate to Settings → Members → Members.
2
Find the member
The tab shows a table of Member and Permission columns, so you can see each member’s current group at a glance.
3
Change the permission
Use the member’s row menu to change their permission group. The new group takes effect for that member’s session immediately.
Invite a member with a group
1
Click Invite member
On the Members tab, the Invite member button opens the invitation form.
2
Enter email addresses
Provide the email address(es) of the people you want to invite.
3
Choose a permission group
Select the group the invitees should receive when they accept.
4
Send the invitation
Submit the form. The invitation appears under the Invitations tab with EMAIL, EXPIRES, STATUS, and PERMISSION GROUPS columns until it is accepted or expires.
Invitation management is itself permissioned. Creating, resending, and cancelling invitations requires the right permission — only members whose group allows it can do these actions.
Recommended permission matrix
How permissions are enforced
Permission groups are enforced for user sessions. When a member performs an action in the Console, the platform checks the action against the member’s group and denies it when the corresponding permission is missing. Because groups are evaluated per action, changing a member’s group takes effect immediately — you do not need to wait for a session to expire. Enforcement is not limited to UI actions. The same checks apply wherever the permission model is consulted, so a member cannot bypass a restriction through other channels. Automated access is a separate surface: the workspace API key is workspace-scoped with its own access model, so key-based callers are governed by that model rather than by member groups. Every permission-relevant action is recorded in the Audit log. Audit events capture the actor — a user, an API key, or an agent — which lets you trace exactly who (or what) changed a permission, invited a member, or modified a workspace.Owner is permanent authority. An Owner can delete the workspace, rotate the API key, and read or modify every resource — including permission groups themselves. Grant Owner membership only to the smallest set of trusted people, and audit the group regularly.
Best practices
- Start with least privilege. Assign the smallest group that lets a member do their job, and escalate only when a concrete need appears. The Read only group exists precisely for members who only need to monitor results.
- Escalate through groups, not ad hoc grants. If a member needs more access, create or assign a purpose-built group instead of granting individual permissions one by one — each extra permission expands what they can change.
- Reserve Owner for a minimal set. Owner covers every current and future permission. Keep Owner membership to a small, trusted set and use Admin for day-to-day administration.
- Audit access continuously. Permission changes, membership changes, and API activity are recorded in the Audit log. Review it regularly — audit events record the actor (a user, an API key, or an agent), so you can trace who changed what.
- Model roles as groups, not ad hoc grants. Recurring team roles should be custom groups with descriptive names, so the permission matrix stays reviewable.
- Separate user and API access. User access is governed by permission groups enforced on sessions; programmatic access uses the workspace API key, which is workspace-scoped with its own access model. Review both surfaces, not just member groups.
Related
Members
Invite members, manage invitations, and change permission groups
Users and roles
Understand platform-level roles such as admin, user, and bot
API keys
Manage the workspace API key and its access model
Audit log
Review who changed what, and with which actor