Who can do what in dvt.
Four cumulative workspace roles set the baseline for every member. Per-resource sharing can only widen that baseline; API-key scopes and plan entitlements can only narrow it. This page exists so a security review doesn't have to ask.
The model at a glance
Access is layered, and each layer only moves in one direction. A member's workspace role sets their baseline across the org. Sharing grants can widen that baseline for one resource — never narrow it. API-key scopes and the org's plan entitlement can only narrow what a role or grant would otherwise allow — neither can grant more than the underlying role has.
effective access = ( role ∩ API-key scopes ∩ plan ) ∪ per-resource sharing grant
Four workspace roles
Roles are assigned per organization and are cumulative — each role includes everything the role below it can do (owner ⊇ admin ⊇ editor ⊇ viewer).
Viewer
Read dashboards, sheets, and other resources they have access to; run queries; comment.
Editor
Viewer, plus create and edit dashboards, sheets, and skills.
Admin
Editor, plus manage members, sharing, warehouse connections, API keys, and the audit log.
Owner
Admin, plus billing and organization-level settings, including promoting or demoting owners.
The full capability matrix
Every declared capability, and which roles include it. This table mirrors the same
authorization rules dvt's API enforces at request time: it is transcribed from dvt's
generated authz matrix — a test-locked artifact that cannot drift from what the server
enforces — and the same matrix is rendered live in-app under Members → Roles &
permissions. Capability ids (e.g. dashboard:read) are
the exact strings used as API-key scopes.
| Capability | Viewer | Editor | Admin | Owner |
|---|---|---|---|---|
| Dashboards | ||||
dashboard:read — View dashboards and their data | ✓ | ✓ | ✓ | ✓ |
dashboard:write — Create and edit dashboards | – | ✓ | ✓ | ✓ |
| Data | ||||
data:query — Run queries behind panels | ✓ | ✓ | ✓ | ✓ |
data:export — Export results and schedule exports | ✓ | ✓ | ✓ | ✓ |
data:read_cached — Read cached query results | ✓ | ✓ | ✓ | ✓ |
| Sheets | ||||
sheet:read — View sheets | ✓ | ✓ | ✓ | ✓ |
sheet:write — Create and edit sheets | – | ✓ | ✓ | ✓ |
sheet:delete — Delete sheets | – | ✓ | ✓ | ✓ |
| Skills | ||||
skill:read — Use skills | ✓ | ✓ | ✓ | ✓ |
skill:write — Create and edit skills | – | ✓ | ✓ | ✓ |
skill:manage — Publish and manage org skills | – | – | ✓ | ✓ |
| Comments | ||||
comment:read — Read comment threads | ✓ | ✓ | ✓ | ✓ |
comment:write — Write comments | ✓ | ✓ | ✓ | ✓ |
| Sharing & members | ||||
share:manage — Manage sharing and visibility | – | – | ✓ | ✓ |
member:manage — Invite, remove, and set member roles | – | – | ✓ | ✓ |
member:manage_owners — Promote or demote owners | – | – | – | ✓ |
| Workspace administration | ||||
connection:manage — Manage warehouse connections | – | – | ✓ | ✓ |
apikey:manage — Manage API keys | – | – | ✓ | ✓ |
audit:read — View audit log and admin analytics | – | – | ✓ | ✓ |
support_issue:manage — Manage support issues | – | – | ✓ | ✓ |
| Organization | ||||
billing:manage — Manage billing | – | – | – | ✓ |
org:manage — Rename, rebrand, or delete the org | – | – | – | ✓ |
✓ = included in that role; – = not included. Roles are cumulative, so a capability that appears at Editor also appears at Admin and Owner.
Workspace roles vs. sharing grants
The matrix above is a member's workspace role — their baseline across everything in the org. Sharing a dashboard or sheet grants extra access to that one resource only, and can only widen what the workspace role already allows — a share can never take away what a workspace role already gives.
| Sharing grant | On that resource, the person can… |
|---|---|
| Viewer | View it, run its queries, export, comment. |
| Editor | Everything Viewer can, plus edit it. |
| Manage | Everything Editor can, plus change its visibility and share it with others. |
Naming note: a Manage grant is admin of that one resource — it does not make someone a workspace Admin. For example, a workspace Viewer given an Editor grant on one dashboard can edit that dashboard and nothing else. Admins and Owners already hold manage access everywhere, so grants never affect them.
API keys and plans can only narrow
Two more layers sit on top of a role, and both only ever restrict what it allows — never add to it.
API-key scopes
Scopes restrict a key to a subset of what its owner's role allows — a scope can never grant a key more than the owner's role and plan already permit. An unscoped key carries the owner's full effective role.
Plan entitlements
A capability is exercised only if the org's current plan tier entitles it. Plan is resolved fresh on every request, never snapshotted when a key is minted — so a downgrade applies on the very next call, for every key regardless of when it was created.
AI agents inherit your permissions
There is no special agent permission tier. When an AI agent operates dvt through the API or MCP server, it holds the token of the user it acts for and can do exactly what that user can do — no more, no less. Agent actions are recorded in the audit log, attributed as agent activity. See Security for the broader story on AI and your data.
Warehouse access is a separate layer
Everything above governs what a member can do in dvt — view, edit, share, administer. It does not govern what rows and columns a warehouse query returns. The identity dvt presents to your warehouse is set per connection: either a shared service credential, or per-user OAuth passthrough, where your warehouse enforces that user's own row- and column-level policies natively. The guarantee: a dvt Admin's workspace role never grants more warehouse access than the connection's own credential has. See Security for the full data-flow story.
Running a security review? Email [email protected] and we'll help.