Skip to content

Technical diligence

Use this page to evaluate the 4 security controls most often reviewed during technical diligence. The detailed security pages linked below remain the authority for each control.

Customer-onboarding contract and deployment evidence

These controls describe the customer-onboarding contract. A tenant-specific implementation checklist records each control as verified, pending, not enabled, or not applicable. A public page cannot replace deployed policy, configuration, or verification evidence. See Docs authority and product state.

Review summary

Review area Customer-onboarding contract Evidence to inspect
Prompt and completion content No prompt or completion content is ever persisted. Venturi materializes allowlisted invocation metadata only. Event schema, ingestion validation, data-classification record, and log-guard evidence.
Connector permissions Connectors are read-only at the provider-scope, IAM-policy, and CI-gate layers. Deployed provider policy plus a positive read and denied write verification.
Tenant isolation Each tenant has a dedicated data boundary, tenant-scoped stores and event topics, and a dedicated KMS key. Tenant activation record and the signed-token tenant-binding test that returns 403 TENANT_MISMATCH on mismatch.
SOC 2 SOC 2 Type I readiness/report is a target. SOC 2 is not yet held. Current compliance status and the customer-applicable diligence packet.

Zero retention for prompt and completion content

No prompt or completion content is ever persisted. Optional provider grants can expose content-bearing logs while a connector reads them, so Venturi applies a field allowlist before materialization and discards request bodies, response bodies, and content-shaped keys in memory. Raw provider responses are not written to application logs, audit logs, retry queues, or dead-letter storage. The canonical InvocationEvent schema contains no field for prompt or completion text.

The zero-retention boundary applies to prompt and completion content, not to all operational data. Operational retention defaults to 13 months for allowlisted metadata such as identity, service, project, cost, token counts, and timing. Retention is configurable by data class from 30 days to 5 years. The pseudonymized audit trail has a separate 5-year Object Lock retention window.

Review Data privacy and retention for the field boundary, retention lifecycle, and crypto-shred erasure process.

Read-only connector enforcement

Venturi enforces read-only access at 3 independent layers:

  1. Connector scope. Each connector requests only documented read scopes and read endpoints.
  2. IAM explicit deny. Workload and customer cross-account policies contain an explicit Deny on all write actions.
  3. CI invariant gate. The platform permissions gate blocks an integration that requests write permission from shipping.

A deployment verification should inspect the exact provider policy, execute a permitted read, and execute a representative write that must fail. Record the policy version and both results in the tenant activation evidence.

Review Read-only integrations, enforced at 3 layers and Trust and security.

Tenant isolation architecture

Venturi runs a dedicated, single-tenant data plane. Self-hosted mode places that plane in the customer’s cloud account; SaaS mode uses a Venturi-operated, single-tenant environment in the contracted residency lane. Operational data is not pooled across tenants, and the separate control plane receives no raw tenant data.

Isolation is enforced through:

  • a tenant-scoped database;
  • tenant-scoped event topics;
  • a dedicated customer-managed KMS key;
  • a tenant-scoped audit trail; and
  • signed-token tenant binding at the query boundary.

Tokens are verified for issuer, audience, expiry, and signature before tenant binding is evaluated. A mismatch returns 403 TENANT_MISMATCH, returns no cross-tenant rows, and is logged. Venturi support has no standing tenant-data access; support access is time-boxed, MFA-gated, audited, and customer-notified.

Review Tenant isolation and Security architecture.

SOC 2 roadmap

SOC 2 Type I readiness/report is a target. SOC 2 is not yet held. Type I readiness work is in progress on the audit-trail and policy-event foundation. Type II is targeted within 12 months of Type I, with its observation window starting immediately.

The planned scope covers Security, Availability, Confidentiality, and Processing Integrity. Privacy is added when the 1st EU or regulated deal enters the pipeline. No penetration-test report or executive summary is represented as currently issued.

Review Compliance for the current roadmap status and the Trust center for the control crosswalk and diligence-artifact process.

Diligence evidence checklist

Before recording a control as verified:

  • inspect the deployed connector and IAM policies;
  • capture a successful read and denied write;
  • confirm the signed-token tenant-binding test returns 403 TENANT_MISMATCH;
  • confirm the tenant’s database, event topics, audit trail, and KMS key are tenant-scoped;
  • confirm the content field allowlist and no-persistence validation;
  • record the configured operational and audit-retention periods; and
  • use the current compliance page for SOC 2 status without implying an attestation is held.