Skip to content

The admin console

The admin console is the single, coherent surface where a Tenant Admin runs the Venturi tenant: users and their lifecycle, enterprise identity, access policy, recertification, tenant settings, and billing visibility. Every control shows its current state and its safe default, every mutation writes an immutable audit entry, and every denial names the factor that caused it — never a generic error and never a "degraded" banner used to mask an access decision. No control here sits on the AI hot path; administrative actions are fail-closed, never fail-open.

Where it lives

The admin surfaces are the Admin, Settings, Teams, Integrations, and Notifications pages of app.venturi.systems, reachable to users holding the Admin role. A non-admin who reaches an admin route sees a clear permission denial naming the role required, not a broken page.

What you manage here

  • Users & lifecycle

    Invite, provision, suspend, deactivate, transfer ownership, and recertify — each grant showing its effective scope path and least-privilege flags.

  • Enterprise identity

    SSO configuration and group mapping, SCIM enablement and token rotation, MFA/step-up policy, domain claiming, and the JIT toggle — on one surface, defaults visible.

  • Access policy

    Roles, custom roles, separation-of-duties visibility, delegation and impersonation controls, and access recertification campaigns. See Roles & RBAC.

  • Tenant settings

    Session duration and idle timeout, password complexity, residency and classification posture, notification routing, and configuration precedence.

  • Usage & billing visibility

    Plan entitlements and consumption via the billing entitlement card. Billing visibility is broad; billing mutation is fail-closed and admin-only.

  • Support access

    Approve, time-box, scope, and revoke Venturi support break-glass sessions — or leave them off. Venturi has no standing access.

User lifecycle

The console drives the full account lifecycle. Every transition is an explicit, audited action with a safe failure mode:

Stage What happens Safety mode
Invite Admin invites by email with an initial role and scope; no self-registration Single-use, expiring invite; fail-closed if expired
Provision (manual) Invited user registers by choosing an auth method Unverified email cannot activate
Provision (SCIM/JIT) Users and groups flow from your IdP; JIT creates a lowest-role account Deprovision removes access fail-closed within the SCIM sync SLA
Activate Account becomes usable; first session subject to MFA policy MFA enforced where policy requires
Suspend Temporarily block authentication without deleting history Active sessions revoked server-side immediately
Deactivate Disable the account; audit history preserved Cannot authenticate; grants resolve to deny
Transfer ownership Reassign objects/teams/projects/connectors a departing user held Orphaned objects never silently lose an owner; transfer audited
Off-board Revoke all grants; SCIM-driven where federated; data subject to ≤30-day crypto-shred on erasure Fail-closed; audit trail persists pseudonymized
Recertify Periodic attestation of remaining access Stale grants default to restricted, not retained

See Roles & RBAC for how scope, attributes, and separation of duties shape each grant.

Enterprise identity, on one surface

The identity panel brings every enterprise-identity control together with its security-relevant default already chosen and its current state shown:

Target-state — SSO / SCIM / MFA enforcement

The identity panel and its fail-closed defaults are the committed design. Live IdP-federated enforcement of SSO-only, SCIM provisioning, and MFA/step-up is a Target-state control being wired against the canonical identity model — not yet general. The binding label and gate are in Docs authority & product state.

Control Default Effect when changed
SSO-only Opt-in (off until verified) Disables password/OAuth tenant-wide; revokes non-SSO sessions at next validation
SCIM Off IdP-driven create/deprovision within the sync SLA; group→role mappings resolve to scoped grants
MFA / step-up Enforceable per tenant or role Privileged actions require a fresh factor regardless of session age
Domain claiming None claimed Verified domains enable JIT and assert tenant membership
JIT provisioning Off; lowest role when on First SSO login on a claimed domain creates a least-privilege account

Every change to any of these is a fail-closed authentication/authorization change (never fail-open) and writes an immutable audit entry. Credentials such as the SCIM bearer token and scoped API keys are rotated from the credential rotation panel, a step-up-protected, audited action.

Tenant settings

Tenant settings let you tune the tenant to your enterprise's policy. Settings resolve with a clear precedence — tenant override > workspace override > platform default — and every effective value is auditable with its source layer shown:

  • Sessions: configurable session duration and idle timeout; forced session revocation is available to admins.
  • Password complexity: enforced complexity and account lockout for the password method (where it is still enabled).
  • Residency & classification posture: view and confirm your tenant's residency lane and data-classification policy. Residency routing is fail-closed: a request that would touch an out-of-lane resource is blocked, not served cross-border.
  • Retention: the platform default is 13 months; a tenant may set a tighter override, which then governs deletion eligibility. The immutable audit trail is retained separately under its own lawful basis.
  • Notification routing: where budget, alert, and security notifications are delivered (email, Slack, Microsoft Teams, signed webhook).

Support access (break-glass)

Venturi support has no standing access to your tenant. Diagnostic access exists only through a customer-approved, time-boxed, scoped, audited break-glass workflow that you control entirely:

Target-state — break-glass enforcement

The no-standing-access posture and the approval, time-box, scope, and audit properties below are the committed design. The enforced approval gate — the operator surface that makes every diagnostic session customer-approved and fail-closed in runtime — is a Target-state control, not yet general. See the binding label in Docs authority & product state.

Property Behavior
Request Support raises a request naming the tenant, the narrowest data class, and the reason
Approval No access exists until your admin approves; approval is required, not bypassable
Time-box Sessions are time-boxed (default ≤4h, hard max 24h) and auto-expire
Scope & mode Limited to the approved tenant and data class; read-only by default; write requires explicit elevation
Audit Every session and every action within it is written to your audit trail and notifies you
Revocation You can revoke at any time; revocation or expiry fails closed with no residual access

You watch and govern this on the support case timeline. A break-glass session can never cross your tenant boundary.

Implementation checklist

For tenants still onboarding, the console presents a single implementation checklist that mirrors the prerequisites and resolves each item against live state — read-only access grants, encryption-key provisioning, outbound-only egress, connector validation, coverage, your first chargeback-eligible export, and finance acceptance. Each item reflects real status (met, pending, or blocked), and each blocked item deep-links to the action that resolves it.

Completeness and honesty

For any lifecycle stage or policy control, the admin console shows the surface, shows current state, writes an immutable audit entry on mutation, and renders any denial with the determining factor named. Every administrative mutation is fail-closed; none inherits the AI hot path's fail-open allowance.

Next steps