Role capabilities

A matrix of what each role may do on each resource.

Capability matrix

Roles are ordered, so each includes everything below it. ✓ means permitted, - means refused.

Secrets

Action	viewer	developer	admin	owner
List secrets and metadata	✓	✓	✓	✓
Inject a secret into a process	-	✓	✓	✓
Reveal a secret value	-	✓	✓	✓
Create and update secrets	-	✓	✓	✓
Restore a previous version	-	✓	✓	✓
Delete a secret	-	-	✓	✓
Create and update groups	-	✓	✓	✓
Delete a group	-	-	✓	✓

Infrastructure

Action	viewer	developer	admin	owner
List targets and metadata	✓	✓	✓	✓
Open an SSH session	-	✓	✓	✓
Run a command over SSH	-	✓	✓	✓
Obtain database credentials	-	✓	✓	✓
Inject AWS credentials	-	✓	✓	✓
Obtain a kubeconfig	-	✓	✓	✓
Enter an infrastructure profile	-	✓	✓	✓
Register or update a target	-	-	✓	✓
Change an SSH security policy	-	-	✓	✓
Delete a target	-	-	✓	✓
Create or delete a profile	-	-	✓	✓

Runbooks and access

Action	viewer	developer	admin	owner
List and read runbooks	✓	✓	✓	✓
Execute a runbook	-	✓	✓	✓
Create, update, delete a runbook	-	-	✓	✓
Require approval on a runbook	-	-	✓	✓
Approve an execution	-	-	✓	✓
Request temporary access	✓	✓	✓	✓
Approve or deny a request	-	-	✓	✓

Workspace

Action	viewer	developer	admin	owner
See members	✓	✓	✓	✓
Create a project	-	-	✓	✓
Delete a project	-	-	✓	✓
Invite and remove members	-	-	✓	✓
Change a member's role	-	-	✓	✓
Read the audit log	-	-	✓	✓
Manage own tokens and devices	✓	✓	✓	✓
Change the subscription	-	-	-	✓
Delete the workspace	-	-	-	✓

Per-project overrides

The matrix above describes the effective role on a given project. A member's workspace role is their default; a per-project membership replaces it for that project alone, and can lower as well as raise.

Workspace role	Project override	Effective
developer	none	developer
developer	viewer	viewer - read-only on this project
viewer	developer	developer - elevated on this project
admin	viewer	viewer - a deliberately restricted project

An approved, unexpired access request raises the effective role for its project until it expires, and then does not.

Interaction with token abilities

A token's abilities narrow the result. They never widen it.

Role	Token ability	Outcome
developer	`secrets:reveal`	Reveal permitted.
developer	no `secrets:reveal`	Reveal refused; injection still works.
viewer	`secrets:reveal`	Reveal refused. The role decides, not the token.
admin	no `audit:read`	Audit refused through the API; the console still works, since that is a session rather than a token.

Interaction with plan gates

Plan gates run last, so a permitted action on an unentitled plan returns a paywall rather than a permission error. The distinction matters when you are debugging: 403 means the role is wrong, 402 means the plan is.

Capability	Requires
Reading the audit log	admin and the Team plan
Inviting members	admin and the Team plan and a free seat
Restoring a version	developer and the Pro plan
Access request workflow	the Team plan

Something here wrong or missing? Tell us.