Identity & access
Managing organization custom roles and permission gates
Four default roles cover most organizations. Enterprise plans add custom roles assembled from permission groups. Either way the check runs on the server against the caller's real membership — never against a role the client claimed.
Open Custom roles in the consoleDefault roles and custom roles
Four default organization roles cover most teams. Enterprise plans add custom roles, assembled from permission groups rather than written from scratch, so a custom role is a named set of existing capabilities.
Where the check actually runs
Where Internal Platform Ops sits
Before reaching for a custom role, check whether the capability you want even belongs to this role system. Organization impersonation, billing override and secrets rotation are not a higher customer role — they live in a physically separate internal application.
Building a custom role
Custom roles are an Enterprise capability and are assembled from permission groups rather than written from scratch. A custom role is therefore a named selection of capabilities that already exist, which is what keeps the authorization checks themselves unchanged.
- Compose from permission groups; do not expect to define a brand-new capability as part of making a role.
- The check still resolves server-side against the caller's real membership in the organization the operation names.
- A role supplied by the client is never consulted, and a hidden button is not an authorization control.
Put it into practice
Run a fleet with these guardrails on from day one.
Hard cost caps, one audited gateway in front of every tool call, and versioned rule files — the defaults, not an enterprise add-on.