Roles - Aperium Docs

Aperium ships three system roles. Every role maps to a fixed set of capabilities defined in code, so the Roles tab under Settings › Workspace › Access is reference material only — a read-only matrix showing which capability each role grants. You don’t create or edit roles here; you assign them to users from Members or through Group mappings.

Role	Reach	What this person can do
Super Admin	Cross-tenant (platform operator)	Every capability, across all tenants. The authorization resolver short-circuits to allow for this role. Can switch the active tenant and manage tenants.
Tenant Admin	One tenant	The full administrative capability set — members, roles, group mappings, integrations, guardrails, agent/model/tool catalogs, sharing, audit — scoped to their own tenant. No cross-tenant reach.
Member	App-level only	Chat with agents, create and run agents, link and use integrations, manage their own preferences and memory. No admin surfaces.

The capability matrix

The tab renders every capability as a row (grouped by namespace, such as agent.*, integration.*, guardrail.*) with one column per role. A check means the role grants that capability; a dash means it doesn’t. It’s a faithful view of the role registry that ships in Aperium’s code.

Roles are additive and combine by union. A user who holds more than one role gets every capability any of their roles grants — there is no deny. Both Super Admin and Tenant Admin also bypass permission-group policy within their reach. Access is still bounded by the upstream system’s own permissions and by what each user can do there.

Custom roles

Tenant-custom roles are deferred — only the three system roles above exist today. Adding data-driven custom roles is a planned change, not something configurable in the UI now. Don’t design access around custom roles yet.

​The capability matrix

​Custom roles

The capability matrix

Custom roles