Roles & Permissions

Odin uses a four-tier role hierarchy to control access within your organisation. Each role inherits the permissions of the roles below it, so a higher role can always do everything a lower role can.

​

Role overview

Owner and Admin have the same access to almost every part of the platform. The difference is who they can manage: an Admin cannot act on another Admin or on an Owner.

​

Permissions matrix

​

Step-up verification

A few actions ask you to confirm your identity again before they go through, even though you are already signed in: inviting, editing, or removing a team member, buying or releasing seats, changing the finding-ID prefix, changing organisation settings, and editing your own profile. See Step-up verification for what the prompt looks like.

​

Role details

​

Owner

Owners have unrestricted access. No one inside Odin can change an Owner’s role or remove them, not even another Owner, so handing the role over means promoting the incoming person to Owner and then asking us to remove the outgoing one. When to use: the person ultimately responsible for the organisation’s security programme, typically a founder, CISO, or security lead. Most organisations need only one or two Owners.

​

Admin

Admins look after the organisation itself: who is in it, what it pays for, and how it is configured. When to use: team managers or senior engineers who need to invite people, manage seats and billing, or set up integrations, single sign-on, and API keys. Cannot do:

• Change or remove another Admin, or any Owner
• Promote anyone to Admin or Owner

​

Member

Members have full day-to-day access to security data. They manage assets, update finding statuses, create issues in connected trackers, email themselves reports, configure workflows, and launch scans. When to use: anyone actively working with security data, such as analysts triaging findings or engineers managing the attack surface. Cannot do:

• Invite, edit, or remove team members
• Change anyone’s role
• Reach billing, seats, API keys, single sign-on, or verified domains
• Change organisation-wide settings

​

Read only

Read only users see everything the organisation has access to and can take part in finding discussions, but they cannot change any security data. When to use: people who need visibility without making changes, such as executives reviewing posture, auditors, or compliance officers. Cannot do:

• Create, edit, or delete assets
• Update finding statuses or assign findings
• Create tracker issues or email report links
• Manage integrations, workflows, or scans
• Anything under team, billing, or organisation settings

Read only users can still edit their own profile and manage their own sign-in methods.

​

Who can manage whom

Managing another member, whether that means inviting them, changing their role, or removing them, requires the Admin or Owner role. Within that, you can only act on someone whose role sits strictly below your own, and you can only assign roles below your own:

• Owner can manage Admins, Members, and Read only users
• Admin can manage Members and Read only users
• Member and Read only cannot manage anyone
• No one can manage an Owner, and no one can change their own role

This prevents privilege escalation: nobody can grant a role equal to or higher than their own.