Roles & Permissions

Documentation Index

Fetch the complete documentation index at: https://docs.borghq.io/llms.txt

Use this file to discover all available pages before exploring further.

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

​

Permissions matrix

​

Role details

​

Owner

Owners have unrestricted access to the entire organisation. This is the only role that can manage Admins, transfer ownership, and delete the organisation. When to use: Assign Owner to 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. Cannot do: Nothing is restricted. Owners have full access.

​

Admin

Admins can do everything except manage other Admins or Owners. They handle the operational side of the organisation: inviting team members, managing billing, and configuring integrations. When to use: Assign Admin to team managers or senior engineers who need to onboard colleagues, manage subscriptions, or configure the platform, but who don’t need to manage other administrators. Cannot do:

• Change or remove an Admin or Owner
• Delete the organisation
• Transfer ownership

​

Member

Members have full day-to-day access to security data. They can manage assets, update finding statuses, create issues in integrated tools, send reports, configure workflows, and launch scans. When to use: Assign Member to anyone actively working with security data: security analysts, developers triaging findings, or engineers managing the attack surface. Cannot do:

• Invite, edit, or remove team members
• Change anyone’s role
• Access billing or subscription settings
• Create new organisations

​

Read Only

Read Only users can view all data in the organisation but cannot create, edit, or delete anything. When to use: Assign Read Only to stakeholders who need visibility without making changes: executives reviewing security posture, auditors, compliance officers, or external consultants. Cannot do:

• Create, edit, or delete assets
• Update finding statuses
• Create issues or send reports
• Manage integrations, workflows, or scans
• Any action that modifies data

​

Role hierarchy

Roles follow a strict hierarchy. A user can only manage (invite, edit role, or remove) members with a role below their own:

• Owner can manage Admins, Members, and Read Only users
• Admin can manage Members and Read Only users
• Member can manage Read Only users
• Read Only cannot manage anyone

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