Security is an architecture decision.
KAVIA is designed to protect customer code and engineering knowledge, govern access and model inference, and keep AI-assisted software change reviewable and under customer control.
Contract-specific commitments, selected providers, regions, service levels and data-processing terms are governed by the applicable agreement.
Your security, residency, model-governance and network requirements determine the configuration.
Protect engineering knowledge
Authorized scope, isolated processing and encryption.
Keep durable outcomes under control
Customer-directed repositories remain the durable destination.
Govern model inference
Approved endpoints, clear boundaries and deployment choice.
Preserve human review
Traceable activity and reviewable software change.
On this page · Trust posture
0%Published security posture
What an enterprise reviewer should understand first.
These statements reflect KAVIA's current public product and deployment posture. Configuration-specific detail is confirmed during architecture review.
- Tenant boundary
- Dedicated customer-isolated VPC for KAVIA Cloud.
- Encryption
- TLS 1.2+ in transit and AES-256 at rest.
- Identity
- SSO/SAML 2.0, RBAC, and team and group controls.
- Retention
- Temporary customer content is customer configured and never retained for more than seven days.
- Model use
- No customer-data training. Approved inference paths use enterprise no-training and zero-data-retention controls.
- Traceability
- Activity logs and traceable run history are available for administrator export.
- Assurance
- SOC 2 Type II is in process.
Need evidence for an architecture review or security questionnaire?
Contact KAVIA
KAVIA Cloud architecture
Dedicated processing. Approved repositories. Customer-directed persistence.
The managed-cloud pattern separates customer-controlled identity and source repositories, a dedicated customer-isolated KAVIA processing environment, and approved model-serving endpoints.
Customer-controlled
Identity & source
Authorized users
Approved repositories
Customer SCM
Dedicated customer-isolated VPC
KAVIA processing
Temporary working copy
System understanding
Workflow execution
Artifact generation
Temporary content: configured period, time restricted
Approved inference path
Model endpoint
Enterprise no-training and ZDR controls
Customer-controlled destination
Customer SCM
Project knowledge and generated artifacts
Important boundary clarification
A dedicated KAVIA Cloud environment does not mean that no data leaves the VPC. Selected task-relevant context is transmitted to the approved model endpoint in configurations that use external inference. Customer-provided and fully self-hosted model options change that boundary.
Temporary processing
Customer SCM remains the source of truth. KAVIA Cloud creates a temporary working copy inside the dedicated customer VPC.
Deleted within the configured period, restricted time period.
Approved inference
Selected task-relevant context may be transmitted to an approved model-serving endpoint.
Enterprise zero-data-retention controls govern the provider inference path.
Durable customer control
Durable project knowledge and generated artifacts are written to customer-designated repositories.
Retention in the designated SCM is controlled by the customer.
Five reference configurations
Choose where processing, storage and inference operate.
KAVIA publishes five deployment configurations. Commercial and implementation details are defined for each engagement.
Configuration
- Application boundary
- Dedicated KAVIA customer VPC
- Storage boundary
- Durable output to customer SCM
- Inference boundary
- KAVIA-approved external endpoints
- Application boundary
- Dedicated KAVIA customer VPC
- Storage boundary
- Durable output to customer SCM
- Inference boundary
- Approved endpoints selected and governed by the customer
- Application boundary
- KAVIA-managed services
- Storage boundary
- Persistent code and artifacts in customer-controlled storage
- Inference boundary
- KAVIA-approved external endpoints
- Application boundary
- KAVIA-managed services
- Storage boundary
- Persistent code and artifacts in customer-controlled storage
- Inference boundary
- Customer-provided endpoint
- Application boundary
- Application and operational services inside customer boundary
- Storage boundary
- Inside customer boundary
- Inference boundary
- Customer-hosted LLM and embedding endpoints
Customer-controlled / self-hosted
Keep the runtime and engineering data inside the approved boundary.
Designed for restricted-network, disconnected, cross-domain and fully air-gapped environments without KAVIA-hosted runtime services, outbound telemetry or public-internet access.
Engineers & reviewers
- Enterprise identity
- Approved scope
Understand → Plan → Change
- Knowledge graph & stores
- Specifications & artifacts
- Activity and run history
Models & engineering systems
- LLM and embedding endpoints
- SCM, build and test
- Keys, logs and observability
Enterprise controls & human governance
Control the people, scope, inference and final decision.
KAVIA capabilities sit inside the customer's existing software delivery and security processes. Generated work remains subject to qualified human review.
Identity & authorization
Enterprise SSO and SAML 2.0, role-based access control, team and group controls, granular environment isolation, and customer-authorized repositories.
Encryption
TLS 1.2+ protects data in transit. AES-256 protects data at rest.
Model governance
KAVIA does not train foundation models on customer code or data. Customers can select governed, customer-provided, or self-hosted model paths.
Activity & traceability
Full activity logs and traceable run history are available for administrator export.
Human review
Sessions and resulting changes remain visible for review, continuation, discard, approval, or merge through the customer's normal delivery gates.
Confidential access
When KAVIA personnel access a customer environment for documented services, use is limited to that purpose and need-to-know personnel bound by written confidentiality obligations.
Shared responsibility
Make the operating split explicit.
Recovery and availability responsibilities change across deployment models. The applicable agreement and implementation runbook define the exact split.
| Area | KAVIA | Customer |
|---|---|---|
| Identity & access | Provide SSO/SAML and RBAC capabilities; isolate customer environments. | Configure the identity provider, groups and roles; review access and deprovision users. |
| Repositories | Connect only to authorized repositories and process the approved scope. | Authorize least privilege; maintain branch protections; review proposed changes. |
| Inference | Use the approved endpoint path and applicable no-training and ZDR controls. | Approve the provider, model and region; govern customer-provided endpoints and contracts. |
| Generated output | Provide reviewable sessions, artifacts and code changes; preserve available activity history. | Perform qualified review; run builds and tests; approve merge and deployment through normal gates. |
| Operations | Operate KAVIA-managed layers for the selected configuration. | Operate selected customer-controlled storage, models, networks, identity, logs, builds, backups and recovery. |
Day 2 operations
Customer control continues after deployment.
Five operating questions platform and security teams should examine before a production decision.
01Replace an approved model
The customer holds the model, license, serving infrastructure and access policy.
02Apply a platform update
The customer holds the transfer process and approval to deploy.
03Recover from a failed change
The customer holds the recovery decision and operating evidence.
04Export audit evidence
The customer holds the logs, retention policy and export approval.
05Operate without hosted runtime services
The customer holds every runtime credential and control in the self-hosted configuration.
Privacy & assurance
Say exactly what has been established.
KAVIA states that customer code and data are not used to train foundation models. Customers retain rights in their code, data and systems. KAVIA publicly describes GDPR- and CCPA-aligned practices; this is not presented as a certification.
Assurance status
SOC 2 Type IIIn processArchitecture review
Bring your security questions and one real engineering workload.
KAVIA will map the deployment boundary, evaluation scope and measurable success criteria with your engineering, platform and security teams.
Version 1.0 · August 2026
This page is informational and does not amend an agreement or create a service-level, security, privacy, compliance or legal commitment. If it conflicts with a signed agreement, the signed agreement controls.