Skip to content

Roles & access control

Venturi’s access model is built so a security review can find what it is looking for: least privilege, separation of duties, and a fail-closed default, all explainable on demand. Access is role-based at its core, with an attribute overlay for residency, data classification, and environment, and every grant is scoped to a position in your org-chart hierarchy. Nothing is reachable except through an explicit, scoped, auditable grant, and every access decision fails closed.

Verified for your tenant during onboarding

Onboarding exercises each access control you enable (the canonical role model, the access-explain surface, SSO, SCIM, and MFA enforcement, record-level tenant isolation, and the break-glass approval gate) 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.

This page covers the roles you assign, how scope and attributes narrow them, separation of duties, and how to keep access right over time. You assign and review all of it at Settings / Admin / Roles in the admin console; you can also drive it from your IdP through group mapping and SCIM. For the at-a-glance grid of every role’s permissions, explicit exclusions, scope, and ABAC constraints, see the role & permission matrix.

The four canonical roles

Two governance modes appear in the role descriptions below. Advisory (Shape) is the default for every tenant: budgets and policies raise alerts and routing recommendations but never block or throttle production AI traffic. Active (Gate) lets a policy emit a signed deny recommendation for one named workload; your customer-controlled enforcement point decides whether to apply it, and Venturi’s decision-time interceptor never blocks a request inline in any mode. Active (Gate) is never on during default onboarding: an Admin can enable it only for a named workload whose trust readiness has reached OPERATIONALLY_TRUSTED. See Governance & exports for the full mode ladder (Passive, Advisory (Shape), Active (Gate)).

Role What it can do Typical count
Admin Full access: user management, policy configuration, integration setup, pricing catalog, the intervention lifecycle, and enabling Active (Gate) for a named, operationally trusted workload whose deny recommendations your enforcement point applies. Can inspect full candidate sets, conflict classes, override history, and time-view divergence. 1 to 3
FinOps Full access to cost data, chargeback exports, budget configuration, forecasting, and adoption reports; read access to attribution and read-only billing visibility at Settings / Admin / Billing. Inspects ownership-vs-allocation distinctions and unresolved/unknown-spend reports. Cannot modify technical policies. 2 to 10
Engineer Read access to attribution, team-scoped dashboards, and model analytics. Can propose interventions and overrides (which require a separate approval). Inspects service/project conflict explanations, routing divergence, and model lineage within scope. Cannot modify policies or pricing. 10 to 100+
Workforce-Data The executive/people role (CTO / CHRO / Chief People Officer). Access to cohort-level adoption-intelligence and shadow-AI views by team, function, role, and tenure. Read-only with respect to attribution and policies. 1 to 5

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.

A common shorthand is Viewer for the lowest-privilege, read-only access (for example, an executive reader, or a just-in-time-provisioned account before an admin elevates it) and Auditor for a time-boxed, read-only grant with evidence and audit-log access. Both are expressed as scoped grants in the model below, and both appear as rows in the role & permission matrix.

Grants are relative to a scope

A role only means something at a scope node in the containment tree. The same “Engineer” role is very different at the tenant root than at one team:

Text Only
Organization   →  Tenant   →  Workspace   →  Team   →  Project   →  Object
Scope level What a grant there bounds
Organization Contract, billing visibility, residency lane, domain claims
Tenant The isolation boundary: all data, the tenant’s encryption key, the audit trail
Workspace A bounded analytic estate, e.g. a business unit or division
Team The org-chart unit that owns cost and adoption
Project The work unit attribution rolls up to
Object A single saved view, export, dashboard, override set, budget policy, or connector

Grants inherit downward: a FinOps @ Workspace: BU-West grant applies to every team and project beneath BU-West, unless an object-level rule narrows it. The admin console renders the effective scope path of every grant, for example Engineer @ Workspace:BU-West (inherited) → Team:Payments (effective), so you can see why a user has access, not only that they do.

Attributes narrow a role further

On top of the role and scope, a grant carries attribute conditions that must all hold for access to be allowed. This is what lets one role behave correctly across residency lanes and data classes:

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 Workforce data remains cohort-only Denied when the caller lacks Workforce-Data scope
cohort cohort id / size k=5 suppression applies to cohort reads Suppressed (rolled to parent, not errored)
env prod, staging, dev Scopes a grant to an environment Denied (a dev grant cannot read prod)

A user’s effective permission is the intersection of role, scope, inherited grants, attribute conditions, object-level sharing, and any active delegation.

Explain access

Because the model has several layers, the admin console can compute and explain the effective permission set for any user at any scope node: the resolved intersection, with each contributing factor itemized. When the answer is “deny,” it tells you which factor decided:

An explained denial

A FinOps user with residency=eu asks for an Exports object classified restricted in the us lane. “Explain access” returns:

Deny: residency mismatch, subject eu ≠ resource us.

The preview always matches the live runtime decision, so what you see in the console is exactly what the user would experience. Denials a user hits are rendered the same way (with the determining factor named), never as a generic error or an outage banner.

Custom roles

A Tenant Admin can compose a custom role as a named permission set when the four canonical roles are not a precise fit. Custom roles are not a fifth canonical role. The authoring UI is bounded by a ceiling:

  • It hard-prevents selecting any permission your plan does not include or that would escalate past Admin.
  • It shows a live diff against the nearest canonical role so you can see exactly what you are adding or removing.
  • A saved custom role can never resolve to a grant exceeding the entitlement ceiling set by your contract, and never weakens the Workforce-Data cohort-only boundary, its legal gate, or the k=5 minimum cohort size.

Step-up and separation of duties

Venturi enforces separation of duties (SoD) so no single person can both initiate and approve a consequential change, and surfaces the constraint before the action rather than failing at submit:

  • The Engineer who proposes an attribution override cannot be its sole approver. When that same person opens the approval control, it is disabled with an explanation, and a separate principal must approve. Enforcement is server-side and fail-closed; the disabled UI control reflects that enforcement.
  • The person who requests a support break-glass session cannot approve it.

A defined set of sensitive operations additionally requires a fresh step-up assertion (a WebAuthn or TOTP factor presented within the last 5 minutes by default), even inside a live session. 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 or SCIM. It also covers creating an export, changing the plan or billing settings, placing or releasing a legal hold, and approving break-glass.

A legal-gated actor is a user your organization has authorized to place and release legal holds. That authority is checked fail-closed on every lock and release, placing or releasing a hold requires a fresh step-up assertion, and a tenant-wide hold requires two actors.

Delegation and impersonation

For bounded, real-world needs, the admin console exposes two controlled patterns, both heavily instrumented:

  • Delegation lets a user hand a subset of their grants to a colleague for a bounded window. The delegate, the delegated scope, and the expiry are shown, and the delegation auto-expires with no residual access.
  • Impersonation (“view-as”) lets an admin see Venturi as a lower-privileged user would. It requires step-up to begin, shows a persistent “viewing as <user>” banner, is read-only by default, records every action as an impersonated action in the audit log, and can never cross the tenant boundary.

Recertification keeps access right

Standing access drifts. The admin console measures and corrects it:

  • Every grant shows its last-used time and an over-privilege flag when a role is broader than the user’s actual usage.
  • A recertification campaign asks grant owners to attest, downgrade, or revoke by a due date.
  • A grant that is not attested by the due date is flagged stale, surfaced in the campaign report, and defaults to restricted (read-only) pending review: closure over preservation. Every attest, downgrade, and revoke writes an append-only audit entry.

The standing guarantees behind every 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.
  • Every change is audited. Assigning, changing, delegating, recertifying, or revoking a grant writes an append-only audit entry.

Next steps

  • Drive roles from your IdP via group mapping and SCIM.
  • Manage users, policy, and recertification in the admin console at Settings / Admin / Users and Settings / Admin / Roles.
  • Verify enforcement and decisions in the audit log.
Give feedback on this page

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

Copy page details 
Docs feedback: Roles & access control
Page: https://docs.venturi.systems/administration/roles-and-rbac/