Role & permission matrix¶
This page is the single, customer-readable reference for what each Venturi role can do, what it explicitly cannot do, the scope it operates at, and the attribute (ABAC) constraints that narrow it. It is the matrix form of the model described in Roles & RBAC; read that page first for how roles, scope, and attributes compose. Use this page when you are mapping IdP groups, designing a custom role, or answering an auditor's "who can do what" question.
The access model is exact and closed:
- Four canonical roles — Admin, FinOps, Engineer, Workforce-Data.
- Two scoped-grant templates — Viewer and Auditor, expressed as bounded read-only grants, not separate roles.
- Custom roles, composed by a Tenant Admin within a hard ceiling.
Every grant resolves to the intersection of role, scope, inherited grants, and attribute conditions, and every access decision fails closed — a missing, ambiguous, or denied permission blocks the operation; it never degrades into access. No prompt or completion content is ever readable through any role.
Release state of access enforcement
The role and scope model, separation-of-duties constraints, and the individual-level workforce legal gate described here are Target-state controls. They are being rolled out and are not yet generally available end-to-end. Where a specific control is still being hardened, it carries an inline release-state label below. Roles, scope, and ABAC constraints are enforced server-side and fail closed by design; treat any control without a GA label as not-yet-GA and confirm its status with your account team before relying on it for a compliance attestation. Release states used on this page: GA, Private preview, Milestone-scoped, Target-state.
How to read the matrix¶
- Core permissions — what the role can do, in plain capability terms.
- Explicit exclusions — what the role cannot do, stated positively so a security reviewer can see the boundary, not infer it.
- Default scope — the scope node a grant is typically issued at. A role only
means something relative to a node in the containment tree
(
Organization → Tenant → Workspace → Team → Project → Object); grants inherit downward unless an object-level rule narrows them. - Key ABAC constraints — the attribute conditions (
residency,data_classification,cohort,env) that must all hold for access to be allowed. Any mismatch denies (or, for cohort reads, suppresses) — it never widens access.
Canonical roles¶
| Role | Core permissions | Explicit exclusions | Default scope | Key ABAC constraints |
|---|---|---|---|---|
| Admin | User and grant management; policy and pricing-catalog configuration; integration/connector setup; the intervention lifecycle; inspect full candidate sets, conflict classes, override history, and time-view divergence; enable SHAPE policies. Admin is the ceiling — no role or custom role can exceed it. | Cannot cross the tenant boundary (a cross-tenant request fails closed with 403 TENANT_MISMATCH). Cannot weaken the Workforce-Data legal gate or k=5 suppression. Cannot read prompt/completion content. Cannot be the sole approver of a change it initiated (SoD). Cannot enable GATE during default onboarding. |
Tenant | residency must match the tenant lane (fail-closed). Sensitive operations require a fresh step-up assertion. Individual-level workforce data remains gated regardless of Admin. |
| FinOps | Full access to cost data, chargeback exports, budget configuration, forecasting, and adoption reports; read access to attribution; inspect ownership-vs-allocation and unresolved/unknown-spend reports; author and publish chargeback. | Cannot modify technical policies, pricing-engine internals, or role bindings. Cannot enable interception. Cannot read prompt/completion content. Cannot read individual-level workforce data. Cannot cross the tenant boundary. | Workspace | residency must match resource lane (fail-closed). data_classification=restricted exports require the matching lane. Chargeback honors the 0.80 confidence floor; lines below it are disclosed, not silently dropped. |
| Engineer | Read attribution, team-scoped dashboards, and model analytics within scope; propose interventions and overrides (which require separate approval); inspect service/project conflict explanations, routing divergence, and model lineage within scope. | Cannot modify policies, pricing, or budgets. Cannot approve its own proposed override (SoD). Cannot enable interception. Cannot read prompt/completion content. Cannot read individual-level workforce data. Cannot read outside granted scope. Cannot cross the tenant boundary. | Team (or Project) | residency and env must match (a dev grant cannot read prod; fail-closed). Scope inheritance is downward-only; object-level rules can narrow further. |
| Workforce-Data | The executive/people role (CTO / CHRO / Chief People Officer): cohort-level adoption-intelligence and shadow-AI views by team, function, role, and tenure. Read-only with respect to attribution and policies. | Cannot view individual-level workforce data through any UI toggle. Cannot modify attribution, policies, budgets, or grants. Cannot read prompt/completion content. Cannot see any cohort smaller than five. Cannot cross the tenant boundary. | Workspace (or Tenant) | cohort reads enforce k=5 minimum-cohort suppression — any cohort below five rolls up to its parent and is never shown. data_classification=individual-level-workforce requires the legal gate and is hard-disabled in the EU regardless of role. |
| Custom | A named permission set composed by a Tenant Admin from canonical capabilities when the four roles aren't a precise fit. The authoring UI shows a live diff against the nearest canonical role. | Cannot select any permission your plan doesn't include. Cannot escalate past the Admin ceiling. Cannot weaken the Workforce-Data legal gate, k=5 suppression, residency fail-closed, or separation-of-duties. Cannot cross the tenant boundary. | Author-chosen, bounded by plan and Admin ceiling | Inherits every ABAC constraint of the capabilities it includes; constraints can only be tightened, never relaxed. |
Workforce-Data is cohort-only by design
Individual-level workforce views are never a UI toggle. They are gated per tenant behind written legal sign-off plus a DPA amendment, are off in the EU regardless of role, and are always subject to k=5 minimum-cohort suppression. No role and no custom role can weaken this.
Release state: Milestone-scoped. k=5 suppression and the individual-level legal gate are being hardened to enforce across every cohort read path before this control is declared GA. Until then, treat cohort visibility as a control under active rollout and confirm coverage with your account team.
Scoped-grant templates¶
Viewer and Auditor are not separate roles — they are bounded, read-only grants expressed in the same model. They exist so you can hand out least-privilege, time-boxed access without inventing a custom role.
| Template | Core permissions | Explicit exclusions | Default scope | Key ABAC constraints |
|---|---|---|---|---|
| Viewer-grant | The lowest-privilege, read-only view — for example an executive reader, or a just-in-time-provisioned account before an Admin elevates it. Sees dashboards and reports within scope. | Cannot propose, approve, configure, export, or mutate anything. Cannot read prompt/completion content. Cannot read individual-level workforce data. Cannot read outside granted scope or across the tenant boundary. | Narrowest granted node (e.g. Project or Object) | All canonical ABAC constraints apply (residency, data_classification, cohort k=5, env); read-only never relaxes them. |
| Auditor-grant | A time-boxed, read-only grant scoped to evidence and the audit log — every consequential action, mutation, export, access, override, and support session — so a reviewer can verify without standing access. | Cannot mutate, configure, approve, export operational data, or read prompt/completion content. Cannot read individual-level workforce data. Cannot extend its own window. Cannot cross the tenant boundary. | Tenant (audit/evidence surface), time-boxed | Bound by residency to the tenant lane; auto-expires at the end of its window with no residual access. Every read it performs is itself audited. |
Scoped grants — release state
Target-state. Viewer and Auditor grant templates resolve through the same fail-closed authorization path as canonical roles. Time-boxing and auto-expiry of Auditor grants are part of the recertification and access lifecycle currently being rolled out; confirm enforcement status with your account team before using an Auditor grant as standalone audit evidence.
ABAC constraint reference¶
These attribute conditions narrow every row above. All conditions on a grant must hold for access to be allowed.
| Attribute | Example values | Effect | If it doesn't match |
|---|---|---|---|
residency |
us, eu, lane |
The subject's lane must match the resource's lane. | Denied — residency is fail-closed. |
data_classification |
standard, restricted, individual-level-workforce |
restricted requires a matching lane; individual-level-workforce requires the legal gate. |
Denied; individual-level-workforce is EU-hard-disabled regardless of role. |
cohort |
cohort id / size | k=5 suppression applies to cohort reads. | Suppressed — rolled up to the parent cohort, never shown, never errored. |
env |
prod, staging, dev |
Scopes a grant to an environment. | Denied — a dev grant cannot read prod. |
Cross-cutting guarantees (apply to every role and grant)¶
These hold for all rows above and cannot be overridden by any role, custom role, or grant:
- Tenant isolation precedes every grant. A grant can only narrow within the
tenant; a cross-tenant request fails closed with
403 TENANT_MISMATCH. (Release state: Target-state — record-level tenant isolation is being hardened; confirm enforcement scope with your account team.) - Authorization fails closed. A missing, ambiguous, or denied permission blocks the operation — it never degrades into access.
- No content access, ever. No role, custom role, or grant can read prompt or completion content. Venturi attributes consumption; it does not read the payload.
- Separation of duties. The principal who proposes a consequential change cannot be its sole approver, and the requester of a support break-glass session cannot approve it. Enforcement is server-side; the disabled UI control merely reflects it. (Release state: Target-state.)
- Step-up on sensitive operations. Enabling interception, changing residency lane, rotating API keys, changing a role binding, configuring the IdP/SCIM, creating an export, placing or releasing a legal hold, and approving break-glass each require a fresh WebAuthn or TOTP assertion. (Release state: Target-state.)
- Every change is audited. Assigning, changing, delegating, recertifying, or revoking a grant writes an immutable audit entry.
- Venturi support is never in this matrix. Venturi personnel hold no standing access. A support session is customer-approved, time-boxed, MFA-gated, least-privilege, tenant/residency-bound, read-only by default, fully audited, and fail-closed — and it never inherits the gateway's fail-open behavior. (Release state: Target-state — the break-glass program and Operator Console are being rolled out; see your account team for current status.)
Next steps¶
- Read Roles & RBAC for how roles, scope, and attributes compose, and for delegation, impersonation, and recertification.
- Drive role assignment from your IdP via group mapping and SCIM.
- Assign, review, and recertify grants in the admin console.
- Verify every decision and grant change in the audit log.