Roles and permissions
Last updated September 15, 2026
What the organization-level and workspace-level roles can each do, and the three fixed rules that prevent permission deadlock.
Permissions come in two layers: organization level decides who manages the company's money and people, workspace level decides what can be done inside a particular workspace. Neither implies the other — an organization finance role has no calling rights in any workspace, and a workspace admin cannot see organization invoices.
Organization roles
| Role | Can | Explicitly cannot |
|---|---|---|
| Owner | Add credit, create and close workspaces, invite members, assign admins and finance, view organization-wide usage and audit records, transfer and close the organization | —— |
| Admin | The same, except cannot act on peers (see the fixed rules below) | Cannot change another admin's role, cannot promote anyone to admin |
| Finance | Add credit, view invoices, receipts, and usage amounts, view audit records | Cannot view call logs or prompt content, cannot view the member list, cannot manage workspaces |
| Member | Only denotes "belongs to this organization" | Cannot enter the organization console, cannot create workspaces |
Finance is a separate role, meant to cover funding and reconciliation without exposing call logs or prompt content.
Organization membership alone grants no workspace access. A member's actual work happens inside a specific workspace, which is why inviting an ordinary member requires naming one.
In the interface, "owner" and "admin" occupy the same tier in the data; the distinction is that the owner created or was transferred the organization, holds the exclusive ability to transfer it, close it, and assign admins, and cannot be removed.
Workspace roles
| Role | Can |
|---|---|
| Admin | Manage all keys in the workspace, invite and remove its members, set member spend limits, view all its usage and logs |
| Member | Create their own keys, see only the keys they created, see only their own usage and logs |
Keys record their creator, which is what allows a member's visibility to be scoped to their own keys. Legacy keys with no recorded owner are visible to workspace admins only.
Organization owners and admins hold admin-level authority in every workspace under the organization.
Three fixed rules
These apply at both the organization and workspace level, and exist to prevent permission deadlock and circular grants:
- You cannot modify or remove yourself. Changing your own role, or removing yourself from the member list, is rejected. Use "leave organization" instead.
- Admins cannot act on admins. Demotion, removal, and promotion to admin are reserved to the owner.
- Inviting an admin is likewise reserved to the owner. Otherwise "admins cannot create admins" would have a bypass: the role could not be changed, but someone could be invited straight in as an admin.
Rules two and three together guarantee that "who manages this organization" always has a final arbiter. If any admin could pull in a peer, A could add B and B could add C, while each could in turn demote the one before.
Visibility by page
| Page | Org owner / admin | Org finance | Workspace admin | Workspace member |
|---|---|---|---|---|
| Organization console | Full access | "Analytics" group only | —— | —— |
| Workspaces, members, org settings | Manage | Not visible | Own workspace's members only | Not visible |
| Invoices, receipts, top-ups | Manage | Manage | Not visible | Not visible |
| Usage and cost | Organization-wide | Organization-wide amounts | All of own workspace | Own only |
| Call logs and prompts | Organization-wide | Not visible | All of own workspace | Own only |
| API keys | All | Not visible | All of own workspace | Only those they created |
| Audit records | Visible | Visible | —— | —— |
Related
- Accounts, organizations, and workspaces — invitation rules and member spend limits
- API keys — key ownership and management boundaries