Trust & security

The whole integration is built so you can verify Venturi’s claims rather than trust them. This page is what to tell your security reviewer.

Read-only, enforced three ways

Venturi reads. Venturi does not write into customer environments. That isn’t a promise; it’s enforced at three layers:

1. The runtime identity only receives reads. Setup necessarily creates the integration identity and role bindings; the standing Venturi identity receives only the allowlisted read actions.
2. A platform gate blocks violations from shipping. check_permissions.py runs in the platform’s CI gate stack; an onboarding module that requests any write permission cannot merge to main.
3. You prove it yourself. Every module ships scripts/verify.sh, which exercises one read and one write per granted service. Reads must pass; writes must fail. Any successful write exits the script non-zero. See Verify & confirm.

No long-lived cloud credentials by default

Cloud	Default auth	Secret exposure
AWS	Cross-account AssumeRole, scoped by a per-customer external_id, 15-minute session TTL	No static credentials; nothing exported
GCP	Workload Identity Federation	No service-account keys are ever created; the module refuses
Azure	Federated credential (OIDC)	No secret by default; optional 90-day client-secret fallback, never in outputs

The AWS external_id is a confused-deputy mitigation: Venturi can only assume the role when presenting the exact per-customer string, so a leaked role ARN alone is not enough to assume it.

Least privilege

Each module grants the minimum needed for attribution:

• AWS: Cost Explorer, CUR bucket read (that bucket only), pricing, optional Bedrock metadata, CloudWatch/CloudTrail read, IAM/Organizations listing.
• GCP: bigquery.dataViewer (optionally pinned to one dataset), monitoring.viewer, logging.viewer, serviceusage.serviceUsageConsumer.
• Azure: Reader, Cost Management Reader, Monitoring Reader; optional APIM / Event Hub reads only if you enable them.

No content capture

Some optional provider grants can reach content-bearing logs: Bedrock model invocation logs, GCP request/response logs, and Azure diagnostic streams may contain prompts or completions when a customer has enabled that provider feature. Venturi therefore applies a field allowlist before materialization. It extracts only identity, resource, model, token, cost, timing, and correlation metadata; request/response bodies and content-shaped keys are discarded in memory and are never persisted. Raw provider responses and error payloads are never written to application logs, audit logs, retry queues, or dead-letter storage.

The normalized InvocationEvent schema has no field for prompt or completion text. Scope provider log access to the narrowest log group, dataset, workspace, or Event Hubs namespace that supplies the required metadata.

Fail-open

The decision-time interceptor cannot block your traffic. It runs on a hard latency budget with a wall-clock timeout enforced outside application logic and forwards regardless of Venturi’s health.

You stay in control

• Rotate credentials any time; see Rotate & offboard.
• Revoke instantly with terraform destroy; Venturi loses visibility within minutes.
• Everything Venturi can do is visible in the module source you deployed.

References

• Trust-boundary source document: shared with your security reviewers during onboarding and diligence
• Security policy & vulnerability reporting: Trust center or security@venturi.systems
• Permission gate: scripts/check_permissions.py in the platform repo