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

# Roles and permissions

> Organization roles (Owner, Admin, Member) — what each can do

Your **organization role** — Owner, Admin, or Member — scopes what you can do inside your organization.

Every action you take is checked against your role. If your role doesn't permit something, the control affecting it is hidden or disabled in the UI, and the request is refused.

## Organization roles

Each member of an organization holds exactly one role. To act in two organizations with different permissions, you need a separate membership in each.

| Role       | What they can do                                                                                                                                                                                                        |
| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Owner**  | Everything below, plus: assign the **Admin** role and remove any non-owner member. Each user can own only one organization.                                                                                             |
| **Admin**  | Connect executors and deploy, configure, upgrade, and delete nodes. Manage API keys. Configure notifications and labels. Invite **Members**, change a member's role to **Member**, and act on members (block, restore). |
| **Member** | Read-only access to everything in the organization: executors, nodes, metrics, logs, audit events, releases, labels, and notification settings.                                                                         |

Roles are ranked: **Owner > Admin > Member**. A higher role can do everything a lower one can.

### Who can manage whom

Member management lives on the **Members** page.

* **Owners** can invite Members and Admins, change any non-owner's role, and remove any non-owner member.
* **Admins** can invite Members and act on existing Members. They **cannot** grant the Admin role, change an Admin's role, or remove a member — those are owner-only.
* **No one** can change or remove an Owner through the UI. A user can own only one organization at a time.

The role picker and member actions you see are filtered to what your role allows, so the table above is also exactly what the UI offers you.

## How access is enforced

* **People** sign in through the browser; your session carries your organization role.
* **Executors** authenticate with an organization-scoped API key (prefixed `exc_`), created in the [Connect an executor](/docs/executors/connect-an-executor) flow. An API key can only sync executor state — it can't act as a person or read across organizations.
* **Tenant isolation.** Every read and write is scoped to your active organization. A request for data outside it returns nothing rather than leaking another org's rows.

## Related

* [Members and invitations](/docs/account/members-and-invitations) — invite, change roles, block, and remove members.
* [API keys](/docs/executors/api-keys) — create and rotate the keys executors use.
* [Organization](/docs/account/organization) — settings and switching the active org.