Yes, you really can have it all. And by “all,” we mean the agility and speed of containers, backed by security you can trust and verify.
Confidential computing isn’t new. The industry rallied around it back in 2019, when the Linux Foundation launched the Confidential Computing Consortium with members including Intel, Google, Microsoft, and Red Hat, to name a few.
Yet for years it stayed a niche technology, until AI made protecting data in use impossible to ignore. The risk of exposing sensitive data and proprietary model IP at runtime became one of the hardest security problems in AI.
This is because encryption only protects data at rest and in transit. The moment a model starts processing sensitive data, that protection falls away.
The three states of data
For regulated enterprises, and for AI providers asked to deploy their models in enterprise environments, that gap is often why promising AI projects never make it past the pilot.
Confidential computing closes that gap by protecting data while it’s in use. But how it’s delivered matters, and teams now have a choice.

Confidential VMs protect an entire virtual machine, so existing applications run unchanged inside a TEE. They are a natural fit for lift-and-shift workloads, complete AI stacks, and teams that manage infrastructure at the VM level.
Many AI teams, though, build, ship, and scale on Kubernetes, and for them the protection needs to come in the same shape as the rest of their pipeline: the pod. That is what Confidential Containers (CoCo) set out to deliver.
CoCo gives confidential computing the shape of a container: your pods run inside lightweight confidential VMs, using TEEs on confidential CPUs and GPUs with no change to your applications.
The right choice depends on the workload, and many organizations will use both. Fortanix supports confidential VMs and confidential containers with the same attestation and key management, so teams can pick the model that fits each use case.
The CoCo project has gained real momentum since. It was accepted to CNCF in March 2022 and moved to the Incubating maturity level in July 2026, with support from many technology leaders.
Like all confidential computing, CoCo assumes the host can’t be trusted, so it relies on a trust layer to attest each TEE and release keys only to verified workloads. With containers, that has to happen for every pod, every time one starts, at the speed Kubernetes moves.
With newly announced support for CoCo, Fortanix Confidential AI delivers the trust layer CoCo needs, all in one unified enterprise platform.
It verifies every pod down to the CPU and GPU through composite attestation. Only then does it release keys from a FIPS 140-2 Level 3 validated HSM.
The platform runs as SaaS, on-premises, or air-gapped, scales across clusters and regions, and is already proven in production with high availability, centralized audit, and 24x7 support.
How confidential containers work
Our customers already run their AI workloads on Kubernetes and don't want to rewrite them for a TEE, so the protection has to fit the pod model. Kata Containers and CoCo do that together by running each pod in its own lightweight confidential VM.
Kata Containers: A lightweight VM around every pod
Standard containers share the host's Linux kernel and are kept apart by namespaces and cgroups, so a container escape lands on the node with every other workload on it. Kata Containers, an open source project formed in 2017 from Intel Clear Containers and Hyper runV, runs each pod inside its own lightweight VM with a dedicated guest kernel. An escape from the container then stops at the hardware virtualization boundary.

Standard containers vs Kata Containers
Kubernetes still sees an ordinary pod. You create a RuntimeClass that points to the Kata handler and set it in the pod spec, and all containers in that pod share one Kata VM. Kata protects the node and the other tenants from the workload. The workload still has to trust the node, because the hypervisor and host can read the VM's memory.
Confidential Containers (CoCo)
Confidential Containers (CoCo) builds on Kata and maps each pod to a lightweight confidential VM, so everything in the pod sits inside its own TEE. On Intel TDX or AMD SEV-SNP hardware, the CPU encrypts and integrity-protects the VM's memory, and NVIDIA confidential GPUs extend that protection to GPU memory, so the host OS and hypervisor fall outside the trust boundary.
CoCo also moves work the host used to do into the guest. Images are pulled and unpacked inside the confidential VM, so the infrastructure owner never handles their contents, and encrypted and signed images get their decryption keys and verification policy only after a successful remote attestation. Inside the guest, the Attestation Agent collects the hardware evidence and the Confidential Data Hub fetches and unwraps secrets once they are released. A Kata agent policy, enforced in the guest, limits which requests the host can send it.
The gap Kata and CoCo close
Kata closes the gap between tenants, and CoCo closes the gap between the workload and the infrastructure under it. With runc, a container escape reaches the node. Kata stops that at the VM boundary, yet whoever runs the node can still read the pod's memory. CoCo takes the host OS, the hypervisor, and the infrastructure operator out of the trust boundary, so a regulated team can run sensitive pods on infrastructure it does not fully control, such as a public cloud, a GPU cloud, or a shared on-prem cluster.

NVIDIA Confidential GPUs
NVIDIA Confidential GPUs are the other key component of this architecture, and NVIDIA's reference architecture for Confidential Containers brings them into the same model. Hopper (H100, H200) and Blackwell (B200) GPUs run in confidential computing mode, and each one is passed into a pod's confidential VM, so model weights and data stay protected in GPU memory too. The GPU produces its own signed attestation report, which NVIDIA’s Remote Attestation Service (NRAS) verifies alongside the CPU evidence.
Fortanix Confidential Computing - Trust Layer

CoCo made it possible to run Kubernetes AI workloads inside TEEs. Moving those workloads into production takes security that holds up at scale and under audit, and that is the part Fortanix adds. Fortanix plugins connect confidential containers to two Fortanix Confidenital AI services, and a workload gets its keys only when both are satisfied.
- Fortanix Confidential Computing Manager (CCM) verifies the confidential VMs that run your AI workloads. Before any encrypted asset is released, CCM performs composite attestation of the CPU and the GPU, so the integrity of both environments is checked.
- Fortanix Data Security Manager (DSM) then provides encryption keys only to TEEs that CCM has verified. If attestation fails, the keys stay locked in DSM and the workload never sees them. The plugins work inside CoCo’s standard workflows, so developers deploy pods the same way they do today.
The platform behind those plugins is built for enterprise-grade production. CCM and DSM run as a clustered deployment designed so key release never becomes a single point of failure, and support is SLA-backed and available 24x7 worldwide from the team that built the platform. DSM is FIPS 140-2 Level 3, and the platform also holds SOC 2 Type 2 and ISO/IEC 27001 certifications. It deploys as SaaS, on-premises, or fully air-gapped, and governments, banks, healthcare providers, technology and retail companies, and cybersecurity firms already rely on it.
For developers, confidential AI workloads now deploy on Kubernetes as fast as the business needs them. Security leaders get protection from the first pod, so teams can take AI to production on standard CoCo without building the trust layer themselves.
Who uses Fortanix Confidential AI
Fortanix Confidential AI serves three kinds of organizations. Each one needs to keep a different party outside the trust boundary.
AI labs
AI labs want to run their proprietary models wherever enterprise customer data lives, including on the customer’s own servers, without giving up their model weights. With confidential containers, the weights stay encrypted until CCM has attested the environment, so the lab’s IP stays protected on infrastructure it doesn’t operate. Speech and voice AI companies such as ElevenLabs, Deepgram, as well as other frontier AI labs such as Resemble AI and Gnani.ai use this pattern. Frontier AI Labs uses it to let government, healthcare, and finance customers run its text-to-speech models on their own servers, on their own data, with Fortanix on NVIDIA Confidential Computing.
AI factories
Operators of shared GPU infrastructure need every tenant to trust that the operator can’t see their data or models. Fortanix makes that trust verifiable: each tenant’s workloads run in TEEs, and DSM releases keys only to workloads that CCM has attested.
Sovereign AI cloud
Governments and regulated industries need highly sensitive data, such as citizen data, to stay out of reach of infrastructure providers, other jurisdictions, and administrators. With Fortanix, the encryption keys stay in an HSM under the sovereign operator’s control, on-premises or fully air-gapped. Attestation then proves what is running and where before any data is decrypted.
Availability
Fortanix support for CoCo is available now. It runs confidential pods on Intel TDX or AMD SEV-SNP, and NVIDIA confidential computing GPUs, and the CCM and DSM side deploys as SaaS, on-premises, or fully air-gapped, so sovereign and disconnected sites can use it without depending on the cloud. You can find more information here.
So yes, you really can have it all: the speed of containers, security you can verify, and the confidence to adopt frontier AI without putting your data or models at risk.

