Roles & permissions
Workspace roles control what a member can see and do in the cabinet and via the REST API. They do not, on their own, control what the agent will execute on a machine — that is the job of the agent permission gate.
Cabinet roles only restrict the cabinet UI and REST. Agent-side permissions (the rule grammar in permissions) restrict what gets executed on the receiver. Both layers run; both must allow.
Built-in roles
| Role | Workspace settings | Billing | Members | Machines | Sessions | Schedules | Audit |
|---|---|---|---|---|---|---|---|
| Owner | Edit | Edit | Edit | Edit | View | Edit | View |
| Admin | Edit | View | Edit | Edit | View | Edit | View |
| Member | View | — | View | View | View own | View own | View own |
| Viewer | View | — | View | View | View | View | View |
Owners are the only role that can change billing or delete the workspace. There must always be at least one Owner.
Per-machine access levels
On top of the role, individual machines can carry a per-member override:
- Full Access — the default for Owners, Admins, and granted Members. Read everything, drive sessions (subject to the agent gate).
- Execute Only — can run commands but cannot read transcripts of others’ sessions.
- View Only — read-only across the board: machine metadata, transcripts, file paths. No command execution, no file write.
What “View Only” means in practice
A View-Only member sees:
- Machine inventory and health.
- Session transcripts (already-recorded output).
- File paths in the file manager (not file contents for protected paths).
A View-Only member cannot:
- Open a new shell or send keystrokes.
- Trigger schedules.
- Issue API tokens.
- Edit machine metadata.
Workspace-level policies
In addition to roles, the workspace settings page exposes broader policies:
- Require 2FA for all members.
- IP allowlist for cabinet and REST.
- Session timeout for the cabinet UI.
- Default permission mode (
default,strict, orbypass) for newly registered machines.
See Workspace settings for how to configure these.
Cabinet roles vs the agent gate
The two layers complement each other:
- Cabinet role decides whether you can even see a machine in the UI / REST.
- Agent gate decides whether the agent on that machine will run a given tool when you ask it to.
A View-Only member can technically craft a cmdop connect exec call — but the agent’s permissions.yaml (with mode default or strict) will deny it on the receiver side. Belt and suspenders.
Where this data lives
Roles live in the Django workspaces app (role model). Per-machine access overrides live in the same app, keyed by (workspace, member, machine).
Related
- Members
- Workspace settings
- Concepts: permissions — the agent gate.
- Guides: agent permissions — how to write rules.