Confidential Computing: What TEEs Actually Protect

Encryption at rest and in transit is table stakes now, every serious platform does both without anyone asking. What most teams still overlook is the gap in between: the moment data is actually being computed on, it has to be decrypted in memory, and until recently that meant trusting the entire stack underneath your application, the OS, the hypervisor, and the cloud provider’s own staff, not to look. Confidential computing closes that gap, and for AI workloads specifically, it has gone from a niche compliance checkbox to a real deployment requirement.

The gap it actually closes

Standard cloud security assumes a chain of trust: you trust the cloud provider’s hypervisor to isolate your virtual machine from other tenants, and you trust the provider’s operators not to inspect what’s running inside it. That assumption has held up reasonably well for most workloads, but it’s an assumption, not a cryptographic guarantee, and it breaks down for data with strict regulatory or contractual protection requirements.

A trusted execution environment (TEE) removes that assumption from the equation. Intel TDX and AMD SEV-SNP create a hardware-isolated region of the CPU where memory is encrypted with keys the hypervisor itself never has access to. Code and data inside the TEE are opaque to everything outside it, including a compromised host OS or a malicious cloud administrator with root access to the physical machine. NVIDIA extends the same principle to GPU memory on its Hopper, Blackwell, and Rubin architectures, which matters because AI workloads spend most of their compute time on the GPU, not the CPU.

The other piece that makes this useful in practice, not just theoretically secure, is attestation. A TEE can produce a cryptographic proof of exactly what code is running inside it, signed by the hardware itself. A customer sending data into someone else’s infrastructure can verify that proof before trusting the enclave with anything, rather than taking the provider’s word for what’s actually running.

Why AI workloads specifically

The pattern driving adoption is straightforward: enterprises increasingly want to run inference or fine-tuning against a third-party model, hosted by an AI provider, a cloud vendor, or an inference platform, using data they can’t expose to that provider’s own staff or infrastructure. Health records processed through a diagnostic model, financial data feeding a fraud-detection pipeline, proprietary source code sent to a coding assistant: all of it involves handing sensitive data to infrastructure the sender doesn’t operate.

Without a TEE, that handoff requires trusting the provider’s access controls and contractual promises. With one, the provider’s own operators are cryptographically locked out of the plaintext data during processing, and attestation lets the customer verify that claim rather than accept it on faith. That’s the shift behind estimates that a majority of enterprises processing sensitive AI data will require TEE-based isolation as a deployment condition, up sharply from a few years ago, driven by the same pressures pushing zero trust architecture into the mainstream: don’t extend trust by default, verify it cryptographically instead.

There’s a second driver specific to AI: multi-tenant inference. A single GPU cluster serving inference for many customers simultaneously is efficient for the provider and a genuine risk for the customer if isolation between tenants isn’t airtight. Confidential GPU computing makes that isolation a hardware property instead of a purely software one.

What the major providers actually ship

This isn’t a research concept anymore, it’s a shipping product across the major clouds, though still opt-in rather than default:

• Azure Confidential Computing offers confidential VMs backed by AMD SEV-SNP and Intel TDX, plus confidential containers and a confidential ledger service for auditable, tamper-evident logging.
• Google Cloud provides Confidential VMs and, more recently, Confidential GKE Nodes on its accelerator-optimized machine series, extending confidential computing to GPU-backed Kubernetes workloads.
• NVIDIA ships confidential computing mode across Hopper, Blackwell, and now Rubin-generation GPUs, letting a workload move into a protected enclave without code changes in most cases.

Adopting any of these means choosing a specific instance type or node pool at deployment time, not flipping a global setting. That’s a real integration decision, not a checkbox.

What it doesn’t protect against

Confidential computing is a strong layer, not a complete answer, and treating it as one leads to a false sense of security.

It doesn’t protect against bad code running inside the enclave. If the application processing your data has a vulnerability or the model provider has built in logic you didn’t intend, the TEE faithfully protects that flawed process from outside observation. It’s isolation, not correctness.

It doesn’t protect against a provider acting in bad faith at the source. Attestation proves what code is running, but it can’t prove intent behind code a provider wrote to look benign while doing something else. Attestation raises the cost of doing that undetected; it doesn’t make it impossible.

It’s not immune to side-channel attacks. TEEs have had documented timing and speculative-execution vulnerabilities over the years, the same general category of hardware-level side channel that has affected CPUs broadly. Confidential computing meaningfully raises the bar for an attacker, it doesn’t eliminate the category of risk entirely.

Where the overhead is worth it

Confidential computing costs something real: reduced instance selection, added latency in some configurations, and deployment complexity beyond a standard VM or container. That overhead is worth carrying when you’re processing regulated data (health, financial, government) on infrastructure you don’t fully control, when a customer contract specifically requires provable data isolation, or when you’re running inference on genuinely sensitive proprietary data through a third-party model provider.

It’s not worth defaulting to for workloads processing already-public or low-sensitivity data. The right move is treating it the way you’d treat any other security control with a real cost, matched to the specific data and threat model at hand, not applied uniformly because it sounds like the safer choice. If your team is evaluating where sensitive data touches third-party AI infrastructure, that’s a scoping exercise worth doing deliberately, the same kind of review our team runs for clients assessing cloud security posture before a new integration goes live.