Skip to content

Technical diligence

Use this page to evaluate the four 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

Customer onboarding contracts and the evidence to inspect:

Area Contract Evidence
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 only read. Native provider read permissions, cloud IAM where applicable, endpoint allowlists and certification preserve the boundary. Exact provider-policy evidence, a permitted read, and independent refusal tests for unsupported methods, management endpoints, redirects and alternate destinations.
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 Readiness program in progress; report not yet issued. SOC 2 Type I readiness/report target on our security roadmap with Type II targeted within 12 months; it is not yet held. Current compliance status and the onboarding diligence pack.

Zero retention for prompt and completion content

No prompt or completion content is ever persisted. The default cloud read grants can reach content-bearing logs that a provider writes, 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. On a call routed through the drop-in proxy, request and response content passes through Venturi’s proxy in memory only while it is forwarded, and is never written to access logs, error logs, traces, queues, or exception payloads, including on error and timeout paths.

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 S3 Object Lock retention period, in Governance mode by default or Compliance mode where root-resistant retention is required.

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 through provider-specific controls:

  1. Provider permissions and endpoint allowlist. Use native read permissions for each selected reporting surface. OpenAI organization Admin keys support permission selection, including Usage: Read for usage and cost reporting and Audit Logs Scope: Read for audit logs. Anthropic Admin API credentials can also authorize management operations. Both connectors restrict requests to GET on an explicit endpoint allowlist. An API Platform key is not a ChatGPT workspace key. See Provider connectors.
  2. Cloud IAM enforcement. Venturi’s cloud-authorized source access carries explicit write-denies where the cloud policy model supports them, and the customer cross-account role grants no write permission. A cloud IAM policy does not constrain a bearer key accepted by an external provider.
  3. CI invariant gate. The platform permissions gate rejects source-system write operations, unnecessary native management grants, and a broader reporting credential without independently certified read-only egress. Cloud IAM grants remain read-only.

For each connector, verify its exact provider policy and a permitted read. Prove write refusal with policy simulation or an isolated provider test fixture; do not attempt an administrative write against production data. For a reporting credential with wider capability, independently verify that unsupported methods, management endpoints, redirects and alternate destinations cannot escape the connector’s egress allowlist. A log containing only successful reads does not prove that refusal. Record the credential type, permitted scope, policy version, endpoint allowlist and negative-test results in the tenant activation evidence.

Review Read-only integrations, enforced at three 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; each support grant is approved by a customer Admin, time-boxed, MFA-gated, audited, and notified to you.

Review Tenant isolation and Security architecture.

SOC 2 status

SOC 2 Type I readiness/report target on our security roadmap with Type II targeted within 12 months; it is not yet held.

The readiness program runs on the audit-trail and policy-event foundation, and no SOC 2 report has been issued. Type II is targeted within 12 months of Type I, with its observation window starting immediately after Type I.

The scope covers Security, Availability, Confidentiality, and Processing Integrity. Privacy is added to the audit scope for EU or regulated-sector customer engagements.

Penetration testing is separate from SOC 2. A qualified third party tests the API endpoints, authentication flows, and tenant data boundaries at least annually. The executive summary and remediation status of the latest test are in the onboarding diligence pack, and the full report is available on request under NDA. See Penetration testing.

Review Compliance for the current status and the Trust center for the control crosswalk and the contents of the onboarding diligence pack.

Diligence evidence checklist

Before recording a control as verified:

  • inspect the deployed connector and IAM policies;
  • capture a successful read and a denied write for each scoped connector, and the outbound request and egress evidence showing only GET requests for each admin-key connector;
  • 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
  • record SOC 2 status from the current compliance page without implying an attestation is held: SOC 2 Type I readiness/report is a target, and SOC 2 is not yet held.
Give feedback on this page

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

Copy page details 
Docs feedback: Technical diligence
Page: https://docs.venturi.systems/security/technical-diligence/