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. Owners cannot be added, edited, or removed from within Odin, by anyone, not even another Owner. To add, change, or remove an Owner, contact [email protected]. When to use: the person ultimately responsible for the organisation’s security programme, typically a founder, CISO, or security lead. The first Owner is set when the organisation is created.

​

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, set up integrations and single sign-on, or oversee everyone’s API keys. Cannot do:

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

​

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, and launch scans. They can also create up to 10 active API keys of their own, for example to connect a coding agent through the Odin MCP server. A key acts as the Member who created it. Their keys are revoked if they are removed from the organisation, and stop working while they are Read only. 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, single sign-on, or verified domains
• See or revoke other people’s API keys
• 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 or scans
• Create or use API keys
• Connect or use apps through OAuth sign-in
• 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.