Onboard your cloud to Venturi¶
Customer onboarding docs
The attribution layer for enterprise AI. Venturi links AI inference across providers, services, owners, identities, and budgets into one attribution graph — without manual tags. Use these docs to connect a customer cloud, prove the read-only trust boundary, or add request-level attribution.
As you operationalize chargebacks, governance, and adoption on top of that graph, Venturi can earn system-of-record status — that is a destination state you grow into, not a claim we make on day one.
The read-only cloud connector is set up in ~15–30 minutes. Request-level
attribution is additive and needs either InvocationEvent emission or the
drop-in fail-open proxy.
Choose the right path¶
-
I need to connect a cloud
Required for most customers. Deploy a read-only connector, run the verifier, and send the outputs back to Venturi — ~15–30 minutes of hands-on time.
-
I need security review details
Show exactly what Venturi can read, what it cannot change, how verification works, and where customer data stays.
-
I need request-level attribution
Add optional
InvocationEventsubmission or a fail-open proxy after the cloud connector is in place.
What onboarding actually is¶
Venturi reads your cloud's cost, usage, and identity data — it never writes into your environment. There are two integration surfaces; most customers only need the first.
-
1. Connect your cloud (required)
Deploy one small, read-only Terraform module in your AWS, GCP, or Azure account. It grants Venturi scoped
Get/List/Describeaccess to billing, usage, and identity data — and nothing else. A bundledverify.shproves the read-only boundary holds before you hand anything back. -
2. Send events (optional)
For request-level attribution beyond cloud billing data, emit
InvocationEvents directly to the ingestion API, or route provider calls through Venturi's drop-in, fail-open proxy. Both are optional and additive.
The onboarding path¶
Every cloud follows the same six-step shape, so multi-cloud teams see a predictable flow:
graph LR
A[1. Get values<br/>from Venturi] --> B[2. Fill<br/>terraform.tfvars]
B --> C[3. terraform<br/>apply]
C --> D[4. Run<br/>verify.sh]
D --> E[5. Send outputs<br/>to Venturi]
E --> F[6. Venturi<br/>confirms ingestion]
| Step | You do | Time |
|---|---|---|
| 1 | Email [email protected], receive your cloud-specific values |
5 min (mostly waiting) |
| 2 | Fill terraform.tfvars with those values + your bucket/dataset |
5 min |
| 3 | terraform init && terraform apply |
5 min |
| 4 | Run ./scripts/verify.sh to confirm read-only access works |
2 min |
| 5 | Reply with the Terraform outputs (role ARN / SA email / client ID) | 3 min |
| 6 | Venturi validates and starts ingestion (≤ 1 business day) | — |
Why it's safe by design¶
- Read-only, always. Onboarding modules request only
Get/List/Describe. A platform gate (check_permissions.py) blocks any module that asks for a write permission from ever shipping. - You can prove it. Every module ships a
verify.shthat exercises a read and a write per service — reads must pass, writes must fail. Any successful write is a security finding and fails the script. - No long-lived secrets. GCP and Azure default to Workload Identity Federation; no keys are exported. AWS uses external-ID-scoped cross-account assume-role.
- No content capture. Venturi's pipeline never stores prompt or completion text.
- Fail-open. The decision-time interceptor can never block your production traffic.
Read the trust & security model
Pick your cloud¶
-
AWS
Cross-account IAM role: Cost Explorer, CUR bucket, Bedrock, CloudWatch/CloudTrail, identity inventory.
-
Google Cloud
Service account via Workload Identity Federation: BigQuery billing export, Monitoring, Logging, Service Usage.
-
Azure
Service principal via federated credential: Reader, Cost Management Reader, Monitoring Reader.
Need a hand?
Onboarding is white-glove. Email [email protected] at any point and a
human will help you finish. See Support.