Roles — who may do what
Three roles. An unknown role is treated as the least privileged one, deliberately: a new role must be granted reach explicitly, never inherit it.
| Role | Shown as | Reach |
|---|---|---|
| member | — (the default; no badge) | their own workspace |
| tenant administrator | “Tenant admin (tenant_admin)” | everyone in one tenant |
| deployment administrator | “super_admin (whole deployment)” | every tenant, and the host |
A tenant administrator is usually also a working member, and the two hats are entered from different places: personal work from Settings, the team from Tenant settings. Only a deployment administrator sees the shield-icon Admin item.
What each may do
Section titled “What each may do”| member | tenant admin | deployment admin | |
|---|---|---|---|
| Own sessions, repositories and files | ✓ | ✓ | ✓ |
| Own connections and settings | ✓ | ✓ | ✓ |
| See every session in the tenant | — | ✓ | ✓ |
| Force-stop another member’s workspace | — | ✓ | ✓ |
| Rotate another member’s internal git token | — | ✓ | ✓ |
| Add and remove members | — | ✓ | ✓ |
| Per-member session limits | — | ✓ | ✓ |
| Make a member’s home bigger; choose the machine a member’s workspace runs on | — | ✓ | ✓ |
| Choose which members may use the self-hosted engines (within what the tenant is allowed) | — | ✓ | ✓ |
| Switch the limit board on or off for the tenant | — | ✓ | ✓ |
| Tenant-wide limits, sizing and idle auto-stop | — | —¹ | ✓ |
| Register a sign-in method for the tenant | — | ✓² | ✓ |
| Approve a sign-in method | — | — | ✓ |
| Login rules (join mode, domains) | — | —¹ | ✓ |
| Restrict where members may connect from | — | ✓ | ✓ |
| Register the tenant’s integration app OAuth | — | ✓ | ✓ |
| Distribute integration servers to the team | — | ✓ | ✓ |
| Allow or block outside apps (MCP OAuth) and outside use of members’ memory, for the tenant | — | ✓ | ✓ |
| Set the team’s branch naming rules and the agent new members are pointed at | — | ✓ | ✓ |
| Read the audit log | — | ✓ | ✓ |
| Running time and cloud cost | — | ✓ | ✓ |
| Egress control, speech engine, shared dictionary, the MCP sign-in hosts, the development OIDC IdP switch, the deployment’s colour and label | — | — | ✓ |
Replace or force-stop slots on ecs-ec2, keys at rest (KMS), pausing an idle deployment |
— | — | ✓ |
| Allow a tenant the self-hosted engines (llm / image), take models in, API tokens | — | —³ | ✓ |
| Create tenants and grant admin rights | — | — | ✓ |
| Install, upgrade, back up, restore | — | — | ✓ |
| A shell on the host | — | — | ✓ |
¹ Visible, but read-only. The panel exists so an administrator can see why something was refused without having to ask.
² Registering is not enough: a deployment administrator approves it, and a later change (adding an organisation, changing how the same account is recognised) sends the row back for approval.
³ Taking models in can be granted to a tenant’s administrators by the deployment administrator (the ingest grant in the tenant’s limits); enabling a model, the engine modes, the use gate and the API tokens stay with the deployment administrator.
Adding administrators
Section titled “Adding administrators”Only a deployment administrator can make someone a tenant administrator.
- The deployment administrator presses Make an admin of this tenant under Permissions in the member detail, and Revoke admin to take it away again
- The rights they grant apply inside that tenant only; other tenants are not affected
- A tenant administrator adding people with “Add member” can add plain members (
member) only - A removed administrator who is added back returns as a plain member; only a deployment administrator can make them an administrator again
- Deployment administrators are set in the deployment’s configuration (
SUPER_ADMIN_EMAILS) and carry a star on the roster
Where a tenant administrator has to ask
Section titled “Where a tenant administrator has to ask”The split follows blast radius. Anything whose effect crosses tenants, or that could lock people out of the deployment, sits with the deployment administrator (creating tenants, granting rights, the login rules, approving a sign-in method, egress). Anything scoped to one team sits with its own administrator, including the whole offboarding sequence.
Backups, upgrades and host incident response are the deployment administrator’s too, and in most organisations that is the same person as IT or SRE.
Which documentation each role receives
Section titled “Which documentation each role receives”The same guide, whatever the role: every container receives member/, admin/, operate/ and ref/. The shelves are cut by reader so that each reader knows where to start, not to hide anything. A link inside the guide has to work for everyone who follows it.
The developer documentation (design notes, decision records, work journals) is shipped to nobody.