Authorization and RBAC

Authentication proves who is calling. Authorization decides what they may do. XKOVA has one authorization control plane: every mutation is checked against a single permission registry, and a role is just a named bundle of permissions resolved per request.

How a request is authorized

A principal, either a staff session or an API key, carries one or more roles. At request time the platform resolves those roles to a permission set and checks the permission the route requires. There is no hand-rolled role check anywhere; the same registry backs every mutation, every governed action, and every audit row.

• owner and admin are wildcards: they hold every non-platform permission.
• Other built-in roles are explicit bundles scoped to a domain.
• A tenant may define custom roles, bounded by anti-escalation: you can only grant a role whose permissions you already hold.

Built-in roles

Role	Authority
owner	Full tenant authority. Required to arm break-glass.
admin	Full tenant authority, not the literal owner. May opt out of a domain (for example no treasury).
compliance_officer	Compliance and verification oversight. Reads the approval trail but cannot attest.
customer_service	Read payments and escrows, manage contacts, place and release holds.
treasury_admin	Full treasury authority over vaults, signers, thresholds, and transfers.
treasury_signer	Treasury reads plus transfer draft, approve, and execute.
treasury_viewer	Read-only treasury.
tokenize_admin	Full digital-asset and real-world-asset authority: deploy, mint, burn, schemas, distributions.
tokenize_minter	Token read plus mint only.

The permissions group into domains: treasury and money, identity and keys and governance, firewall and compliance and config, tenant and branding and reporting, and digital assets. For the complete role model and the generated permission catalog, see Roles and Permissions.

Tenant scope

An API key carries a scope as well as roles. Every integrator credential is tenant scope: it acts within the single tenant the key is bound to, and that tenant is fixed by the key. A typical caller is an integrator backend acting for its own institution.

There is also an internal platform scope that sits above tenants. It is used only by XKOVA platform operations and is not a surface integrators call.

Separation of duties and quorum

High-blast actions are gated by an approval quorum rather than a single permission. The request creator is recorded and cannot self-approve whenever the approval clause can be satisfied without them. Break-glass is the only bypass: two-of-two to arm, time-boxed, with every action under it tagged and audited at high severity. See Policies and Quorum Governance for the governance model and Audit Log for what each authorized action records.

Related

See Authentication for how a credential proves itself, Roles and Permissions for the full catalog, and the Errors page for the role_denied response.