Roles and permissions
Workspace roles, ranked permissions, and organization and workspace membership boundaries.
Every workspace membership has exactly one role: Viewer, Member, Admin, or Owner. Roles are rank-based: a higher role includes the permissions of the ones below it.
Role matrix
Enterprise environment checks use this rank (enterpriseRoleCan / workspaceRoleCan):
| Role | Rank | read | execute | write | promote | manage-secrets |
|---|---|---|---|---|---|---|
| Viewer | 0 | Yes | No | No | No | No |
| Member | 1 | Yes | Yes | No | No | No |
| Admin | 2 | Yes | Yes | Yes | Yes | No |
| Owner | 3 | Yes | Yes | Yes | Yes | Yes |
write and promote share rank 2. manage-secrets is Owner-only.
Typical product gates that use the same ranks:
| Action | Minimum role |
|---|---|
| Read workspace resources, list members, GET git repository, GET agent rollout | Membership (any role) |
| Discover assignable organization members or assign workspace access | Workspace Admin or Owner |
Run workflows (execute) | Member |
| Assign a workspace member via session or v1 members API | Admin |
Create or revoke API keys (session /api/api-keys) | Admin |
| PATCH/DELETE git review repository | Admin |
| PATCH agent-runtime rollout | Admin |
| Configure enterprise SSO (plus org owner/admin) | Admin |
| Prepare, publish, promote or stop a workflow destination | Member with write and execution access; publication also requires exact AIMS approval |
| Execute a single deployed step with real effects | Admin or Owner with execution access and recent MFA |
| Manage external secret providers and 1Password credential grants | Owner (manage-secrets) |
| Observability retention POST | Owner |
Checks compare the actor's role rank to the minimum allowed role. Passing ["Admin", "Owner"]
means Admin or higher.
Approvals in the main navigation uses effective AIMS assignments. A workspace Owner is not automatically an AIMS System Owner, Manager or Reviewer. Organization Owners may configure the organization approval policy; the independent and Owner-authorized paths retain their assignment and separation rules. Viewers can inspect permitted workflow metadata but cannot edit, simulate, publish or operate destination switches. See AI governance.
How you become Owner
Invite APIs reject owner. Stored invite roles are admin | member | viewer.
You become Owner only when:
- Platform bootstrap writes org + workspace membership
owner(FLUXUS_BOOTSTRAP_OWNER_*). - Google provisioning creates your personal org/workspace as
owner. - A platform-managed membership explicitly assigns that role.
Creating a workspace yourself makes you its Owner.
Organization and workspace membership are separate. An organization Owner or Admin first invites someone to the organization. After acceptance, a workspace Owner or Admin explicitly assigns that person a workspace role. Organization role changes do not overwrite explicit workspace roles.
Invitation permission split
Workspace access assignment requires an existing organization membership:
- tRPC
workspaceShell.workspaceMembers.assignablesearches and paginates eligible members; only a workspace Admin or Owner can use it. - tRPC
workspaceShell.workspaceMembers.inviteassigns the selected existing organization member; only a workspace Admin or Owner can use it. It does not send an invitation. - v1
POST /api/v1/workspace-membersassigns an existing organization member and requires a workspace-scoped API key owned by an Admin or Owner.
Invite external people from the Organization page first. An unaccepted organization invitation cannot be assigned to a workspace.
Only an organization Owner or Admin can cancel a pending organization invitation in that organization. Confirm Cancel invitation beside the invited email on the Organization page. Cancellation invalidates the emailed link and also clears invitations whose link already expired; it cannot remove an accepted member.
Unknown invite roles do not silently become Viewer at the HTTP/tRPC boundary. They throw
Member role must be admin, member, or viewer. Viewer is the fallback only inside
normalizeWorkspaceMembershipRole inside workspace membership persistence.
Scope boundaries
- Workspace: isolation unit for resources, members, and API keys.
- Organization: membership, billing and identity container; SSO/SCIM; optional projects.
- API key: always bound to one workspace. The key is valid only while the owning user is not banned and still has both workspace and organization membership.
- Session: may switch among workspaces the user belongs to; cannot act on others (
403).
More structure: Organizations and workspaces. Enterprise gates: Enterprise. Settings map: Workspace settings.