Access control tiers

Velarum’s authorization model is built to be explainable, auditable, freezable, and recoverable — the minimum viable least-privilege loop, not the most elaborate one.

Default deny

The rule is deny by default, allow explicitly. Every authorization decision is made in the core backend (never the frontend or SDK), and funds-related writes additionally check subject identity, org/project ownership, the idempotency key, and policy status before proceeding.

Permission levels R0–R4

Operations are graded by risk: R0 public health checks, R1 read-only queries, R2 ordinary writes, R3 funds/policy writes, and R4 high-risk actions that require 2FA / second-person approval / cooldown. Higher tiers carry mandatory audit-log and event-bus writes.

The five RBAC roles

Enterprise members hold exactly one of five roles, plus an independent read_only flag: OrgAdmin (day-to-day org management), TreasuryAdmin (sovereign-withdrawal initiator, authorization lifecycle), SecurityAdmin (second approver, agent freeze, sub-key revoke), Finance (reports/audit read-only), and Developer (API keys, webhooks, agent metadata).

Separation of duties

TreasuryAdmin and SecurityAdmin are mutually exclusive on one account, so high-risk fund actions need two different people (SOX 405 / SOC 2 CC6.1):

What this means for you

Agent tokens and API keys are non-human principals with deliberately narrow scope — an AgentToken can read its own agent and create payments within policy, but can never touch sovereign withdrawals or cross-agent resources. Design your team so the person who initiates a withdrawal is never the person who approves it; the contract’s M-of-N and timelock enforce the rest, not Velarum.