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 & access control; 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.

Verified for your tenant during onboarding

Roles, scopes, ABAC constraints, separation of duties, and central authorization are enforced server-side. Onboarding exercises each control you enable against your configuration and records its status in your tenant’s implementation checklist. See Current implementation status for how that evidence relates to the customer-onboarding baseline.

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.
• Advisory (Shape) and Active (Gate): the two governance modes the matrix refers to. Advisory (Shape) is the default: policies raise alerts and routing recommendations but never block or throttle traffic. Active (Gate) lets a policy emit a signed deny recommendation for one named workload, which your customer-controlled enforcement point decides whether to apply; the decision-time interceptor never blocks a request inline in any mode. Active (Gate) is never on during default onboarding and can be enabled only for a workload whose trust readiness has reached OPERATIONALLY_TRUSTED. See Governance & exports.

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; configure Advisory (Shape) policies; enable Active (Gate) for a named workload that has reached OPERATIONALLY_TRUSTED; raise the minimum cohort size above 5 at Settings / Admin / Security; change the plan or billing settings. 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 lower the minimum cohort size below 5. Cannot read prompt/completion content. Cannot be the sole approver of a change it initiated (SoD). Cannot enable Active (Gate) during default onboarding or for a workload below OPERATIONALLY_TRUSTED.	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; read-only billing visibility (plan entitlements and consumption at Settings / Admin / Billing); inspect ownership-vs-allocation and unresolved/unknown-spend reports; author and publish chargeback.	Cannot modify technical policies, pricing-engine internals, or role bindings. Cannot change the plan or billing settings (billing mutation is Admin-only, with step-up). 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 includes only Chargeback-ready lines (coper >= 0.80); lines below that floor 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 the k=5 minimum cohort size (or the higher minimum an Admin set): any smaller cohort rolls up to its parent and is never shown.

Workforce-Data is cohort-only by design

Individual-level workforce views do not exist. Every cohort read path (adoption views, dashboards, filters, drill-downs, shared views, exports, API responses, board packs, and webhooks) enforces a server-side minimum cohort size of 5: a smaller cohort is suppressed and rolled into its parent unit, and it cannot be reconstructed by differencing overlapping cohorts. An Admin can raise the minimum above 5 at Settings / Admin / Security; no role, custom role, or setting can lower it. Beneath this boundary sits the Workforce-Data legal gate: the authorization layer denies every request for individual-level workforce data. No role, custom role, or IdP group mapping can grant past it. See Cohort-only adoption intelligence.

Custom roles

Custom is not a fifth canonical role. It is a named permission set composed by a Tenant Admin from canonical capabilities when the four 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 your plan or exceed the Admin ceiling. Nor can it weaken the Workforce-Data cohort-only boundary, its legal gate, the k=5 minimum cohort size, or residency and separation-of-duties controls, and it can never 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. Can open a dispute on an attribution result within its view scope; a dispute is collaboration metadata and never changes the attribution.	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. Can open a dispute on an attribution result within its view scope; a dispute is collaboration metadata and never changes the attribution.	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 use the same enforcement path

Viewer and Auditor templates resolve through the same fail-closed authorization path as canonical roles. An Auditor grant’s window is enforced server-side: at expiry the grant resolves to deny with no residual access, and the grant holder cannot extend it.

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 does not 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 reflects that enforcement.
• Step-up on sensitive operations. Each of these requires a fresh WebAuthn or TOTP assertion, presented within the last 5 minutes by default. The set covers enabling Active (Gate) for a workload, changing residency lane, creating or rotating API keys, changing a role binding, and configuring the IdP/SCIM. The same applies to creating an export, changing the plan or billing settings, placing or releasing a legal hold, and approving break-glass.
• Every change is audited. Assigning, changing, delegating, recertifying, or revoking a grant writes an append-only 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 decision-time interceptor’s fail-open behavior.

Next steps

• Read Roles & access control 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 at Settings / Admin / Roles in the admin console.
• Verify every decision and grant change in the audit log.

Give feedback on this page

Sign in to send feedback. Opens in a new tab.

Copy page details

Docs feedback: Role & permission matrix
Page: https://docs.venturi.systems/administration/role-permission-matrix/