Confidential computing has spent years as a CPU story. The hardware mechanisms that protect data while it is being processed — not just at rest on disk or in transit over the network, but live, in memory, during computation — matured first on processors, where Intel and AMD built trusted execution environments into their server lines. The arrival of these protections on GPUs is what makes confidential computing newly relevant to AI, because AI workloads are GPU workloads, and until recently the most sensitive part of an AI deployment was also the part the technology could not protect.
By 2026 that gap has closed enough to make confidential AI a practical option rather than a research demonstration. The combination of confidential GPU modes on NVIDIA’s Hopper and Blackwell generations with the CPU-side foundations of Intel TDX and AMD SEV-SNP gives organizations a way to run AI workloads on shared GPU infrastructure while keeping the model and the data shielded from everyone else — including the infrastructure operator.
The Problem Confidential Computing Solves
Conventional security protects data in two of its three states. Encryption at rest protects data on storage; encryption in transit protects it on the network. The third state — data in use, decrypted in memory while the processor operates on it — has historically been unprotected. Anyone with sufficiently privileged access to the machine, including the cloud operator and a compromised hypervisor, could in principle read it.
For most workloads that exposure was an accepted risk. For AI workloads it is increasingly unacceptable, for two distinct reasons.
The first is the data. Training and fine-tuning frequently use sensitive, regulated, or proprietary datasets — patient records, financial transactions, confidential business data. Processing that data on shared infrastructure means it sits decrypted in memory on hardware the organization does not exclusively control.
The second, and more novel, is the model itself. A trained model represents substantial investment and competitive value, and during inference the model weights are loaded into GPU memory in the clear. On shared infrastructure, that is a high-value asset exposed in a place the owner does not fully control. Model theft — extracting the weights of an expensively trained model — is a real concern that conventional encryption does nothing to address, because the weights have to be decrypted to be used.
Confidential computing extends protection to data in use. A trusted execution environment establishes an encrypted, integrity-protected region of memory that even privileged software outside it — the operating system, the hypervisor, the cloud operator’s tooling — cannot read or tamper with. Applied to AI, this means the dataset and the model weights remain protected even while the GPU is actively computing on them.
The Hardware Stack
Confidential AI requires the protection to span both the CPU and the GPU, because an AI workload moves data between them. The pieces that make this work as of 2026:
CPU trusted execution environments establish the confidential VM that anchors the workload. Intel’s Trust Domain Extensions (TDX) and AMD’s Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) provide confidential virtual machines whose memory is encrypted and isolated from the hypervisor and host. This is the mature, CPU-side foundation that has been deployable for a while.
Confidential GPU modes are the newer and more decisive addition. NVIDIA’s confidential-computing capability, available on the Hopper and Blackwell generations, allows the GPU to operate as part of the trusted environment: data transferred between the confidential CPU VM and the GPU stays encrypted across the link, and the GPU’s memory holding the model and data is protected. Without this, the GPU would be the gap in the chain — the one place where the protected data had to be exposed to be useful. The confidential GPU modes close that gap.
Attestation ties it together. Before an organization trusts an environment with its model and data, it needs cryptographic proof that the hardware is genuine, the confidential mode is actually engaged, and the software loaded into the environment is the expected, unmodified code. Attestation provides that proof, and it is the mechanism that lets a workload owner verify the protection is real rather than merely claimed. Without attestation, confidential computing is a promise; with it, it is a verifiable property.
Confidential AI in Practice
Several use patterns motivate the technology, and they are worth distinguishing because they protect different parties.
Protecting your data on someone else’s infrastructure. An organization runs training or inference on shared GPU cloud capacity but keeps its sensitive dataset shielded from the provider. This is the data-residency-and-sovereignty case extended down to the in-use state: not just “my data stays in this jurisdiction” but “my data is unreadable even to the operator of the hardware it runs on.”
Protecting your model when others run it. A model owner lets a customer run inference on its proprietary model without exposing the weights to that customer — the model runs in a confidential environment the customer cannot inspect. This enables business models around valuable models that would otherwise be impossible to deploy on infrastructure the owner does not control.
Multi-party computation on combined data. Several parties contribute sensitive data to a shared AI workload — collaborative model training across organizations that cannot share raw data with each other — with confidential computing ensuring no party, and not the operator, sees the others’ inputs. This is the most ambitious pattern and the one with the most regulatory and competitive friction to work through, but it is the one confidential computing uniquely enables.
These patterns connect directly to the open private-cloud developments of recent months. The confidential-computing capabilities arriving in open cloud-management platforms mean an organization can build this protection into infrastructure it operates itself, rather than relying solely on a hyperscaler’s confidential-AI offering. The combination — open private cloud plus confidential GPU computing — is a notably strong sovereignty posture: the organization controls where the workload runs and the operator cannot see inside it.
The Limits Worth Knowing
Confidential computing is a powerful tool, and it is also frequently oversold. The honest boundaries:
It protects data in use; it does not make a workload secure. A confidential environment running vulnerable code is still vulnerable through that code. Confidential computing protects against the infrastructure and the operator; it does not protect against bugs in the application running inside the enclave.
The trusted computing base still matters. The protection rests on trusting the hardware vendor’s implementation and the attestation chain. A flaw in the TEE implementation itself undermines everything built on it, and such flaws have been found in earlier generations of the technology. The trust is reduced, not eliminated — relocated from the operator to the hardware vendor.
There is a performance cost. Encryption and integrity protection of memory, and the encrypted CPU-GPU transfer path, impose overhead. For some AI workloads it is modest; for memory-bandwidth-bound workloads it can be more noticeable. It should be measured for the specific workload rather than assumed negligible.
Attestation is operationally demanding. Verifying attestation correctly, managing the trust roots, and integrating attestation into deployment pipelines is real engineering work. Confidential computing that does not actually verify attestation provides a false sense of security — the attestation step is the part that turns the protection from claimed to proven, and skipping it defeats the purpose.
Conclusion
Confidential computing has crossed from a CPU-only capability into something that meaningfully protects AI workloads, because the protection now extends across the GPU where AI computation actually happens. The technology addresses a genuine and growing concern — keeping sensitive data and valuable models shielded even while in use on shared infrastructure — and it pairs naturally with the open private-cloud platforms that have recently added the same capability. The cautions are real: it protects data in use rather than making workloads secure, it relocates rather than eliminates trust, and attestation must be done properly to mean anything. Used with those limits understood, it closes one of the last gaps that kept the most sensitive AI workloads off shared infrastructure, and it strengthens the case for running AI on infrastructure an organization controls.
Further Reading
- Confidential Computing Consortium — the Linux Foundation project defining standards, terminology, and open-source implementations for trusted-execution-environment computing.
- NIST — Hardware-Enabled Security — guidance on hardware roots of trust and attestation, the foundations on which confidential computing’s guarantees rest.