> ## Documentation Index
> Fetch the complete documentation index at: https://www.oplane.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Roles & Permissions

> Understand Oplane's layered access model: organisation roles (Org Admin, Org Member), workspace membership, and inherited threat model permissions.

Oplane uses a layered access model. Permissions are determined by your organisation role and workspace membership, with threat model access inherited from the workspaces they belong to.

## Organisation Roles

Every user belongs to an organisation with one of these roles:

| Role       | Description                                                                                                                                                        |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Org Member | Standard organisation member. Can view the organisation, access analytics, and work within assigned workspaces.                                                    |
| Org Admin  | Organisation administrator. Can manage members, update org settings, manage personal access tokens, manage security rules, and access all non-personal workspaces. |

## What Each Role Can Do

| Action                        | Org Admin | Org Member |
| ----------------------------- | --------- | ---------- |
| View organisation             | ✓         | ✓          |
| View analytics                | ✓         | ✓          |
| Update org info               | ✓         | —          |
| Manage member roles           | ✓         | —          |
| Manage personal access tokens | ✓         | ✓          |
| Manage security rules         | ✓         | —          |
| Access all shared workspaces  | ✓         | —          |

## Workspace Access

Workspaces have their own access layer that determines who can view and modify the threat models within them.

### Workspace Types

| Type       | Description                                                   | Who Has Access                                                       |
| ---------- | ------------------------------------------------------------- | -------------------------------------------------------------------- |
| Personal   | Private workspace for individual use                          | Only the owner                                                       |
| Shared     | Team workspace belonging to an organisation                   | Owner, direct members, and org admins                                |
| Repository | Linked to a GitHub/GitLab repository for automated PR reviews | Same as shared — threat models are created automatically by PR scans |

### Access Types

Shared and repository workspaces have a configurable access type:

| Access Type        | Behaviour                                                   |
| ------------------ | ----------------------------------------------------------- |
| ACL Only (default) | Only users explicitly added to the workspace can access it. |
| Organisation-Wide  | All members of the organisation automatically have access.  |

## Workspace Permissions

Within a shared or repository workspace, permissions depend on your relationship to the workspace:

| Action                         | Org Admin | Owner | Member |
| ------------------------------ | --------- | ----- | ------ |
| View workspace & threat models | ✓         | ✓     | ✓      |
| Create & edit threat models    | ✓         | ✓     | ✓      |
| Update requirements            | ✓         | ✓     | ✓      |
| Add & remove members           | ✓         | ✓     | ✓      |
| Update workspace settings      | ✓         | ✓     | —      |
| Delete workspace               | ✓         | ✓     | —      |
| Transfer ownership             | ✓         | ✓     | —      |

## Threat Model Access

Access to threat models is inherited from workspaces. If you can access any workspace that contains a threat model, you can view and update it. Security requirements inherit access from their parent threat model.

<Note>
  A threat model can belong to multiple workspaces. A user only needs access to one of those workspaces to view and edit the threat model.
</Note>

## How Roles Are Assigned

* **Organisation role** — Set by an existing org admin via the organisation settings. New members join as Org Member by default.
* **Workspace membership** — Added by the workspace owner, an existing workspace member, or an org admin.
* **Workspace ownership** — The user who creates the workspace becomes its owner. Ownership can be transferred by the current owner or an org admin.

<Card title="Workspaces" icon="folder" href="/workspaces">
  Learn about creating and configuring workspaces.
</Card>