Members

The Members screen (/members) administers who belongs to the organization and with which role. Every route requires org.member:manage, so it is available to Admins and Owners.

Membership mutations are privileged and infrequent, so the endpoints carry a tighter rate limit (30 requests/minute) than the API default.

Assigning an organization role

Each member holds exactly one organization-scope role: Owner, Admin, Member, or Viewer. Assigning is idempotent — it replaces any existing binding rather than stacking.

For what each role grants, see Roles and permissions.

The assignment goes through two guards, and both return an error rather than doing something surprising:

Owner-last. The organization must never be left without an Owner. Demoting or removing its only Owner is refused, which is what stops an accidental lock-out.
No self-escalation. You cannot grant a role above your own level, and you cannot touch a member who already outranks you. An Admin can manage Members and Viewers; only an Owner can create another Owner.

A role change flushes that user’s cached permissions immediately, so it takes effect on their very next request rather than after a cache window.

Removing a member

Removing a member drops their organization binding and their membership. It does not delete their sign-in account — that is a platform-level operation under Users. The owner-last and outranking guards apply here too.

Workspace roles

Enterprise feature. Requires the workspace-scoped-RBAC feature.

When workspace-scoped RBAC is enabled, the screen also shows each member’s per-workspace roles, read from every binding in the organization, and lets you assign or remove a role on a specific workspace.

A workspace binding replaces the organization baseline for agents in that workspace — it grants what the org role lacks and revokes what it grants. See Workspaces.

Audit

Organization and workspace role assignments and removals are recorded in the authorization audit with the acting operator, the target user, and — for a workspace binding — the workspace.

Adding people

There are two paths, and which one you use depends on the deployment:

Invitations (enterprise) — send a token link; the holder creates their own account and lands in the organization with the role you chose.
Users (platform) — a platform superadmin creates the sign-in account directly and hands over a temporary password out of band.