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.
Customer-onboarding access contract
Roles, scopes, ABAC constraints, separation of duties, and central
authorization are server-side activation requirements. Onboarding records
each enabled control as verified, pending, not enabled, or not
applicable; a present-tense description is not a substitute for that
tenant-specific evidence.
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 Advisory (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 k=5 suppression. Cannot read prompt/completion content. Cannot be the sole approver of a change it initiated (SoD). Cannot enable Active (Gate) during default onboarding. |
Tenant | residency must match the tenant lane (fail-closed). Sensitive operations require a fresh step-up assertion. Individual-level workforce views do not exist. |
| 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 Active (Gate). 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 Active (Gate). 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. Cannot modify attribution, policies, budgets, or grants. Cannot read prompt/completion content. Cannot see any cohort smaller than 5. Cannot cross the tenant boundary. | Workspace (or Tenant) | cohort reads enforce k=5 minimum-cohort suppression: any cohort below 5 rolls up to its parent and is never shown. |
Workforce-Data is cohort-only by design
Individual-level workforce views do not exist. Server-side k=5 minimum-cohort suppression applies to every cohort read path. No role or custom role can weaken it.
Custom roles¶
Custom is not a 5th canonical role. It is a named permission set composed by a Tenant Admin from canonical capabilities when the 4 roles are not a precise fit. The authoring UI shows a live diff against the nearest canonical role. A custom role cannot select a permission outside the plan, exceed the Admin ceiling, weaken the Workforce-Data purpose boundary or k=5 suppression, relax residency or separation-of-duties controls, or cross the tenant boundary. Its scope is author-chosen within those ceilings, and every inherited ABAC constraint can be tightened but never relaxed.
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-grant activation
Viewer and Auditor templates resolve through the same fail-closed authorization path as canonical roles. Time-boxing and auto-expiry must pass the tenant activation check before an Auditor grant is used as 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, workforce-cohort |
restricted requires a matching lane; workforce data requires Workforce-Data scope. |
Denied on mismatch. |
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. - 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.
- 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.
- 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 AI hot path’s fail-open behavior.
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.