RBAC roles

Permissions are fine‑grained and colon‑style (e.g. mcp_server.register, policy.publish, audit.read). Roles bundle those permissions and are granted through role bindings scoped to a tenant, environment, owner‑team, or specific resource.

Built-in roles

Role	Purpose
security_admin	Full security control — identity, policy, credentials, emergency controls.
platform_admin	Full platform control — deployment, connectors, data planes, operations.
registry_reviewer	Review and approve MCP server / API source submissions.
server_owner	Own and manage specific servers (scoped to owned resources).
policy_admin	Author, validate, publish, and archive policies.
credential_admin	Manage credential bindings — create, rotate, disable, revoke.
auditor	Read‑only access to the audit trail and exports.
viewer	Read‑only access to governed objects.
break_glass_admin	Emergency override — revoke and emergency‑disable.

Role bindings

A binding grants a role to a subject (user, group, or service account) within a scope. Bindings can be previewed before they take effect and disabled without deletion.

• List / create: GET / POST /v1/admin/role-bindings
• Preview: POST /v1/admin/role-bindings/preview
• Disable: POST /v1/admin/role-bindings/{binding_id}/disable

DB-backed control planes ignore header roles

When the control plane is backed by a database, identity‑header roles are not trusted — access is governed entirely by stored role bindings. If every request 403s on a fresh deployment, seed an initial binding (or bootstrap an admin) first.

Note

There is no dedicated gatewayctl verb for role bindings yet — manage them through the UI or the /v1/admin/role-bindings API.