---
title: Roles
description: "The organization roles and the project roles as the platform enforces them: what each may do, where each is set, and the points still being clarified."
---

Access has two levels. An **organization role** says what you may do with the organization itself: its members, its devices, its projects. A **project role** says what you may do inside one project: its models, benchmarks, deployments and licenses. Everyone holds exactly one organization role and one role per project they belong to.

## Organization roles

Set under **Settings**, then **Organization**. The invite dialog offers Admin and Member; ownership is transferred with **Make owner** in a member's row menu.

| Role | May do |
| --- | --- |
| **Owner** | Everything below, plus transfer ownership and delete the organization. The web application offers the deletion under **Settings**, then **Organization** (**Delete organization**, owner only; type the organization's name to confirm, and every member loses access at once); the CLI does not, because the deletion takes a signed-in session, which the CLI does not hold. An organization always has one owner. |
| **Admin** | Invite members (as Member), remove members, create projects, register, rename, tag and delete devices, open a terminal on a device, cancel anyone's benchmark, read the whole organization's activity. An admin cannot promote a Member to Admin; ask the owner. |
| **Member** | Work in the projects they belong to with their project role. A member sees the device list and a device's page but cannot register a device or open its terminal (`devices:exec`), and reads only their own rows of the activity view. |

There is no organization-level viewer. For a person who should only read, give them **Member** at the organization and **Viewer** in each project.

## Project roles

Set on the project's dashboard under **Members**, then **Manage Members**. A new member of the organization joins its default project as **Developer**; change it there.

| Role | May do |
| --- | --- |
| **Owner** | Everything below, plus delete the project. The last owner cannot be removed or demoted. |
| **Admin** | Add and remove project members, and issue, rotate and revoke the project's runtime licenses. |
| **Developer** | Register models, start benchmarks, cancel their own, create deployments, read results. |
| **Viewer** | Read models, benchmarks, results and deployments. Deploy, Stop, Reveal key and Issue are hidden or disabled. |

A project admin's rights hold inside that project only: an organization Member who is Admin of one project cannot invite organization members, and cannot manage another project they are only Developer in.

## What the words in the app's Roles table mean

The Roles table under **Settings**, then **Organization**, lists the platform's own role catalog, including `user`, `platform_admin` and `support_admin`. `platform_admin` and `support_admin` are the deployment's staff roles, never assigned to a customer account; `user` is the base every account holds. They are not choices for your team; the two tables above are.

## API keys and roles

A key carries a subset of its owner's capabilities and never more, so a key created by a Member reaches what that Member reaches. Changing who is a member, their role, or the organization's ownership takes a signed-in session whatever the key's scope. [Manage members and API keys](../how-to/manage-members-and-api-keys.md) has the rules.

## Being clarified

- Whether an organization Member may reveal a deployment's key. A Member could on the hosted platform in early October 2026, with no confirmation.
- Whether a project Viewer should see **Add Model** at all; the dialog it opened was a stale one.
- The Member's rights on a device's **Commands** tab, which no role check has exercised.

## Related pages

- [Organization and project](organization-and-project.mdx): the two containers the roles apply to.
- [Manage members and API keys](../how-to/manage-members-and-api-keys.md): the day-to-day operations.