Skip to content

Security architecture

Venturi’s security architecture is designed around one principle: a tool that sees your AI traffic must be incapable of harming you with that visibility. This page describes the trust boundary, the read-only integration model, encryption, secrets management, the fail-open guarantee, and the threat model: the controls a security reviewer evaluates before deployment.

The trust boundary

Venturi’s data plane (the decision-time interceptor, attribution processor, attribution store, and serving APIs) is dedicated to 1 tenant. In self-hosted mode it deploys in your cloud account; in SaaS mode Venturi operates it in the residency lane contracted during onboarding. Operational data stays inside that dedicated tenant boundary and is never pooled with another tenant.

Dedicated tenant boundary

Tenant data plane

outbound fetch, signed

Decision-time interceptor

Attribution processor

Attribution store

Serving / query API

Venturi control plane

No inbound connections · no cross-account data replication

The control-plane connection is data-plane initiated. The control plane initiates nothing inbound to your environment and observes none of your transactional data. It exists for three narrow, signed, opt-in functions only:

  • a daily pricing-catalog sync (signed JSON, Ed25519, with a vendored local fallback);
  • a daily software-release check (your own CI/CD pulls the images; there is no auto-update); and
  • opt-in anonymized telemetry (off by default; contains no PII).

Full offline mode is available

Venturi can run with the control plane disconnected entirely. In offline mode you pull signed image and pricing-catalog updates on your own cadence, and Venturi publishes a security-advisory feed so you can prioritize patches. The vendored pricing fallback is bounded and surfaced when it diverges from the live catalog.

This is a hard invariant: per-tenant operational data lives inside the dedicated tenant data plane. The separate control plane receives only signed control traffic and explicitly opted-in de-identified telemetry, never provider credentials or prompt/completion content in plaintext.

Read-only integrations, enforced at three layers

Venturi reads from your systems; it never writes to them. This is not a setting; it is enforced at three independent layers.

Every source-system connector uses read-only scopes only: for example repo:read / read:org for code-ownership data, okta.users.read / okta.groups.read for identity, and Cost Explorer / CUR read for cloud billing. The HRIS poller asserts read-only credentials at construction and refuses to start with write-capable credentials.

The IAM roles attached to Venturi’s workloads contain an explicit Deny on all write actions. The decision-time interceptor’s service account, for example, denies s3:PutObject, s3:DeleteObject, ec2:*, and iam:*. The customer cross-account role is read-only by construction (ce:Get*, cloudwatch:Get*/List*, logs:Get*/Describe*, and read-only CUR access only), and your own security team reviews the IaC before deployment.

A binding permissions check runs in the platform’s CI gate stack: an integration that requests any write permission cannot ship. Read-only is a frozen system invariant: write permissions cannot be added without violating it.

This is a frozen decision

Read-only integration is not a configurable behavior. There is no flag that grants write access. Provider admin keys (where you supply them) are used only for documented read endpoints; the credential store rejects write-capable use. See Residency & subprocessors for the provider-key model.

Encryption

At rest

  • AES-256 at rest across every resource, using customer-managed KMS keys, one key per tenant (see Tenant isolation). Venturi workloads hold only Decrypt and GenerateDataKey on your key, never ScheduleKeyDeletion.
  • All object storage is encrypted, versioned, and denies non-TLS access. The audit bucket additionally carries Object Lock (see Data privacy & retention).
  • Instance and database storage are encrypted: EBS for instance storage, native encryption for Postgres, and at-rest encryption for the event stream.

In transit

  • TLS 1.3 on every service-to-service connection. Internal gRPC traffic uses mutual TLS (mTLS), with each side verifying the other’s SPIFFE identity (X.509-SVID) through a service mesh. Customer-facing REST uses one-way TLS.
  • The data-plane-initiated control-plane path uses mTLS with certificate pinning. A man-in-the-middle attempt fails certificate verification and the data plane refuses the response.
  • Trained attribution-model artifacts are staged from object storage inside your own account, mounted read-only, and hash-verified before they are bound. They are never fetched on the request path. Verification failure refuses the artifact, falls back to the deterministic baseline, and pages on-call rather than loading an unverified model.

Standards basis: TLS 1.3 (RFC 8446), NIST SP 800-52r2, SPIFFE X.509-SVID, and Ed25519 signatures (RFC 8032) for the signed pricing catalog.

Secrets management & rotation

All secrets (source-system API keys, database credentials, JWT signing keys, and provider admin keys) are stored in a managed secrets store (AWS Secrets Manager, or GCP Secret Manager in GCP-native deployments).

  • Pods retrieve secrets at startup via their workload identity role. Secrets are never written to disk and never appear in pod environment manifests.
  • Database credentials rotate every 90 days via automated rotation. Manually-rotated secrets are tracked in an inventory and reviewed quarterly.
  • JWT signing keys are externally managed and rotated, carry a key identifier (kid) to support overlapping-window rotation, and are never generated per-process. Access tokens carry a bounded lifetime.
  • Provider admin keys are stored per-tenant, KMS-encrypted, inside your trust boundary. The Venturi control plane never observes a provider admin key in plaintext, and a log-guard rejects any line that would emit one. When you rotate a provider key mid-month, attribution and budget accumulation continue across the rotation boundary with no billing gap.

The fail-open guarantee

The single most important availability control: Venturi cannot block or degrade your AI traffic under any failure condition.

  • The synchronous decision-time interceptor wraps the hot path in a hard 50 ms P99 end-to-end timeout (a fast index lookup, not inline model inference). On any exception or timeout, the request is forwarded unmodified and the event is logged with null attribution.
  • Where the processor invokes the trained model through a blocking adapter, that adapter enforces a hard 20 ms wall-clock per call, the adapter’s share of the synchronous 50 ms budget, with a per-instance concurrency cap and a circuit breaker that trips to the deterministic heuristic baseline under sustained timeouts. The asynchronous processor’s 100 ms P99 inference budget is a separate figure and never sits on the synchronous path.
  • The bulk of model inference runs off the hot path on the asynchronous processor, under a 100 ms design budget measured at the processor, failing open to the deterministic baseline on any error.

Fail-open is not configurable

Fail-open has no feature flag and cannot be disabled. It is a frozen decision, exercised by an invariant test, and its acceptance gate is a 72-hour sustained-load run that the contract must pass before Venturi represents it externally. The decision-time interceptor’s only runtime dependencies are the cache and the event stream; it never reads the attribution graph directly and never depends on the control plane to let your traffic through.

Because of fail-open, Venturi unavailability never blocks your AI traffic. Venturi’s 99.9% serving-plane SLO bounds attribution availability (your dashboards and queries) and never your ability to send AI traffic. See the fail-open boundary and the engine’s invariants.

Index integrity & freshness

The decision-time interceptor reads only a precomputed attribution index that the processor writes and the interceptor reads (never the other way around). The index carries a freshness timestamp and a maximum-staleness bound; beyond that bound the interceptor emits an honest null attribution rather than a stale guess. Target index freshness is P99 ≤ 90 seconds.

Confidence-bounded outputs

Venturi’s outputs are deliberately bounded so financial and governance decisions never rest on false precision:

  • Operational confidence (coper) is policy-capped at 0.95 at materialization. The cap can be lowered by configuration but a value above 0.95 is rejected at startup, and the attribution data structures raise on any value above the cap.
  • Chargeback eligibility is gated by a single 0.80 floor. Attributions at or above 0.80 are chargeback-eligible; 0.50–0.79 are provisional (labeled, never auto-billed); below 0.50 are estimates excluded from automated workflows.
  • Unknown is reported as unknown: unknown cost is None, never zero; unknown energy is null, never a fabricated number.

For the full confidence model and how to act on each band, see Confidence and evidence.

Threat model

Venturi maintains a STRIDE-based threat model that maps each principal threat to its control and residual risk, exercised by a red-team program committed to run at least annually and on any change to the attribution or confidence-scoring logic.

Threat Control Residual risk
Compromised control plane reaches inbound Outbound-only architecture; no inbound listener; NAT-only egress; full offline mode Low: no inbound path exists by construction
Model-artifact substitution (MITM / poisoned registry) Control-plane→data-plane mTLS + cert pinning; artifact hash + signature verified at load; signed-build provenance and SBOM Low
Cross-tenant exfiltration via the query API Per-tenant stores and keys; TENANT_MISMATCH rejection (property-tested); signature-then-tenant-binding on tokens Low
Support-staff access to tenant data Break-glass only: time-boxed, MFA-gated, audit-logged, customer-notified Low–Medium (human-mediated, audited)
Supply-chain compromise of the pricing catalog Ed25519-signed catalog + vendored local fallback; signature verified before use Low
Credential theft of provider admin keys Keys KMS-encrypted in your boundary; control plane never sees plaintext; log-guard; egress network policy Low
Evidence / feedback poisoning of the learner Feedback authentication; per-update drift bound; calibration re-check with automatic rollback; heuristic-baseline fallback Medium: monitored, auto-fallback
Disputed attribution / override repudiation Append-only audit trail; immutable policy-event writer; pseudonymized actor identifiers Low
Query / ingest API abuse (DoS) Per-tenant quotas and rate limits; processor backpressure; fail-open preserves customer traffic Low
Confidence inflation / ownership spoofing 0.95 cap (rejects higher); 0.80 chargeback floor; per-edge false-high-confidence gate under 1% (non-waivable) Low

The customer-facing API additionally sits behind edge protection (WAF) and rate-limiting, with a documented DDoS posture and an explicit responsibility split between your cloud’s edge and Venturi-configured limits. Malformed events are rejected at the edge of ingest and never partially materialized into the graph.

Supply chain

Every released image carries a signature and a software bill of materials (SBOM); the build verifies provenance (SLSA / NIST SSDF). Dependency and image scanning runs continuously with severity-based remediation SLAs: critical findings remediated within 7 days, high within 30 days. An OSS license inventory with a compatibility allowlist is maintained. The coordinated Vulnerability Disclosure Program is operational. Its monitored security.txt intake and safe-harbor terms give good-faith researchers a private reporting channel. A paid bug bounty is a separate future program.