About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
Confidential computing, in the Confidential Computing Consortium's definition, is the protection of data in use by performing computation in a hardware-based, attested trusted execution environment. For an inference server that means the weights and the prompt can stay unreadable to the host operating system and the hypervisor, for as long as they remain inside that environment and on a path the environment actually protects. Attestation is the evidence you check before you believe you are in that environment.
An AI writing system produced this article for NetLeverage's editorial studio. No GPU was attested and no confidential VM was started. Commands below are the ones NVIDIA's deployment page documents. They were not run.
Why it matters
Encryption at rest protects a file on disk. TLS protects a file on the network. Neither one protects the weights after they have been decrypted into memory so a GPU can multiply them. The host administrator, the hypervisor, and another tenant on the same machine are exactly the parties who can see ordinary memory. The Consortium's technical analysis (v1.3, updated November 2022) puts those parties inside the set of unauthorised entities a TEE is meant to resist, including someone with physical access, and it says the point of the three properties is that the computation you attested is the computation that ran.
A model owner who ships weights to someone else's machine is betting on that distinction. The bet is false if they release the decryption key before checking evidence, if the GPU path they chose does not encrypt the link they think it encrypts, or if the bug is inside the guest, which the TEE treats as trusted.
How it works
What a TEE claims
The Consortium defines a TEE by three properties:
- Data confidentiality. Unauthorised entities cannot view data while it is in use inside the TEE.
- Data integrity. They cannot add, remove, or alter that data.
- Code integrity. They cannot add, remove, or alter the code executing in the TEE.
Attestation is how a verifier, who may be remote, gets an authentic, accurate, and timely report of the software and data state of the attester. The analysis sketches a hardware-backed exchange: a channel, a challenge from the verifier, evidence gathered and signed by a trusted hardware component together with that challenge, and an appraisal against reference values. The signature is meant to be unforgeable by anyone who does not hold the hardware's key. A fresh challenge is what stops a replay of yesterday's good report. The report speaks about the state at the time the evidence was generated. It does not keep watching.
The same paper is explicit about what sits outside the promise. Sophisticated physical attacks, such as long-term invasive probing of the chip, are out of scope. Availability attacks, including someone simply turning the machine off, are out of scope. Side channels are not solved by the definition. The analysis says the confidentiality claim assumes there is no exploitable side channel, that researchers have found side channels in TEE designs that were treated as theoretical, and that closing them is shared work for the silicon vendor, the library author, and the application. A method that takes a different amount of time, or a different amount of power, for a 0 bit and a 1 bit leaks the bit to anyone who can measure that difference. Some of those measurements are software-only.
Where the CPU TEE stops and the GPU starts
NVIDIA's trust-and-threat-model page, opened 10 November 2026, places the CPU TEE on Intel TDX or AMD SEV-SNP, and then extends protection to GPUs that are passed through to a confidential VM. The CPU hardware blocks the GPU from reading the VM's private memory directly. The documented bridge is a bounce buffer in shared memory. The guest driver, which sits inside the CPU TEE, moves data through that buffer. On the modes that use it, the bytes in the shared buffer are ciphertext. Private VM memory stays under the CPU TEE.
The same page corrects a common picture of GPU memory. Inside GPU memory, hardware access controls protect plaintext data. GPU memory encryption is not the protection mechanism. The guest driver holds a protected session with each GPU. Each GPU is assigned whole to one VM. MIG, MPS, and GPUDirect RDMA are not part of the confidential configurations that page describes.
Three modes, from that page and from white paper WP-12554-001 v1.3 (14 August 2025), do not protect the same wires:
| Mode | CPU to GPU | GPU to GPU |
|---|---|---|
| Single-GPU confidential mode, Hopper or Blackwell | Encrypted | Not applicable |
| Multi-GPU confidential mode, Blackwell | Encrypted | Encrypted over NVLink |
| Multi-GPU protected PCIe, Hopper | Encrypted | Unencrypted over NVLink |
The white paper says the Hopper protected-PCIe mode is for an eight-GPU, four-NVSwitch, air-cooled HGX Hopper system, with all eight GPUs passed through to one VM. CPU-to-GPU traffic uses bounce buffers. NVLink traffic in that mode is not encrypted. NVIDIA's threat-model page says the assessment then has to include the fabric, the NVSwitch, and physical access. Encrypting the PCIe path does not make the NVLink path confidential. On Blackwell, the white paper says NVLink can be encrypted as well, and that a compatible CPU, GPU, every PCIe switch in the path, firmware, and driver can use inline encryption (TDISP/IDE) instead of a bounce buffer. The same white paper still describes inline encryption as future work on page 21; verify support for the actual platform and release. Those are configuration claims. They are not true of every card that says Hopper or Blackwell on the box.
CC-On is the mode in which the restrictions are actually on. The threat-model page says management interfaces then expose limited health information, JTAG is disabled, and performance counters are blocked, because counters can be used to infer what the device is doing. CC-DevTools turns profiling access back on. The white paper says encryption paths and bounce buffers stay in place in that development mode, and counters are unblocked. A production policy that needs the counter restriction has to reject CC-DevTools. A report that says the GPU is "in a confidential mode" is not enough if the mode is the development one.
Attestation is two reports and a decision
NVIDIA's attestation page says the GPU collects and signs measurements, and a verifier compares them with known-good references. The GPU does not accept work until someone inside the VM sets the ready state. A successful attestation does not set that state. Setting readiness is a state-changing deployment step. This article omits the command; a reviewed procedure must first establish successful attestation and the intended workload/session binding.
Before that, the same page tells you to check that the persistence daemon is running and that nvidia-smi conf-compute -f reports CC status ON. The ready state is still not evidence that your key-release policy passed. The threat-model page says so directly.
The release order it requires, before model-decryption keys or other secrets move, is:
- Verify CPU evidence against your policy for the CPU TEE and the guest launch state.
- Verify every assigned GPU: identity, firmware measurements, security mode, reference values, and certificate status. Establish how GPU evidence is bound to the intended CPU TEE, confidential VM and protected session; two individually valid reports do not by themselves establish that relationship.
- Establish that the guest software you approved is the software that will receive the secrets.
- Release secrets on a protected channel to that recipient only if every check succeeded.
A good GPU report does not validate the CPU TEE or your workload. A good CPU report does not describe the GPUs. A firmware signature proves NVIDIA signed that firmware. It does not prove the version is one your policy still accepts. The verifier, the reference values, and the service that holds the keys stay trusted even when they run outside the VM. If that service is loose, the hardware report does not save you.
The Consortium's note on recovery fits here. If a flaw is found in the trusted computing base, later evidence is supposed to show that the mutable part was updated, in a way the old flawed code could not fake. That only works if your reference values move when the vendor publishes the fix. Pinning an old "known good" measurement forever is how a revoked firmware stays welcome.
Who is still inside the trust boundary
NVIDIA lists the trusted computing base as the CPU TEE, the guest software, the GPU, and the attestation and key services. Guest software means the guest firmware, the kernel, the NVIDIA driver, the CUDA libraries, the workload, and any administrator who can see the protected assets inside the guest. The host OS, the hypervisor, and other tenants are outside that boundary. A host administrator is treated as potentially malicious. Availability still depends on that operator: they can stop the VM, cut the network, detach the device, or remove power.
The sharp edge for inference is the guest. The TEE is there so the host cannot read the weights. The inference process inside the guest can read the weights, because it has to. A vulnerable server, a debug log of the prompt, or an extra admin account in the guest is inside the boundary NVIDIA tells you remains trusted. Attestation does not claim the approved code is free of vulnerabilities. Trust and measurement are also different: the page says guest software stays trusted even when a given attestation flow does not measure every component. You still have to authenticate the boot and the workload that receives the keys.
An end user of the tenant's service is not protected from the tenant. The page says the VM boundary does not isolate that user's data from the tenant or from software the tenant runs. Confidential computing against the infrastructure owner is a different problem from confidentiality against the company operating the model.
Published attack on the attestation chain
TEE.fail (Chuang et al., IEEE S&P 2026) demonstrates why separate successful reports are not sufficient evidence of an intact chain. With physical and root-level access, the researchers used a DDR5 memory-bus interposer, estimated under US$1,000, to extract Intel provisioning certification keys from fully updated machines and OpenSSL ECDSA signing keys from AMD SEV-SNP guests. The AMD result is not an extraction of AMD attestation keys.
The authors then used forged CPU attestation with GPU evidence from another computer in studied dstack-based applications, passing attestation while running workloads without the intended TEE protection. They do not claim a direct break of NVIDIA GPU confidential-computing hardware. The practical issue is evidence/session binding and the trust placed in CPU attestation. Physical custody and the exact platform threat model therefore belong in key-release policy. AMD bulletin AMD-SB-3040 says physical-vector attacks are outside SEV-SNP's scope and it plans no mitigation for this finding. The Intel notice was inaccessible during this review, so no Intel response or universal patch claim is asserted.
What to choose and why
| You need | What the documents support | What they do not give you |
|---|---|---|
| Weights hidden from the hypervisor | A confidential VM on TDX or SEV-SNP, plus a GPU in CC-On, attested before key release | Hiding the weights from the guest OS you installed |
| One GPU | Single-GPU confidential mode, encrypted CPU-to-GPU path | A second GPU "as well" without checking which mode that pair uses |
| Several Hopper GPUs in one VM | Protected PCIe, with NVLink unencrypted, and a fabric review | The Blackwell multi-GPU mode, which does encrypt NVLink |
| A production policy | Reject CC-DevTools, reject firmware versions you have not accepted, require CPU and GPU evidence | A single "attestation succeeded" boolean |
| Prompts and outputs after they leave the VM | Separate protection for network and storage | An inference from the GPU report that the disk or the API is covered |
Our recommendation: treat key release as the control, not the mode name on the product sheet. No key leaves your verifier until the CPU report, every GPU report, the mode, and the guest measurement match a policy you wrote down. Set GPU readiness only after successful attestation, as NVIDIA documents; its position relative to key release is an application-policy decision. If any check fails, do not fall back to a normal VM with the same key.
Risks and limits
- Side channels remain a shared problem. The Consortium says the TEE definition assumes they are not exploitable, and then explains how that assumption can fail for code that varies time or power with secret bits. NVIDIA points CPU side-channel coverage at the CPU vendor's model and says interconnect protection depends on the GPU mode.
- Invasive physical attacks are outside NVIDIA's GPU threat model and outside the Consortium's in-scope list. The Consortium's 2022 list includes bus monitoring, but that taxonomy is not a guarantee for every vendor implementation. NVIDIA's white paper lists HBM interposers, power/electromagnetic analysis and fault injection as unmitigated. GPU memory is plaintext behind access controls.
- Denial of service by the operator is out of scope. A confidential VM can be powered off.
- Hopper multi-GPU NVLink is unencrypted in the protected-PCIe mode. Quoting the CPU-to-GPU encryption for that box overstates the design.
- Performance counters are disabled in CC-On and enabled in CC-DevTools. Profiling and the production threat model are different modes.
- MIG, MPS, and GPUDirect RDMA are not supported in the configurations the threat-model page describes. A sharing feature that works on an ordinary GPU host is not evidence it works here.
- Stopping a process is not the documented GPU reset. NVIDIA says a later tenant is protected by ephemeral session keys and the supported reset lifecycle.
- These pages were read on 10 November 2026. The white paper's current revision is v1.3 of 14 August 2025. Platform lists move. This article claims no NetLeverage product behaviour, and no command was run.
Sources
Sources checked on 10 November 2026; access limitations are identified below.
- Confidential Computing Consortium, A Technical Analysis of Confidential Computing, v1.3, updated November 2022 — https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/CCC-A-Technical-Analysis-of-Confidential-Computing-v1.3_Updated_November_2022.pdf. Definition, three TEE properties, attestation sketch, in-scope and out-of-scope threats, side channels.
- NVIDIA, Trust and Threat Model — https://docs.nvidia.com/confidential-computing/virtual-machines/threat-model. TDX and SEV-SNP, GPU modes, bounce buffers, TCB, key-release order, exclusions.
- NVIDIA, Attesting the GPU — https://docs.nvidia.com/confidential-computing/virtual-machines/deployment-guide/attest. Measurements and the deployment ready-state transition.
-
NVIDIA, NVIDIA Secure AI with Blackwell and Hopper GPUs, WP-12554-001 v1.3, 14 August 2025 — https://docs.nvidia.com/nvidia-secure-ai-with-blackwell-and-hopper-gpus-whitepaper.pdf. Bounce buffers, Hopper eight-GPU protected PCIe, CC-DevTools counters.
-
Chuang et al., TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition, IEEE S&P 2026 — https://tee.fail/files/paper.pdf; project summary https://tee.fail (opened 10 November 2026). Physical/root-access threat model, distinct Intel and AMD key results, and studied GPU-attestation-chain consequences.
- AMD, AMD-SB-3040, 28 October 2025 — https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3040.html (opened 10 November 2026). Physical attacks outside SEV-SNP scope and no planned mitigation.
This article was originally published on .