Kindo cloud
Your cloud or VPC
On premises
Air-gapped
Same platform, same record
What is air-gapped and sovereign AI?
Sovereign AI means your organization decides where AI runs, which models it uses, and who holds the data, credentials, and metadata. Air-gapped AI is the strictest form: the whole workflow runs inside a network with no external connection. Kindo supports both as one AI agent management platform, deployed wherever the workload requires.
Sovereign
Control over location, models, and data
External endpoints allowed only where your policy permits. Credentials, data, and metadata stay with you.
Air-gapped
A disconnected network boundary
Local inference, internal tools, your identity directory. No external model API at all.
with Kindo
One platform, four ways to deploy it
Deployment is a choice, not a different product. Your policy decides what, if anything, connects out.
Deployment
Where Kindo runs
Where models run
What your policy decides
Kindo cloud
Kindo's SOC 2 Type II SaaS
Hosted providers you enable
Which models, which data, per Group
Your cloud or VPC
Your Kubernetes environment
Hosted, or your own endpoints
Region, approved endpoints, data flows
On premises
Your infrastructure
Local, with approved external endpoints if permitted
Which connections, if any, leave the site
Air-gapped
Your disconnected network
Local only, on your GPUs
Everything inside the boundary
Why does AI sovereignty matter now?
The workloads with the most value are often the ones that cannot leave the building: classified and export-controlled data, regulated records, core intellectual property. An AI program that depends on one vendor's cloud stops at exactly those workloads, and the enterprise AI control center has to reach them too.
Data that cannot leave
Contract, regulation, or classification rules out external processing. The workflow has to come to the data.
Model providers change
Approved-vendor lists change. Suppliers have already been required to move off a provider's models. Never depend on one AI lab.
Control must come with it
Moving AI inside the boundary is not the same as governing it. IT, Security, Finance, and Compliance still need one record of what agents did.
Who needs air-gapped or sovereign AI?
Government agencies, defense industrial base companies, regulated enterprises, and any business whose intellectual property cannot be processed outside its own walls. Inside those organizations, four teams own the decision.
IT
Own the environment
Deployment, infrastructure, connectivity, and day-to-day operation.
Security
Set the boundary
Which models, tools, and data each agent may touch, and the DLP that applies.
Finance
See the cost
Inference and platform spend by agent, owner, and team, with budget alerts.
Compliance
Keep the evidence
One audit trail from a SOC 2 Type II platform, mapped to the obligations that apply.
What problems does Kindo solve?
Four reasons sensitive AI workloads stall, and what Kindo does about each. Your network security, identity provider, and existing model servers stay in place.
The workflow needs an external API
Most agent tools assume a hosted model. For restricted data, that is a non-starter.
Kindo → Runs with locally hosted models through the AI Model Gateway. No external call is required.
Your GPU infrastructure and model servers stay yours.
Nobody can say where
data goes
A locally installed tool can still call out. Prompts, retrieved content, and tool results each take their own path.
Kindo → Every model call and data access routes through the gateways, so each path is explicit, policy-checked, and logged.
Your firewall and network monitoring keep their view.
Access rules live in
each tool
Each agent carries its own permissions and credentials, outside your directory.
Kindo → RBAC from Okta, Microsoft Entra, or LDAP. Every agent inherits its operator's permissions; DLP applies per model and per Group.
Your identity provider stays the source of truth.
One provider, hard-wired
Agents built against one model have to be rebuilt when the approved provider changes.
Kindo → Switch models, or use a different model per agent step, without rebuilding the agent.
Validate the workload after a change; Kindo handles context and compatibility.
How does Kindo run inside your boundary?
Kindo's three core capabilities, AI Data Gateway, AI Model Gateway, and Role Based Access Control, run fully on premises, and every deployment option is the same platform. Point your own agents at the gateways, run Kindo's pre-built agents, or both.
Step 1 · The control layer
What turns a location into control
Who may use which model on which data, and a record of every call. Three capabilities, working together.
AI Data Gateway
Every read or write by a person or an agent against your data sources, through MCP connectors Kindo builds itself so they run on premises.
AI Model Gateway
The models you allow, local or hosted, with per-model, per-Group rules on which data each may see and which DLP filters apply.
Role Based Access Control
Who each person is, which Group they belong to, what they and their agents may do, from your own identity provider.
Step 2 · The boundary
Choose how connected the deployment is
Same platform either way. Your policy, not a product edition, decides whether any external endpoint is permitted.
Connected sovereign deployment
Permitted connections, made explicit
Kindo in your cloud, VPC, or data center
Local inference, plus approved external endpoints where policy permits
Keep your existing gateway or model hub; Kindo fronts it and adds DLP, policy, cost, and audit
Air-gapped deployment
The whole workflow inside the boundary
Kindo, models, data, tools, and identity all inside the disconnected network
Local inference on your own GPUs
Software and model updates by your approved transfer process
Step 3 · The infrastructure
Run it on what you already own
Kindo deploys as a Kubernetes service. Identity, state, secrets, retrieval, and the audit logs stay in your hands.
Deployed as
A Kubernetes service via Helm chart: EKS, AKS, OpenShift, Rancher, or bare metal
Identity
Okta, Microsoft Entra, LDAP; SSO over SAML 2.0 and OIDC
You control
State databases, secrets manager (for example HashiCorp Vault or AWS KMS), vector stores for retrieval
Models
Any model, hosted or your own; Deep Hat, Kindo's cybersecurity model, runs locally
Record
One audit trail of every human and AI action; JSON audit logs you keep
Step 4 · The agents
Connect agents by either of two paths
The harness is optional. Agents you already run route through the gateways and keep their governed access; agents in Kindo's harness get step-level control as well, which is the route to full control. Most estates use both.
Any agent, through the gateways
Agents in Kindo's harness
Governed model and data access, DLP, RBAC, cost attribution, call-level record
All of that, plus step-level approval gates inside a run
No gates inside the agent's own steps
Pause, resume, and the full action-level record
Support is the agent vendor's
24x7 operational support and forward deployed engineering
What will you gain?
Restricted workloads reach production, and IT, Security, Finance, and Compliance each get what they need from them.
Reach
A path for restricted workloads
Classified, regulated, and IP-sensitive work runs where the data lives.
Cost
Every token attributed, inside the boundary
Agent FinOps: spend by agent, owner, and team, with budget alerts. Local inference included.
Evidence
One audit trail, from a SOC 2 Type II platform
Every human and AI action, kept by you. Kindo is SOC 2 Type II certified and supports ISO 27001, PCI DSS, HIPAA, GDPR, and NIST CSF programs.
Speed
Pre-built agents, inside the boundary
Kindo's library of pre-built agents for IT and security operations runs where the data lives, from day one.
What those four gains look like on one job
A security team investigating internal telemetry, with no external inference. The example is illustrative; the mechanics are the product.
The job
Investigate internal telemetry
A security team runs one of Kindo's pre-built investigation agents over telemetry from an approved internal source.
How it runs, air-gapped
Deep Hat reasons locally
Deep Hat, on your GPUs, reads the retrieved evidence through the AI Data Gateway; permitted internal tools support the investigation; the analyst reviews the findings.
What leaves the boundary
Nothing leaves the boundary
Prompts, evidence, credentials, and the record stay inside. Finance sees the cost; Compliance sees the trail.
Why choose Kindo for sovereign AI?
Going sovereign has meant giving something up: hosted platforms keep the controls but take your data, and self-hosted model servers keep your data but have no controls. With Kindo you keep both. Three things you get inside your boundary that you cannot get elsewhere together.
The whole control layer
All three core capabilities, on premises
AI Data Gateway, AI Model Gateway, and RBAC from your own directory, all inside the boundary. Not one gateway and a promise.
Same platform, same record
Going sovereign never means going dark
An agent's action in an air-gapped network lands in the same record as one in Kindo cloud, read by IT, Security, Finance, and Compliance, and kept by you. Same SOC 2 Type II platform in every deployment.
Independence
Any model, no rebuild
Local or hosted, including Deep Hat, Kindo's cybersecurity model, on your GPUs. When the approved provider changes, switch models without rebuilding the agent.
Frequently Asked Questions
Can an air-gapped deployment use an external model API?
No. A fully disconnected deployment runs only locally hosted models, and its tools and identity services must be inside the boundary. If a workload needs an external service, that is a connected sovereign deployment, and Kindo's policy decides which endpoints are permitted.
Does running Kindo on premises keep all AI processing local?
Only if your policy says so. Kindo can run on premises while a Group is permitted to use a hosted model for a given workload. The AI Model Gateway makes each permitted endpoint explicit, and the record shows which model handled each call.
Can Kindo govern agents we built elsewhere?
Yes. Issue the agent a Kindo key and its model and data calls route through the gateways: RBAC, DLP, cost attribution, and a call-level record. Step-level approval gates and the full action record apply to agents that run in, or are ported into, Kindo's harness.
Which models can we run locally?
Any model you can host on your own GPUs, including open-weight models and Deep Hat, Kindo's cybersecurity model.
Does a sovereign deployment make a workload compliant?
Deployment location is one control among several. Kindo contributes access policy, DLP, and one audit trail of every human and AI action, which maps to NIST AI RMF and EU AI Act oversight expectations. Kindo is SOC 2 Type II certified and supports ISO 27001, PCI DSS, HIPAA, GDPR, and NIST CSF programs; it does not certify your workload.
What do we need to operate it?
A Kubernetes environment, inference capacity for the models you choose, your identity provider, and your own state, secrets, and retrieval stores. For disconnected operation, an approved process for software and model transfers.
