Role → Console Access Matrix

Runs unlicensed

The six-role model below works with no license, in the Development posture — including SSO. A license adds the MCP and A2A planes, production rights and support.

DVARA ships six built-in roles, split into two scopes:

• Platform roles — owner, policy-admin, billing-admin. These render the platform Console at / and operate across all workspaces.
• Workspace roles — admin, developer, viewer. These render the workspace Portal at /portal and are scoped to a single workspace.

A user holds roles from exactly one scope — mixing a platform role with a workspace role on one account is rejected at creation. The role names below are the literal values that appear in your JWT / SAML / built-in claim — no aliasing.

This page is the access contract for the platform Console navigation. It is derived from the same URL-pattern rules the running app enforces, so a compliance reviewer can answer "what can a billing-admin actually see?" without standing up the app.

Legend

Mark	Meaning
✓	Visible in the navigation and fully reachable
◐	Visible and readable, but write actions are restricted to a higher role
—	Hidden from the navigation and blocked at the URL

Platform Console (/)

Workspace roles render the Portal, not this Console — see the workspace note below. The columns here are the three platform roles.

Destination	owner	policy-admin	billing-admin
Dashboard	✓	✓	✓
Playground	✓	—	—
Identity
Workspaces	✓	✓	✓
Users	✓	✓	—
Credentials	✓	✓	✓
Routing
Routes	✓	✓	✓
Cache	✓	—	—
Latency	✓	✓	—
Schemas	✓	✓	—
Governance
Policies	✓	✓	✓
Audit	✓	✓	✓
Webhooks	✓	✓	◐
Cost
Cost Dashboard	✓	✓	✓
Token Usage	✓	—	✓
Model Pricing	✓	✓	✓
Budget Caps	✓	✓	✓
Chargeback Reports	✓	✓	✓
Compliance Reports	✓	✓	✓
Prompts
Templates	✓	✓	✓
Experiments	✓	✓	✓
Golden Prompts	✓	✓	✓
Eval Prompts	✓	✓	✓
Eval Reports	✓	✓	✓
Agents
MCP Servers	✓	✓	✓
Tool Calls	✓	✓	✓
Sessions	✓	✓	✓
Approval Queue	✓	✓	✓
Analytics	✓	✓	✓
User menu
License	✓	✓	✓
My Access Tokens	✓	✓	✓
Import / Export	✓	—	—

The non-obvious cells

• owner-only: Cache, Import / Export, and Playground. The semantic cache may hold cross-workspace prompt/response pairs, Import overwrites live config, and Playground bills the workspace whose API key the operator pastes — all three are locked to the platform owner.
• Users excludes billing-admin. Cross-workspace user and role management is reachable by owner and policy-admin only (/users/** → hasAnyRole("owner", "policy-admin")). A billing-admin whose scope is pricing, budgets, and chargeback never sees the Users page.
• Token Usage excludes policy-admin. It is a FinOps lens (raw token counts behind the Cost dashboard), reachable by owner and billing-admin only — a policy-admin does not see it. The Portal shows a workspace only its own.
• Latency and Schemas exclude billing-admin. These are routing / structured-output operations surfaces with no FinOps relevance.
• Webhooks is read-only (◐) for billing-admin. They can view subscriptions and delivery logs (delivery cost is a FinOps concern) but cannot create, edit, test, or delete a webhook — those writes are owner + policy-admin.
• PII detokenize / purge (not a top-level nav item; reached from the data-protection surface) is owner + policy-admin, and the destructive purge is owner-only.

License and playground gating (independent of role)

Two gates apply on top of the role rules above:

• Enterprise license — the Cost and Prompts sections, and the Tool Calls / Sessions / Approval Queue / Analytics items, only appear when a valid enterprise license is active. Without one they are hidden regardless of role.
• Playground toggle — the Playground item only appears when dvara.flightdeck.playground.enabled=true (the default). Production deployments that set it false hide it for every role.

Workspace roles

admin, developer, and viewer never render this Console. After login they are redirected to the workspace Portal (/portal). The Portal RBAC follows the same shape — admin manages the workspace (including its team), developer creates API keys and credentials, viewer is read-only — all scoped to the caller's own workspace.

Two surfaces are shared across both shells for any authenticated user: My Access Tokens (/settings/tokens, personal access token management) and the workspace Portal itself.

How this stays accurate

The role gates above are kept equal to the Console subset of the URL-pattern RBAC the gateway enforces, so a change to one ships with a change to the other. For the authentication model (built-in, OIDC, SAML) and the IdP property reference, see Setup & Login.