Isolate AI workloads with workspaces

Enterprise only

Not included in DVARA Open Source.

DVARA Open Source can resolve a configured API key to a workspace, but it does not include accounts, teams, SSO, RBAC, or DVARA Flightdeck.

In the Enterprise platform, a workspace is the governance boundary for an AI workload. Its API keys, policies, budgets, credentials, usage, cost, and evidence stay scoped to that workspace while the deployment infrastructure is shared. This is logical isolation, not a dedicated deployment for each workspace.

DVARA Open Source can attach a configured workspace identity to a model request, but it does not provide the Enterprise account, team, role, or fleet-management workflows described below.

Three levels: account, team, workspace

Enterprise tenancy has three levels:

level	what it is	what keys on it
Account	the customer	quota bands and billing
Team	a group of people inside that customer	user membership and roles
Workspace	an isolated governance boundary	API keys, policies, budgets, credentials, audit rows — every workspace-scoped record

An account has many teams, and a team has many workspaces. The workspace remains the boundary used for governance and evidence.

Users belong to a team, not to a workspace

A user's role is granted on their team and spans that team's workspaces. That is the part a flat reading gets wrong: you do not add someone to a workspace, you add them to a team, and they then have that role across the workspaces the team holds.

Quotas roll up to the account

A quota band belongs to the account, not the workspace. This is the reason the level exists at all: with bands on workspaces, one customer with five workspaces would get five allowances, and the meter would measure nothing useful.

A workspace is the unit you switch between

The Flightdeck carry a workspace switcher, and views are workspace-scoped: you see one workspace's keys, spend, and audit evidence at a time.

What this means when reading the rest of this page

A workspace still has a name, a region, a status (ACTIVE / SUSPENDED) and a metadata map that tunes governance for that workspace alone (see Per-workspace configuration). Everything below about resolution, scoping and RBAC is workspace-level and unchanged — the account and team sit above it.

How a request is resolved to a workspace

An authenticated data-plane request carries an Authorization: Bearer <key> header. A DVARA API key is an opaque token rather than a JWT: it has no claims or parseable payload. The plaintext is shown once when you create the key, and each key belongs to one workspace.

When a request arrives:

1. DVARA validates the token and resolves its workspace. Open Source reads keys from file configuration; Enterprise manages them through DVARA Flightdeck.
2. DVARA uses the resolved workspace for rate limiting, policy, budgets, audit, cost attribution, and structured logs where those capabilities are available.

Opaque tokens, not JWTs

Revoking a key prevents it from authenticating future requests. Because the token carries no embedded authorization claims, DVARA resolves its current workspace and permissions on each authenticated request.

Every data-plane request requires a bearer key. DVARA resolves that key to a workspace before applying workspace-scoped policies, budgets, rate limits, cost attribution, and audit.

3-level configuration hierarchy

Many features cascade across three levels — global, workspace, and API key. Every applicable level is evaluated; the strictest or most specific level wins.

Global       ← applies to every workspace
  └─ Workspace     ← applies to every key in one workspace
       └─ API Key ← applies to one key in one workspace

• Budget caps stack at all three levels. A global "$5,000/month" plus a workspace "$500/month" plus an API key "$50/day" all apply, and the request is allowed only if it fits under every applicable cap.
• Policies have global and workspace scopes. Both run on every request; the strictest decision wins.
• Rate limits are keyed by API key, which transitively scopes them to the workspace.

Not every feature has all three levels. Where workspace-level config isn't supported, the global default applies to every workspace.

Per-workspace configuration

Per-workspace configuration is a small key-value map on each workspace. It overrides global defaults without a config reload.

Two ways to set it:

• DVARA Flightdeck — go to Workspaces → Edit. Form tabs cover the Basic, PII, Guardrails, and Embedded scanner keys. See Workspaces & Users for the walkthrough.
• GitOps import — edit the workspace's metadata object in a Flightdeck export, review the file in version control, then preview and apply it through the Flightdeck. The final import is a human action; the former Automation API is not available for CI/CD apply.

Changes take effect on the next request. Keys are flat dot-separated strings; values are strings, booleans, numbers, or JSON-encoded maps.

Key (or prefix)	Type	Distribution	Feature
priority-tier	premium / standard / bulk	Enterprise	Priority admission control
pat.max-ttl-days	int (≤ 365)	Enterprise	Narrow the platform-wide personal access token TTL ceiling for this workspace
pii.enabled, pii.action, pii.scan-responses, pii.scan-streaming-responses, pii.custom-patterns	various	Both	PII Detection
embedded.enabled-filters	CSV	Both	Built-in PII filter restriction
guardrail.enabled, guardrail.action, guardrail.risk-score-threshold	various	Both	Guardrails
guardrail.max-input-tokens, guardrail.max-messages-per-request, guardrail.max-message-length, guardrail.default-max-response-tokens	int	Both	OWASP LLM10 input-size overrides
guardrail.scan-streaming-responses	boolean	Both	Streaming content filter toggle
guardrail.content.*	various	Enterprise	Per-category content filtering
guardrail.injection.custom-patterns, guardrail.mcp-injection.enabled, guardrail.mcp-injection.action	various	Enterprise for MCP fields	Prompt and tool-injection detection
guardrail.context.*	int / enum	Both	Context-window management
guardrail.plugins	JSON map	Enterprise	Guardrail plugin overrides
grounding.*	various	Enterprise	Hallucination Detection
cost.*	various	Enterprise	Model downgrade and FinOps sensitivity
ip-access.allowlist, ip-access.denylist	CSV of CIDRs	Enterprise	Per-workspace IP access control
approval.*	various	Enterprise	MCP approval gates
agentic.loop-detection.*	various	Enterprise	Loop-detection tuning
audit.store-prompts	boolean	Enterprise	Prompt storage is not implemented in 1.8.1, so this keeps nothing

Set these from the Flightdeck's workspace form, or as a metadata object on the workspace in the Flightdeck's GitOps export/import document.

Require a workspace-owned provider credential

Strict BYOK is an Enterprise control and is off by default. Enable it globally:

dvara:
  credentials:
    require-workspace-credential: true

Or set credentials.require-workspace-credential: true in one workspace's metadata. An explicit workspace value overrides the global setting in either direction, so a workspace can require BYOK when the global setting is off or retain platform-credential fallback when the global setting is on.

The per-workspace value accepts a boolean, a number (0 / 1), or a YAML 1.1 truthy / falsy string (yes / no, on / off, 1 / 0, case-insensitive). Unrecognized values fall back to the global property and log a startup warning so a typo doesn't quietly disable enforcement.

Two operational notes worth flagging:

• The request already has a workspace identity. Every /v1 request requires a workspace API key before strict-BYOK evaluates the workspace credential.
• Rejection happens late. A workspace under enforcement who lacks their own credential still consumes their per-key rate-limit window and budget for the failed call, since the gate runs inside the upstream HTTP path after policy and budget filters. Size rate-limit and budget defaults with a little headroom for onboarding rejections.

Storage modes

Each credential is stored one of two ways:

• Encrypted (default) — the key is encrypted at rest with AES-256-GCM. The encryption key is derived from DVARA_ENCRYPTION_MASTER_PASSWORD using PBKDF2-HMAC-SHA256, so the master password is required whenever any credential uses this mode.
• Reference — only a vault pointer is stored in the database; the live secret never lands on the gateway at rest. Lookups go to HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault, and are cached in-process for 5 minutes by default (dvara.vault.cache-ttl-seconds), so steady-state traffic does not hit the vault per request. A deployment using only reference credentials can omit the master password entirely.

Full walkthrough: Credentials & BYOK.

RBAC: platform vs workspace scope

When RBAC is enabled (on by default whenever authentication is enabled), DVARA splits roles into three platform roles and three workspace roles:

Role	Scope	Example user
owner	Platform — full access everywhere	Platform lead
policy-admin	Platform — policies, routes, guardrails, MCP servers	Security engineer
billing-admin	Platform — pricing, costs, budgets, chargeback, compliance reports	FinOps
admin	Workspace — full access within own workspace + user management	Team lead
developer	Workspace — create API keys, view usage, dry-run policies	Application developer
viewer	Workspace — read-only access within own workspace	Auditor

Mixing platform and workspace roles on one user is disallowed. A user is either platform staff, who can work across workspaces, or a workspace user, who can access only their own workspace. DVARA refuses a mixed role set when an operator creates or updates a user and when an identity provider supplies one at sign-in. An invalid OIDC role set returns HTTP 401 invalid_token; an invalid SAML role set returns the user to the login page with saml_role_mix_invalid.

Flightdeck shows platform-wide or workspace-scoped navigation after sign-in, based on the user's role.

Workspace scoping

Most Flightdeck list and summary pages carry an optional workspace filter — Budgets, Policies, Costs, Audit, Token Usage and the rest.

The scope rule is enforced consistently across every page, summary and write that accepts a workspace id from the client:

• A platform owner, policy-admin, or billing-admin may pass any workspace id, or omit it for a cross-workspace view.
• A workspace admin, developer, or viewer may only act on their own workspace. Omitting workspace_id narrows the result to their own workspace. Passing a different workspace's id is rejected with HTTP 403 — the request is refused, not quietly narrowed, so the caller notices the misuse. A WORKSPACE_SCOPE_VIOLATION audit event is written on every rejection so security teams can detect probing.

The same rule applies when a workspace identifier arrives in a URL, query, or supported form. A workspace user who requests another workspace's data receives HTTP 403, and DVARA records WORKSPACE_SCOPE_VIOLATION. If the user omits an optional workspace filter, DVARA narrows the result to that user's workspace.

Managing workspaces

Creating a workspace

In DVARA Flightdeck, open Workspaces → New Workspace. For a reviewed bulk change, add the workspace to a GitOps export and import the updated document; re-importing the same identifiers updates the existing objects. See Workspaces and users for the complete workflow. After creation, issue an API key so the workspace's applications can authenticate.

Suspending vs deleting

• Suspend (reversible) — set status: SUSPENDED. New requests are rejected with a clear error code, but audit events, cost records, and token usage stay intact. You can re-activate later without losing history. Right for free-trial expirations, billing disputes, and short-term offboarding.
• Delete (irreversible) — removes the workspace and its owned identities, configuration, usage, and cost records. WORKSPACE_DELETED reports counts for the deleted workspace data, users, and keys. Tamper-evident audit evidence and MCP tool-call history remain available for investigation and export. Platform-global configuration is not affected.

Deleting a workspace is an operator action, handled from the DVARA Flightdeck:

Surface	Role required	Behaviour
Delete on the workspace's row in the Flightdeck	Platform owner only	Immediate. Removes the workspace-owned records described above. No recovery.

Other platform roles (policy-admin, billing-admin) cannot delete a workspace.

For permanent offboarding with a compliance requirement to purge PII, delete the workspace and then purge its PII tokens explicitly from the Flightdeck's PII page — deletion removes the workspace's rows, and the token purge makes any tokens minted under it permanently unresolvable.

Related

• DVARA Flightdeck — Workspaces & Users — UI walkthrough for workspace CRUD and API key management
• DVARA Flightdeck — Credentials & BYOK — full credential management flow, including reference storage mode
• Configuration — property reference for every feature that has per-workspace overrides