In the last twelve months, confidential computing has stopped being a research curiosity and started showing up in procurement checklists for hospitals, banks, law firms, and government AI contracts. The pitch is simple: run a large language model on sensitive data inside a hardware-isolated enclave where the cloud operator, the host operating system, and any other tenant on the same physical server cannot read the inference inputs, the model weights, or the outputs. In 2026, that promise is finally backed by chips in production at every major hyperscaler, a mature attestation ecosystem, and a body of CVEs that has taught us where the trust model still has cracks.
This guide is a field-level view of what confidential computing actually delivers for AI workloads, how the three production hardware paths — Intel TDX, AMD SEV-SNP, and NVIDIA H100/H200 Confidential Compute — compare in practice, and the evaluation checklist we use before signing off on an enclave-based inference pipeline.
1. What confidential computing actually means for AI
The phrase "confidential computing" was coined by the Confidential Computing Consortium in 2019 and refers to the protection of data in use — the missing leg alongside encryption at rest and encryption in transit. The implementation is a hardware-enforced Trusted Execution Environment (TEE), commonly called an enclave, that encrypts the CPU and memory state of a guest virtual machine or container while it runs. The host kernel, the hypervisor, and any device driver running at the host privilege level cannot read enclave memory, even if the host is fully compromised.
For AI workloads, three properties matter more than the rest: encryption of model weights that you would rather not leak to the cloud operator, attestation that proves the running binary and configuration match a known good state before any data is decrypted, and sealed-key release that hands data to the enclave only after attestation succeeds. The big shift in 2025-2026 is that all three of those properties are now available on commodity server hardware, not just research-only SGX parts, and that the attestation step integrates with the rest of the modern CI/CD pipeline.
2. The three hardware paths in production
Intel TDX (Trust Domain Extensions) ships on every 4th- and 5th-gen Xeon Scalable data centre CPU. TDX runs a full virtual machine inside an encrypted Trust Domain, with the host hypervisor deliberately excluded from the trust boundary. Attestation is delivered through Intel Trust Authority (formerly Project Amber) and the quote can be verified against a hardware root of trust. For AI teams, TDX's main advantage is operational simplicity: you boot a confidential VM the same way you boot a normal VM, then verify a quote before connecting.
AMD SEV-SNP (Secure Encrypted Virtualization — Secure Nested Paging) is the equivalent path on EPYC 9004 (Genoa) and 9005 (Turin) processors. SNP adds memory integrity protection on top of SEV's memory encryption, which closes a class of ciphertext-replay attacks that earlier SEV-ES parts suffered from. For teams already standardising on EPYC for cost reasons, SNP is the natural fit. The main thing to verify is that your BIOS, firmware, and hypervisor combination is on AMD's published security bulletin list — several 2024 and 2025 advisories only applied to specific firmware revisions.
NVIDIA H100/H200 Confidential Compute (CC) is the new piece. Starting with H100, NVIDIA's Hopper parts can run GPU compute inside a hardware TEE that protects both the GPU memory and the on-die data path between CPU and GPU. The model weights stay encrypted in VRAM, and PCIe traffic between the CPU enclave and the GPU enclave is protected by a hardware session key. For LLM inference, this is the most consequential development of the cycle, because the model itself is the IP and the new attack surface. If you are paying for H100 capacity on a public cloud in 2026, ask your provider whether the CC mode is available and at what price premium — it is usually 8-15% over a normal H100, which is a rounding error for regulated workloads.
3. Remote attestation: the piece that actually takes work
Encryption of memory is the easy half. The hard half is attestation: a third party has to be able to cryptographically verify that the binary running inside the enclave is exactly the binary the data owner expects, that it is running on a genuine TEE-enabled chip with current microcode, and that the secrets will only be released to that verified configuration. The three reference implementations in 2026 are Intel Trust Authority, AMD's SEV attestation service, and the cross-platform verification services that abstract over both, with NVIDIA's NV-Attestation joining for GPU enclaves.
The trap we see teams fall into is treating attestation as a one-time event. In practice, the platform needs continuous re-attestation — a successful quote at boot does not prove the enclave is still in a good state thirty minutes later. Build re-attestation checks into the orchestrator (Kubernetes admission controllers are the common pattern) and reject any pod whose quote has expired or whose measurement no longer matches the signed image you approved.
4. The trust gaps that still exist
Confidential computing does not eliminate every threat. The four gaps we explicitly call out in our own threat models: side-channel attacks on the CPU (downfall, Reptar, spectre-class issues still ship, even in 2026 microcode), DMA from peripherals that have not been IOMMU-isolated, supply chain compromise of the signed enclave image itself, and the I/O path. The model and the prompt are protected while in CPU and GPU memory, but the moment you write an output to a log file, a database, or a downstream API, it is back to the mercy of whatever you have set up there. Plan for that explicitly — encrypted downstream storage, mTLS to the next hop, and strict access logs on the egress side.
A common procurement mistake is to assume that buying a TDX-capable server is the same as running a confidential workload. The hypervisor, the guest kernel, the orchestration layer, the attestation service, and the signed image pipeline are all separate decisions and all matter. The CCC's published seven-step adoption guide and the NCC Group's 2025 audit report are the best starting points for an internal due-diligence checklist.
5. A practical evaluation checklist for an AI inference deployment
If you are evaluating confidential computing for a real inference workload in 2026, walk this list before you sign the contract. First, confirm the chip generation and microcode revision on the target server, and ask the provider for a recent attestation quote — not a marketing claim. Second, verify that the model weights are sealed to a specific enclave measurement, not just encrypted at rest with a key the cloud operator holds. Third, check that the attestation service is operated by a party you are willing to trust with quote issuance, and that the verifier side can run on infrastructure you control. Fourth, run a red-team exercise that assumes a malicious host operator and try to exfiltrate a sentinel token through every I/O path you have. Fifth, budget for the 8-15% performance and price premium and treat it as a compliance line item, not an engineering surprise.
For self-hosted stacks, a managed UPS battery backup on the host running the attestation service is non-negotiable — if the verifier box loses power mid-quote, your orchestrator will assume the enclave is compromised and refuse to hand it the sealed key. That is the correct behaviour, and you want the battery to keep the lights on long enough to fail over cleanly.
The bottom line
Confidential computing is no longer experimental. Intel TDX, AMD SEV-SNP, and NVIDIA H100 CC together cover the full CPU-and-GPU path for a regulated LLM inference workload, and every major cloud now offers at least one of the three at production scale. The remaining work is on the operations side: continuous re-attestation, signed-image pipelines, I/O path hardening, and an honest threat model that names the side-channels, the DMA path, and the egress log. If you have a use case that previously said "we cannot put that data in the cloud", 2026 is the year to revisit that decision — with the right threat model and the right checklist, the trust boundary you actually need is now a SKU.
Affiliate Disclosure: GeniusTechLab is reader-supported. When you purchase through links on our site, we may earn an affiliate commission at no extra cost to you. Our recommendations are based on hands-on testing and editorial judgment, not commission rates.