Understanding roles and permissions (RBAC)
G8KEPR uses role-based access control (RBAC) to decide who on your team can see and change what. Every member is assigned a role, and each role grants a specific set of granular permissions.
The six built-in roles
Every organization comes with six ready-to-use roles:
- ▸Owner — Full access to everything, including billing and deleting the organization.
- ▸Admin — Full access to everything *except* billing and organization deletion.
- ▸Security Analyst — Threat detection, audit, and compliance (read and write).
- ▸Developer — API key management, the AI Gateway, and MCP configuration.
- ▸Auditor — Read-only access to compliance data, audit logs, and reports.
- ▸Read-Only — Dashboard viewing only, with no ability to make changes.
When you create an organization, you are automatically assigned the Owner role.
How permissions work
Roles are built from a set of granular permissions. Each permission follows a resource:action pattern, so you always know exactly what it covers:
organization:billing
threats:read
gateway:configure
mcp:approve
audit:exportThe Owner role holds every permission. The Admin role holds every permission except organization:billing and organization:delete — which is why only an Owner can change your plan or remove the organization.
Permissions are designed to be checked when a member takes an action that changes data, not just at login. A user without the right permission receives a clear "not authorized" response.
Creating a custom role
If the built-in roles do not fit a team, an Owner or Admin can build a custom role with any combination of permissions:
- 1.Go to Settings → Members & Roles.
- 2.Select Roles, then Create role.
- 3.Name the role and choose the exact permissions it should grant.
- 4.Save, then assign the role to any member.
Custom roles are scoped to your organization only and never affect other tenants.
Built-in safeguards
G8KEPR layers two protections on top of standard RBAC:
- ▸Separation of duties — Certain permission pairs can be configured so they are not held by the same person (for example, requesting and approving billing changes), which helps prevent self-approval.
- ▸Escalation detection — If a request tries to use more access than a member's role should allow, it can be surfaced in your security event stream.
Follow least privilege: start people on the narrowest role that lets them do their job, then add permissions as needed.
Related: Managing API keys and Setting up SSO and SAML.