Timeout
- Venturi behavior
- Skip enrichment when the 50ms budget is exhausted
- Customer traffic
- Request proceeds unmodified
- Operator visibility
- timeout event and latency bucket
- Follow-up action
- review index freshness and interceptor budget
Security
A narrow trust boundary, built for review.
The attribution graph, index, HRE, decision-time interceptor, and records all run inside the customer environment. Connectors are read-only.
Read-only connectors resolve attribution without asking teams to rewrite production systems, add manual tags, or expose source content.
Trust boundary
Customer environment first. Vendor control plane narrow.
Customer environment
customer VPC01
Read-only connectors
billing, identity, CI/CD, source control, telemetry
02
Attribution graph
immutable events, derived state, evidence lineage
03
Attribution index
precomputed lookup for decision-time path
04
HRE
heuristic reconciliation with confidence preservation
05
Decision-time interceptor
50ms budget, reads the attribution index
06
Shape recommendations
advisory enrichment by default
07
Gate opt-in path
workload-specific and customer-controlled
08
Customer-controlled storage
customer encryption and residency boundary
If enrichment cannot complete within budget, the request proceeds unmodified. The interceptor never traverses the graph in the decision-time path.
Never crosses boundary
- raw telemetry
- prompts
- outputs
- traces
- attribution records
- cost data
- source code
- salary or performance data
Review snapshot
What runs where, and what never leaves, at a glance.
Security review starts with deployment boundary, connector posture, exported data, fail-open behavior, and whether any workload has explicitly opted into Gate.
- Deployment
- customer VPC
- Connectors
- read-only
- Raw telemetry
- never leaves customer environment
- Prompts and outputs
- not exported
- Attribution records
- customer-controlled
- Source code
- not accessed
- HCM data
- org hierarchy only
- Fail-open
- request proceeds unmodified
- Shape
- advisory by default
- Gate
- explicit opt-in per workload
- Control plane
- license, deployment metadata, version updates, configuration sync
Read-only connector model
Permissions are reviewable by system, data used, and excluded data.
Venturi asks for the narrowest read-only scope that can produce useful attribution coverage. Any expansion should be reviewed against the permission matrix.
Permission matrix
Requested access, excluded data, and expansion triggers.
- AWS, Azure, GCP
-
billing read, monitor read, cost API read
Data used, excluded data, and review triggers
- Data used
- cost, usage, vendor project, account hierarchy
- Explicitly excluded
- resource modification, secrets, workload writes
- Review required
- new account or expanded scope
- GitHub, GitLab
-
repository metadata and ownership read
Data used, excluded data, and review triggers
- Data used
- CODEOWNERS, repository, commit and deployment metadata
- Explicitly excluded
- source code content
- Review required
- source-content request is not part of default scope
- Okta, Azure AD
-
user, group, and service identity read
Data used, excluded data, and review triggers
- Data used
- identity, group, service account, org path
- Explicitly excluded
- identity writes, password data, authentication mutation
- Review required
- new identity source or write scope
- Workday or HCM
-
limited org hierarchy read
Data used, excluded data, and review triggers
- Data used
- team membership, manager chain, budget hierarchy
- Explicitly excluded
- salary, performance, sensitive HR data
- Review required
- any field outside hierarchy and team membership
- CI/CD
-
deployment metadata read
Data used, excluded data, and review triggers
- Data used
- deploy SHA, service ID, release timestamp, environment
- Explicitly excluded
- deployment mutation and approval writes
- Review required
- write action or release gating request
Fail-open behavior
Every failure condition preserves customer traffic.
Fail-open is absolute. Timeout, service error, unavailable attribution index, connector degradation, policy lookup failure, and low confidence all produce the same traffic behavior: request proceeds unmodified.
Fail-open diagnostic
Failure produces operator evidence, not production blocking.
Service error
- Venturi behavior
- Return no decision artifact
- Customer traffic
- Request proceeds unmodified
- Operator visibility
- service health event
- Follow-up action
- inspect service dependency and retry status
Attribution index unavailable
- Venturi behavior
- Do not query the attribution graph at decision time
- Customer traffic
- Request proceeds unmodified
- Operator visibility
- index unavailable diagnostic
- Follow-up action
- restore index materialization
Show all 6 failure conditions
Connector degradation
- Venturi behavior
- Use last known evidence only for observation
- Customer traffic
- Request proceeds unmodified
- Operator visibility
- connector degradation row
- Follow-up action
- refresh connector scope or schedule
Policy lookup failure
- Venturi behavior
- Do not apply Gate policy
- Customer traffic
- Request proceeds unmodified
- Operator visibility
- policy lookup diagnostic
- Follow-up action
- review workload policy configuration
HRE confidence below threshold
- Venturi behavior
- Mark record unknown or contested
- Customer traffic
- Request proceeds unmodified
- Operator visibility
- confidence-state row
- Follow-up action
- add evidence or route human review
| Failure condition | Venturi behavior | Customer traffic | Operator visibility | Follow-up action |
|---|---|---|---|---|
| Timeout | Skip enrichment when the 50ms budget is exhausted | Request proceeds unmodified | timeout event and latency bucket | review index freshness and interceptor budget |
| Service error | Return no decision artifact | Request proceeds unmodified | service health event | inspect service dependency and retry status |
| Attribution index unavailable | Do not query the attribution graph at decision time | Request proceeds unmodified | index unavailable diagnostic | restore index materialization |
| Connector degradation | Use last known evidence only for observation | Request proceeds unmodified | connector degradation row | refresh connector scope or schedule |
| Policy lookup failure | Do not apply Gate policy | Request proceeds unmodified | policy lookup diagnostic | review workload policy configuration |
| HRE confidence below threshold | Mark record unknown or contested | Request proceeds unmodified | confidence-state row | add evidence or route human review |
Shape and Gate
Advisory by default. Enforcement only by explicit workload opt-in.
Shape and Gate are separate paths. Optimization runs on Shape, the default advisory path. Gate is the only enforcement path: workload-specific, customer-controlled, and never enabled by default.
default
Shape mode
Advisory recommendations, approval enrichment, budget context, review routing, and optimization options.
explicit opt-in
Gate mode
Workload-specific, customer-controlled, never enabled by default, and never activated by low-confidence ownership.
What Venturi does not do
Negative capabilities are part of the security model.
Each line is a commitment you can hold the deployment to. Where a capability is absent by design, it is listed here rather than left implied. Absence is a product commitment: no prompt export, no source-code access, no HR performance data, and no write path to customer systems.
- Does not write to production systems through read-only connectors.
- Does not train third-party models on customer prompts, telemetry, traces, attribution records, or cost data.
- Does not send raw telemetry to the Venturi control plane.
- Does not send attribution records to the Venturi control plane.
- Does not require mandatory inline interception for every model call.
- Does not block production traffic on failure.
- Does not treat Gate as enabled unless explicitly configured by the customer.
- Does not access source code content.
- Does not access salary or performance data.
- Does not claim certainty when evidence is incomplete.
Compliance roadmap
Compliance claims stay qualified until complete.
Review us on the implemented trust boundary today; treat certifications as roadmap until the relevant audits are complete. Venturi should be reviewed on the implemented trust boundary now and the planned trust-center work separately.
- SOC 2 Type 1
- planned
- SOC 2 Type 2
- planned after Type 1 readiness
- ISO 27001
- future based on customer demand
- Subprocessor documentation
- planned with formal trust center
- DPA and data-subject workflows
- planned with legal counsel
Security review packet
Everything a reviewer needs, assembled as one packet.
This page is structured as a procurement artifact, not just marketing. Each item below maps to a section above. Security review materials are available on request for a deeper read.
- Trust boundary diagram what runs in the customer environment and what stays out
- Read-only permission matrix requested scope, excluded data, and expansion triggers by system
- Data exclusion list the negative capabilities Venturi commits to
- Fail-open behavior failure condition, Venturi behavior, and customer traffic outcome
- Compliance roadmap implemented today versus planned, with no premature certification claims
- Contact for review a named path to walk one workload against the trust boundary
Design partner review
Review one workload against the trust boundary.
No production data is required for the first conversation. Start with one workload, one unclear owner or budget path, and the decision your team cannot make confidently today.
Useful starting points
- Spend owner AI spend is rising but ownership is unclear
- Shared identity a shared key or service account lacks an accountable owner
- Model change a model migration has unresolved cost and quality tradeoffs
- Budget path a budget review cannot tie AI spend to services or teams