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 and the enforced break-glass gate described below are customer-onboarding requirements. If customer approval, MFA, scope, expiry, tenant binding, residency binding, or audit recording is not verified during activation, support does not receive tenant-data access and works only from customer-supplied diagnostics.

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 interceptor fail-open. The decision-time interceptor’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 with a fresh step-up assertion (WebAuthn or TOTP), and the person who requested a grant can never approve it. This is a human decision made by your side, not a 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: 4 hours by default and never more than 24 hours). These are immutable for the life of the grant; they cannot be widened or extended 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, and opening it notifies you. 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 append-only audit. Every action taken under the grant (and the request, approval, MFA, session open, and revoke events themselves) is written to your append-only audit log, attributable to the support actor and the case. No product surface or API can edit or delete an entry, and the stream is stored under S3 Object Lock with a 5-year retention period. The trail is customer-visible and survives recovery; it is the same 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 AI hot path’s fail-open behavior.

Why a support grant never inherits fail-open

For admitted requests that reach Venturi’s decision-time interceptor, failures or timeouts in Venturi dependencies behind it forward the request unmodified. The drop-in proxy endpoint’s own reachability remains on your request path; see Proxy endpoint reachability. 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 decision-time interceptor 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 control is a post-onboarding roadmap item

A grant is bound to your tenant’s region, and the residency check fails closed. The customer-facing inference_geo control, which would let you pin where inference-time decisions are made as a self-serve setting, is on the post-onboarding roadmap. 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, with a fresh step-up assertion. There is no Venturi-side toggle that creates access.
Am I told when a session opens? Yes. Opening a grant session notifies you, and every event in the grant’s life is in your audit log.
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 append-only, customer-visible audit log, reconciled in post-use review.
Can a decision-time interceptor failure relax a support-access decision? No. Authorization is fail-closed and never inherits the AI hot path’s fail-open allowance for your AI traffic.
Give feedback on this page

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

Copy page details 
Docs feedback: Support-access architecture
Page: https://docs.venturi.systems/operations/support-access-architecture/