Workspaces & Users

Runs unlicensed

Available with no license, in the Development posture. A license adds the MCP and A2A planes, production rights and support — not this feature.

The DVARA Flightdeck combines two closely related surfaces: workspaces (the logical isolation unit for data, keys, and billing) and users (human operators with RBAC roles). Both live under the sidebar's Identity section.

Workspace management

Open Identity → Workspaces in the sidebar.

Workspace list

Displays every workspace with name, status badge (active / suspended), region, and creation date. Auto-refreshes every 10 seconds.

Figure 1. Workspaces list with status badges, region, and create-workspace button

Create / edit workspace

Click New Workspace to create a workspace. Click Edit on any row to update an existing workspace. The form is organized into four tabs:

• Basic — name, region, status (active / suspended), priority tier (standard / premium / bulk)
• PII & DLP — per-workspace overrides for pii.enabled, pii.action (BLOCK / REDACT / LOG), and pii.scan-responses
• Guardrails — per-workspace overrides for guardrail.enabled, guardrail.action (BLOCK / FLAG / LOG), guardrail.risk-score-threshold (0.0–1.0), guardrail.max-input-tokens, and guardrail.max-messages-per-request
• Built-in PII Filters — multi-select checkboxes for the 22 in-process embedded PII filter types in the default-enabled set: SSN, passport, drivers license, credit card, IBAN, bank routing, bitcoin, currency, phone, phone extension, email, IP, MAC, URL, street address, ZIP, state abbreviation, date, age, VIN, tracking, physician name. Leave all unchecked to inherit the gateway default (all 22 deterministic filters auto-enabled; 8 additional dictionary-based filters like first name / surname / city are off by default and only enabled when explicitly listed here). Requires dvara.llm-gateway.guardrail.embedded.enabled=true to take effect.

Form values are validated server-side: invalid actions, out-of-range thresholds, non-positive token caps, or unknown built-in filter names are rejected with a field-named error and no save. Blank fields clear the corresponding metadata key (revert to inherit default).

Updates are non-destructive: metadata keys not exposed in the form (e.g. approval.required-tools, agentic.loop-detection.*, cost.downgrade-rules) are preserved across edits. The same metadata can also be set through the Console's GitOps export/import for IaC pipelines.

Every save emits a WORKSPACE_CREATED (on create) or WORKSPACE_METADATA_UPDATED audit event with a diff ({key, old, new}) of every changed key. Deletes emit WORKSPACE_DELETED.

Figure 2. Create-workspace form

Managing the same metadata as code

For Terraform, CI/CD and other programmatic tooling, the same metadata is editable through the Console's GitOps export/import — export the config, edit the workspace's metadata object, and import it back.

The import reconciles by id, so a workspace present in the document is updated in place.

API key management

Click Keys on a workspace row to manage that workspace's API keys.

Figure 3. API key list for a workspace with seeded keys

• Key list — name, masked key prefix (gw_xxx…), scopes, status, expiry, and creation date. Auto-refreshes every 10 seconds.
• Create key — click New Key to open the modal. Pick a name, scopes (multi-select), and optional expiry. The full plaintext key is shown exactly once after creation with a copy button — it cannot be retrieved again.
• Revoke key — click Revoke on any active key. Requires confirmation. Revocation is immediate and irreversible; the key status flips to REVOKED and the cached entry is evicted on every gateway instance, so subsequent requests fail fast across the whole fleet.

Figure 4. Create-API-key modal with seeded canary-key name

Figure 5. One-time plaintext-key reveal banner after create

User & role management

Open Identity → Users in the sidebar (owner only).

User list

Lists every user with email, name, workspace, roles (as badges), status (ACTIVE / SUSPENDED / DEACTIVATED), last login, and creation date. Auto-refreshes every 10 seconds. Use the Workspace dropdown filter to narrow the list.

Figure 6. Users list with seeded developer and viewer

Create user

Click Invite User to open the invite form. In built-in-auth mode this sends an email with a password-setup link; in OIDC / SAML mode it creates a user record the IdP will bind to on first login.

• Email — unique per workspace; where the invitation is delivered
• Name — display name (optional)
• Workspace ID — the workspace this user belongs to. Leave blank for platform roles.
• Roles — checkbox list for any mix of built-in roles

The six built-in roles and their scopes are documented in Setup & Login → RBAC roles. Platform roles (owner, policy-admin, billing-admin) operate across all workspaces; workspace roles (admin, developer, viewer) are scoped to a single workspace. Mixing platform and workspace roles on one user is disallowed.

For the full invitation walkthrough — workspace create → invite admin → /register → portal hand-off — see Onboarding a Workspace.

Figure 7. Create-user form with role checkboxes

Edit user

Click Edit on any row to update the user's roles. Email, name, and workspace are displayed as read-only. Role changes take effect on the user's next request — no logout required.

Figure 8. Editing the dev user's roles. Email, name, and workspace are read-only; only the role set is mutable. The change takes effect on the user's next request. Console role-edits do not emit an audit event; role changes emit USER_ROLE_ASSIGNED / USER_ROLE_REVOKED.

Delete user

Click Delete to remove a user. Requires confirmation. Any API keys owned by the deleted user's workspace remain valid until explicitly revoked — user deletion and key revocation are separate operations.

Workspace self-service portal

Workspace-role users (admin, developer, viewer) are automatically redirected after login to the workspace portal at /portal instead of the platform dashboard at /. The portal is scoped to the user's own workspace and provides:

• API key management (create / revoke, role-gated)
• BYOK provider credentials (AES-256-GCM encrypted at rest)
• Token usage and cost visualizations
• Workspace-scoped audit logs
• Team management (workspace admin only) — see Onboarding a Workspace for the end-to-end invitation flow including the portal hand-off
• Guardrail plugin management (/portal/guardrail-plugins) — workspace-scoped plugin CRUD for admin and developer roles; viewer gets read-only access. Plugins created here are scoped to the workspace automatically. Platform-global plugins are not shown but still apply to the workspace's traffic.

Role capability matrix within the portal:

Capability	owner	admin	developer	viewer
View dashboard / usage / audit	All workspaces	Own workspace	Own workspace	Own workspace
Create API keys	Any workspace	Own workspace	Own workspace	No
Revoke API keys	Any workspace	Own workspace	No	No
Manage team members	All workspaces	Own workspace	No	No
Manage routes / policies	Yes	No	No	No
Manage own (TENANT) budget caps	Yes	Create / edit (admin + developer); delete (admin)	Create / edit	Read-only
Manage model pricing	Yes	No	No	No

Figure 9. The workspace portal landing — same workspace chrome a customer-side workspace admin sees. KPI cards (Total Requests, Total Tokens, Cost 30D, Active API Keys), the monthly-token-usage bar, and three Quick Actions: API Keys, Usage, Audit Log.

Figure 10. API Keys page scoped to the workspace — create + list + revoke. The Bearer prefix shown next to each key (e.g. `gw_1004be01…`) is the only part visible after creation; the full key is shown once at create time and never again.