Skip to content

Support-access architecture

This page is the engineering-level description of how Venturi support reaches your tenant when — and only when — you let it. It is written for the security reviewer who needs to see the full break-glass flow before signing, and for the operator who will approve a grant during a live case. The short version is the part that matters most: Venturi support has no standing access to your tenant. There is no always-on support role, no shared admin credential, and no background session waiting to be used. Access exists only as a customer-approved, time-boxed, fail-closed grant that is created for one case and destroyed when that case closes.

The no-standing-access model above is the binding design, and the audit record of any support action is in place. The runtime enforcement of the break-glass gate described below — customer-approved, MFA-gated, scope/expiry-bound, fail-closed — is Target-state: it is being wired against the canonical identity model and is not yet general. This page describes the designed enforced behavior; see Docs authority & product state for the binding release state of each control.

The guarantees, before the flow

  • No standing access. Default onboarding grants Venturi support nothing. A grant must be requested and customer-approved for each case; nothing persists between cases.
  • Fail-closed. Every check in the flow — approval, scope, residency, tenant boundary, MFA, expiry — fails closed. A failed or ambiguous check denies access; it never degrades to "allow."
  • Tenant- and residency-bound. A grant is pinned to one tenant and one residency region. It cannot reach across your tenant boundary or out of your region, by construction.
  • Read-only by default. A grant resolves to read-only unless you explicitly approve a narrower write scope for the named action.
  • Never inherits the gateway fail-open. The decision-time gateway's fail-open allowance applies to your live AI traffic only. A support-access decision is an authorization decision and is one of the fail-closed surfaces — it never inherits fail-open.
  • No prompt or completion content, ever. A grant cannot expose prompt or completion bodies, because Venturi never stores them. The most a grant can ever reach is invocation metadata.

What support can and cannot see before a grant exists

This is the question security teams ask first: what does Venturi support see in the steady state, with no active grant? The answer is customer-safe metadata only.

State What Venturi support can see
No active grant (the default) Customer-safe operational metadata: tenant lifecycle stage, onboarding-completion status, connector health and freshness signals, degradation state, named SLO/SLI readings, and case-level fields you attach to a ticket. No tenant data records.
Active grant (customer-approved, time-boxed) The above, plus the specific, scoped invocation metadata named in the approved grant — for example the attribution records and evidence basis for one disputed result — for the duration of the window only.
Anywhere, any state Never prompt or completion bodies, provider key material, or another tenant's data. These are not exposable because they are not stored in a support-reachable form.

The metadata visible without a grant is the same evidence that makes a support case productive without crossing a data boundary: support can reason about whether attribution is current and which signals informed it before ever requesting access to the records themselves. See Support → evidence-linked cases and Confidence & evidence for what each metadata field means.

The break-glass flow, step by step

A break-glass grant moves through a fixed sequence. Each step is a gate: the flow cannot skip ahead, and a failure at any step ends the flow without access being granted. Every transition is recorded.

  1. Request. Venturi support opens a break-glass request bound to a specific tenant and case. The request states the reason in plain language and references the ticket. No access is created by the request itself — it is a proposal awaiting your decision.
  2. Customer Admin approval. A customer Admin must explicitly authorize the request. This is a human decision made by your side, not an Venturi-side toggle. Without an Admin approval the request expires unused. (See the canonical role model — Admin, FinOps, Engineer, Workforce-Data, plus the Viewer and Auditor scoped-grant templates.)
  3. Scope, purpose, and duration are bound. Approval fixes three things and writes them into the grant: the scope (which records or surfaces, never broader than the case requires), the purpose (the recorded reason), and the duration (an explicit expiry window). These are immutable for the life of the grant — they cannot be widened after approval without a new request and a new approval.
  4. Step-up MFA. Before any session can open, the support actor completes a step-up MFA challenge. The grant is bound to the authenticated actor; the session cannot open without a fresh second factor, and the factor cannot be reused for a different grant.
  5. Ticket-bound active session. Only now does an active session exist. It is bound to the ticket and to the approved scope/purpose/duration. The session is the only state in which support can reach the approved metadata, and it carries the case identifier on every action it takes.
  6. Read-only by default. The session resolves to read-only unless your Admin explicitly approved a narrower write scope for the named action in step 3. Read-only is the floor: a grant with no explicit write approval can observe but cannot mutate.
  7. Immediate revoke. The grant auto-revokes when its window closes, and your Admin can revoke it immediately at any point — closing the session at once, not at the next expiry tick. Revocation is itself fail-closed: if revocation state is uncertain, the session is treated as closed.
  8. Customer-visible immutable audit. Every action taken under the grant — and the request, approval, MFA, session open, and revoke events themselves — is written to your immutable, append-only audit log, attributable to the support actor and the case. The trail is customer-visible and survives recovery; it is the same WORM audit surface used for administrative and access actions.
  9. Post-use review. After the grant closes, the case is subject to post-use review: the recorded scope, purpose, duration, and actions are reconciled against the case so that what was accessed matches what was approved. The review is part of closing the case, not an optional follow-up.

Each step is a fail-closed gate

The sequence above is not a checklist of best intentions — it is enforced control flow. A missing Admin approval, a failed MFA challenge, an expired window, a scope that does not match the request, a tenant or residency mismatch: any of these denies the session. None of them degrades to a partial or "best-effort" grant. This is what fail-closed means here, and it is why a support-access decision can never inherit the gateway's fail-open behavior.

Why a support grant never inherits fail-open

Venturi's decision-time gateway is fail-open on your live AI traffic: if any Venturi component fails, your AI request is forwarded unmodified, because nothing Venturi does may take your traffic down. That allowance is deliberately narrow. A break-glass grant is an authorization decision, and authorization is one of the fail-closed surfaces — alongside authentication, tenant isolation, export, billing mutation, and residency routing. When an authorization check cannot be satisfied, the answer is deny, never allow-through. The fail-open path and the fail-closed surfaces are separate by design, so a gateway failure can never relax a support-access decision. See Operations → access-control surfaces fail closed and the fail-open guarantee.

Tenant and residency binding

A grant is pinned to one tenant and one residency region at approval time and cannot move off either.

  • Tenant-bound. A grant authorizes access to the approved tenant only. A cross-tenant reach is rejected, not filtered — it returns the same TENANT_MISMATCH rejection any cross-tenant request would, regardless of the support actor's role. Per-tenant stores and per-tenant keys mean there is no shared surface for a grant to wander into. See Tenant isolation.
  • Residency-bound. A grant cannot reach data outside the tenant's residency region. The residency check fails closed, so a grant that would cross a region boundary is denied rather than served. See Residency & subprocessors.

The inference_geo residency-control surface is Target-state

Today, a grant is bound to your tenant's region and the residency check fails closed. The customer-facing inference_geo control that would let you pin where inference-time decisions are made as a self-serve surface is Target-state — on the roadmap with an explicit phase gate, built on shipped region-aware fields. It is not part of the break-glass flow above. See Compliance → GDPR.

What a reviewer can verify

Question Answer
Does Venturi support have standing access to my tenant? No. Default onboarding grants nothing; a grant is created per case and destroyed when the case closes.
Who authorizes a grant? A customer Admin, explicitly, per request. There is no Venturi-side toggle that creates access.
What can support see with no active grant? Customer-safe operational metadata only — lifecycle stage, connector health, degradation state, SLO readings, and case fields. No tenant data records.
Can a grant ever expose prompt or completion content? No. Venturi does not store prompt or completion bodies, so no grant can reach them. The ceiling is invocation metadata.
Is a grant read-only? Read-only by default. A write scope exists only if your Admin explicitly approved one for the named action.
Can I end a session early? Yes. A grant auto-revokes at expiry, and your Admin can revoke it immediately at any time.
Where is the evidence? Every request, approval, MFA, session, action, and revoke is in your immutable, customer-visible audit log, reconciled in post-use review.
Can a gateway failure relax a support-access decision? No. Authorization is fail-closed and never inherits the gateway's fail-open allowance for your AI traffic.