Azure, AWS, Google: what can a tenant actually verify on a confidential GPU?
On Google Cloud A3 High, a tenant can pull an Intel TDX quote and an NVIDIA GPU report, or rely on Google's attestation token. On Azure NCC H100 v5 the CPU proof is an AMD SEV-SNP report, not Intel TDX. AWS Nitro Enclaves attest an enclave that contains no GPU. On VoltageGPU, you generate both proofs and verify them offline.
Google Cloud: Intel TDX plus H100 on A3 High
Google's supported configurations (read on 22 October 2026) list a3-highgpu-1g on Intel Sapphire Rapids with "Intel TDX" and "NVIDIA" as technologies, in three zones (europe-west4-c, us-central1-a, us-east5-a).
What you can pull yourself: Google's attestation page says reports come from "the Google-managed vTPM, AMD's Secure Processor, and Intel's TDX module", names go-tdx-guest for the TDX report, and gives nvattest for the GPU (sudo ./nvattest attest --device=gpu): driver attestation relies on Secure Boot, which "allows for the loading of only distribution-signed GPU drivers", and device attestation "verifies the Video BIOS (VBIOS)". Or rely on Google's token: the Confidential Space token is OIDC-compliant, issued by confidentialcomputing.googleapis.com (or Intel Trust Authority); its nvidia_gpu claims include cc_mode (OFF, ON, DEVTOOLS), driver_version, vbios_version and hwmodel (always GCP_NVIDIA_H100). Read the footnote on cc_mode: "This claim attests to the GPU driver only, not the entire GPU device."
CENSUS Labs evaluated this stack on early-access A3 instances ("Challenging the Boundaries of Confidential Computing for AI", v1.1, 25 April 2025). Verdict: "core attestation flows performed as expected", with limits: "opaque firmware trust anchors that cannot be independently verified", "relying parties currently cannot cryptographically verify the signer of the TDX Module", and, on Intel Trust Authority tokens, the client "should still manually verify the signature of the attestation token and cross-check the embedded values against those included in the submitted quote", otherwise the root of trust shifts "from hardware to the attestation API service".
Azure: AMD SEV-SNP plus H100 NVL on NCC H100 v5
Microsoft: "Azure confidential GPUs are based on AMD 4th Gen EPYC processors with SEV-SNP technology and NVIDIA H100 Tensor Core GPUs. In this VM SKU Trusted Execution Environment (TEE) spans confidential VM on the CPU and attached GPU". The only size, Standard_NCC40ads_H100_v5, has "1 NVIDIA H100 NVL GPUs with 94 GB memory, 40 non-multithreaded AMD EPYC Genoa processor cores, and 320 GiB of system memory".
What you can pull yourself, from Microsoft's onboarding repository: "Perform in-guest platform attestation to retrieve raw hardware evidence" and "Perform local GPU attestation". The CPU evidence is an AMD-rooted SEV-SNP report; a verification policy written for Intel TDX quotes does not apply to it.
AWS: Nitro Enclaves, no GPU inside
AWS: enclaves "are separate, hardened, and highly-constrained virtual machines" that "have no persistent storage, interactive access, or external networking". The Nitro Hypervisor isolates "the vCPUs and memory for an enclave from a parent instance". Attestation lets you "verify an enclave's identity", and AWS KMS can require it in a key policy. The parent can be a GPU instance (P5, P6-B300 and P6e-GB200 are supported parents), but the enclave gets vCPUs and memory only: the GPU stays with the parent, outside the boundary. We found no NVIDIA Confidential Computing SKU in AWS documentation on 12 September 2026.
VoltageGPU: two proofs, generated by you, verified offline
From /api/attestation/evidence: "Both proofs are generated by the tenant inside the VM on a nonce the tenant chooses: an Intel TDX quote verified offline against the Intel root, and a NVIDIA GPU attestation report verified with NVIDIA. VoltageGPU is not in the trust chain. Nothing here is produced server-side." voltage-verify checks both offline: on 22 October 2026 our published bundle of 17 September passed its 15 checks. The SKUs where we ran it, with dates, are on the same endpoint; the weekly run is on /proofs; the tutorial reads a published quote field by field.
What this proves, and what it does not
On all three platforms a tenant can obtain hardware-rooted evidence for the CPU side and NVIDIA-signed evidence for the GPU; the roots differ and are not interchangeable in a policy. None of them proves what software runs inside your VM unless you hold reference measurements: CENSUS found the firmware side opaque on GCP, and we publish no reference values for our image either. We have not run Google's or Azure's attestation ourselves. And a hardware proof is not a compliance file: Azure and Google hold platform certifications and sign BAAs; we hold no SOC 2 or ISO 27001 today (Trust Center).
Related questions
Does Azure's confidential GPU use Intel TDX?
No. NCC H100 v5 pairs AMD SEV-SNP on 4th Gen AMD EPYC with one H100 NVL; the CPU evidence is AMD-rooted (Microsoft documentation).
Can I put a GPU inside an AWS Nitro Enclave?
No. An enclave gets vCPUs and memory isolated by the Nitro Hypervisor, with no device; the GPU of a P5 or P6 parent stays outside.
Does Google's attestation token prove the GPU is in confidential mode?
Its cc_mode claim "attests to the GPU driver only, not the entire GPU device" (Google). For the device, use nvattest or NVIDIA's own token and check measres, secboot and dbgstat.
Is the cloud's attestation service a trust anchor?
It becomes one if you stop at its verdict. CENSUS: failing to validate the token against the original quote "shifts the root-of-trust from hardware to the attestation API service". Verify the signature and the nonce yourself.