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 gateway, the attribution processor, the attribution store, and the serving APIs — deploys inside your own VPC, in your own cloud account. Your transactional and AI-invocation data lives there and never leaves it.

graph LR
  subgraph Your cloud account
    subgraph Your VPC
      GW[Gateway / interceptor] --> PR[Attribution processor]
      PR --> ST[(Attribution store)]
      ST --> API[Serving / query API]
    end
  end
  CP[Venturi control plane] -. outbound-only, signed .-> GW
  Note[No inbound connections · no cross-account data replication]

The control plane is outbound-only. It 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 data — AI-invocation events, the attribution graph, source-system reads — lives entirely within your VPC, and the control plane "sees only attribution records," never your transactional data or provider credentials 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 gateway 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 control-plane-to-data-plane path uses mTLS with certificate pinning. This is the path by which a trained attribution model reaches the data plane; a man-in-the-middle attempt fails certificate verification and the data plane refuses to load the artifact.
  • Model artifacts are hash- and signature-verified at load. A mismatch fails open and pages on-call rather than loading an unverified artifact.

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 gateway 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 asynchronous processor invokes the trained model through a blocking adapter, that adapter enforces a hard 20 ms wall-clock per call as its share of the 50 ms budget, with a per-instance concurrency cap and a circuit breaker that trips to the deterministic heuristic baseline under sustained timeouts.
  • 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 validated by a 72-hour sustained-load test with zero failures. The gateway'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, customer-traffic availability is effectively ~100%. 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 gateway reads only a precomputed attribution index that the processor writes and the gateway reads (never the other way around). The index carries a freshness timestamp and a maximum-staleness bound; beyond that bound the gateway 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 standing red-team program that runs 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, and a coordinated Vulnerability Disclosure Program with a published security.txt (RFC 9116) and safe-harbor for good-faith research gives external researchers a defined intake.