Skip to content
Venturi
Contact

Platform / Security

A narrow trust boundary, built for review.

The customer data plane, attribution graph, index, decision records, and decision-time interceptor are designed to run inside the customer environment. Connectors are read-only; data crossing into the Venturi control plane is limited and explicitly enumerated.

Security claims are labeled by state: specified, implemented, tested, independently assessed, or planned.

Inspect trust model

Trust-boundary diagram

Customer operational data stays inside the customer-controlled data plane.

Narrow deployment and health metadata may cross the boundary as explicitly listed below. Optional aggregated benchmarking is a separate opt-in.

Architecture commitment . A required system behavior that still needs deployment evidence. Validation pending . Customer evidence is still required to validate actionability.

Trust boundary

Customer-controlled data plane with a narrow control-plane channel

Architecture commitment . A required system behavior that still needs deployment evidence.

Customer environment

Customer operational data remains inside the customer-controlled data plane.

  1. 01Read-only connectors and governed source records
  2. 02Attribution graph and materialized index
  3. 03Venturi attribution engine
  4. 04Decision records and correction history
  5. 05Decision-time interceptor and customer policy context
Decision-time invariantIndex-only lookup. Request proceeds unmodified on Venturi failure.

Venturi control plane

Narrow deployment and health metadata may cross the boundary only as listed.

  • Tenant identifier
  • Deployment and component version
  • License state
  • Enabled connector identifiers, not source payloads
  • Configuration version
  • Component health, error class, and timestamps

Optional aggregated benchmarking is a separate explicit opt-in.

Explicitly excluded from the control-plane channel
  • Customer telemetry and traces
  • Prompts and outputs
  • Attribution records and cost records
  • Source code content
  • Credentials and identity records
  • Compensation and performance data

In summary: read-only connectors, governed records, graph, index, attribution engine, decision records, and interceptor run in the customer environment. Only the listed tenant, version, license, configuration, connector identifier, and health metadata may cross to the Venturi control plane. Customer operational content is explicitly excluded.

What runs where

Attribution and serving state remain in the customer environment.

The control plane manages narrow licensing, version, configuration, and health concerns. It is not the customer attribution data plane.

Read-only connectors
Source observations and governed records
Venturi attribution engine
Deterministic resolution, eligible inference, and separate allocation
Attribution graph
Five node types, eight governed relations, and evidence lineage
Materialized index
Bounded lookup for the decision-time path
Decision records
Evidence, alternatives, time basis, truth domains, and corrections
Decision-time interceptor
Shape advisory path and customer-controlled Gate context

What may cross the boundary

Control-plane metadata is enumerated directly.

Each allowed field has a deployment or diagnostic purpose. Source payloads and customer operational content are not implied by these categories.

Tenant identifier
Identifies the licensed customer deployment
Deployment and component version
Supports updates and compatibility review
License state
Supports subscription validation
Enabled connector identifiers
Names configured connector types without source payloads
Configuration version
Supports governed configuration synchronization
Component health, error class, and timestamps
Supports diagnostics without customer operational content

Read-only permission matrix

Review each system by data used, permission, exclusion, and expansion trigger.

Venturi asks for the narrowest source scope that can support the approved relationships. Any scope expansion returns to security review.

Permission matrix

Requested access, excluded data, and review triggers

Cloud billingReview permission details
Data used
Usage, provider identifiers, account and project hierarchy, reconciled charges
Permission
Read-only billing export or cost API
Explicitly excluded
Resource modification, payment credentials, workload writes
Review trigger
New account, provider, field, or permission scope
TelemetryReview permission details
Data used
Service, workload, route, deployment, and runtime context
Permission
Read-only telemetry query
Explicitly excluded
Payload bodies, prompts, outputs, and application secrets
Review trigger
New telemetry field or payload-content request
Source controlReview permission details
Data used
Repository identity and governed ownership metadata
Permission
Read-only repository metadata
Explicitly excluded
Source code content, write access, and merge controls
Review trigger
Any source-content or write request
CI/CDReview permission details
Data used
Deployment identifier, environment, workload, and release timestamp
Permission
Read-only deployment metadata
Explicitly excluded
Deployment mutation, build secrets, and approval writes
Review trigger
Any write action or release-gating request
IdentityReview permission details
Data used
Human and service identities, groups, lifecycle state
Permission
Read-only directory query
Explicitly excluded
Passwords, authentication factors, credentials, and identity writes
Review trigger
New identity source or write scope
HCM and organizationReview permission details
Data used
Team, organization, manager chain, budget hierarchy, and effective dates
Permission
Limited read-only hierarchy query
Explicitly excluded
Compensation, performance, medical, and unrelated sensitive HR data
Review trigger
Any field outside approved hierarchy scope

Fail-open diagnostic

Every failure condition preserves customer traffic.

Timeout, service error, index unavailability, connector degradation, policy lookup failure, and confidence below threshold produce operator evidence while the request proceeds unmodified.

Architecture commitment . A required system behavior that still needs deployment evidence.

Fail-open diagnostic

Failure produces operator evidence, not production blocking.

TimeoutReview failure behavior
Venturi behavior
Skip Venturi context when the architecture budget is exhausted
Customer traffic
Request proceeds unmodified.
Operator evidence
Timeout event and latency bucket
Follow-up action
Review index freshness and interceptor budget
Service errorReview failure behavior
Venturi behavior
Return no Venturi decision context
Customer traffic
Request proceeds unmodified.
Operator evidence
Component health and error-class event
Follow-up action
Inspect the failing component and recovery state
Attribution index unavailableReview failure behavior
Venturi behavior
Do not traverse the attribution graph
Customer traffic
Request proceeds unmodified.
Operator evidence
Index-unavailable diagnostic
Follow-up action
Restore or re-materialize the index
Connector degradationReview failure behavior
Venturi behavior
Expose degraded source health and keep operational use bounded
Customer traffic
Request proceeds unmodified.
Operator evidence
Connector-health event and affected source
Follow-up action
Restore source health and re-materialize if needed
Policy lookup failureReview failure behavior
Venturi behavior
Return no customer-controlled policy context
Customer traffic
Request proceeds unmodified.
Operator evidence
Policy-lookup diagnostic
Follow-up action
Review workload and policy configuration
Confidence below thresholdReview failure behavior
Venturi behavior
Keep the result advisory, in review, or Gate-ineligible
Customer traffic
Request proceeds unmodified.
Operator evidence
Output state, threshold relation, and explanation
Follow-up action
Add eligible evidence or route human review

Shape and customer-controlled Gate

Advisory by default. Gate requires explicit workload and policy configuration.

Shape supplies context, review routing, and optimization recommendations. Gate is a separate customer-controlled path and is never activated by low-confidence ownership.

Default Architecture commitment . A required system behavior that still needs deployment evidence.

Shape

Advisory context only. It does not block customer traffic.

Explicit opt-in Architecture commitment . A required system behavior that still needs deployment evidence.

Customer-controlled Gate path

A customer-controlled Gate path may act only for explicitly configured workloads and policies. Venturi failure always forwards customer traffic.

Negative capabilities

Explicit exclusions are part of the security model.

These boundaries narrow the permission and data surface a reviewer needs to evaluate.

  • 01Read-only connectors do not write to customer production systems.
  • 02Customer telemetry, traces, prompts, outputs, attribution records, and cost records are excluded from the control-plane channel.
  • 03Venturi does not access source code content, credentials, compensation, or performance data for attribution.
  • 04Venturi does not require mandatory inline interception as the default collection path.
  • 05Venturi failure does not block production traffic.
  • 06A customer-controlled Gate path is inactive unless a workload and policy are explicitly configured.
  • 07Low-confidence ownership does not activate Gate.
  • 08Optional aggregated benchmarking requires separate explicit opt-in.

Control-status roadmap

External claims follow completed evidence.

Specified, implemented, tested, independently assessed, and planned are separate states. The table states what evidence is still required before a stronger external claim is allowed.

Control-status roadmap
ControlCurrent stateEvidence requiredExternal claim allowed
Customer data-plane boundarySpecifiedDeployment review and production validationArchitecture commitment
Read-only connector scopeSpecifiedConnector permission review and production validationArchitecture commitment
Fail-open decision pathSpecifiedImplementation evidence, fault tests, and production validationArchitecture commitment
SOC 2 Type IPlannedCompleted readiness work and independent audit reportPlanned only
SOC 2 Type IIPlannedType I completion, observation period, and independent audit reportPlanned after observation period
ISO 27001PlannedCustomer demand, implemented ISMS, and certification auditFuture based on customer demand
DPA and subprocessor documentationPlannedCounsel-approved documents and maintained inventoryPlanned only
Data-subject workflowsPlannedCounsel-approved process and exercised request handlingPlanned only

Security-review request

Request the security review packet.

The request path covers the trust-boundary diagram, control-plane metadata inventory, permission matrix, fail-open diagnostic, negative capabilities, and current control-status roadmap.

  1. Trust-boundary diagram
  2. Control-plane metadata inventory
  3. Read-only permission matrix
  4. Fail-open diagnostic
  5. Negative-capability statement
  6. Control-status roadmap