Admin authorization in 2.0.1 is enforced as a permission path + action code pair. Controllers declare the pair they require, and signed-in members receive access through their assigned roles.
Examples from the runtime
| Protected operation | Required pair |
|---|---|
| view Database Management | /runtime/db-management → view |
| create Database Management entry | /runtime/db-management → create |
| edit semantic metadata | /runtime/db-management/semantic → edit |
| issue/manage MCP keys | /runtime/mcp-keys with the relevant action |
| view users | /auth/user → view |
| edit roles | /auth/role → edit |
| view audit | /runtime/audit → view |
| export audit | /runtime/audit → export |
| edit security policy | /runtime/security → edit |
| retry an outbound delivery | /runtime/operability → edit |
Authentication alone is therefore not sufficient for these operations: the required path/action pair must also resolve through the member’s roles.
Permission-action templates are authoritative
The Role API exposes a permission-action-templates inventory. Each template contains:
- a permission ID, name, and path; and
- an action ID, code, and name.
A role payload submits selections as { PermissionId, ActionId } pairs. The role service normalizes duplicates and stores only pairs that exist in the template inventory.
Roles are the assignment unit
Members are assigned roles, and roles contain permission/action selections. This separates user lifecycle from reusable access policy:
Member
└─ Role(s)
└─ Permission path + ActionA member may have multiple roles. Effective Admin access is the combined permission surface of those assigned roles.
Authorization changes invalidate stale state
Role edits are security-sensitive. When a role’s permissions change, the role service finds affected members, increments their security version, and executes the change through the auth runtime-state cache barrier.
This is intended to prevent a previously authenticated session from keeping stale authorization after its role definition changes.
Protected SuperUser role
SuperUser is a built-in protected role in 2.0.1. It cannot be edited or deleted through normal role management. This ensures the bootstrap/full-control role cannot be silently redefined into a different permission set.
Related guides
- Members & Roles — member lifecycle and role guardrails.
- Database Management — DB and semantic permission examples.
- MCP Keys — MCP credentials are a separate authorization boundary from Admin roles.
- Security Policies — runtime SQL/rate/concurrency policy managed through its own Admin permission.