Can a cloud provider read my data inside an Intel TDX VM?
Not from software, as long as the VM is an Intel TDX trust domain that is not in debug mode. The CPU encrypts the VM's memory with a per-VM key and hides its CPU state from the host. The host still runs the machine: it can stop the VM, read what leaves it unencrypted, or create it in debug mode.
What Intel TDX encrypts
A trust domain (TD) has two kinds of memory. Intel's TDX white paper describes private memory as protected "using a unique, ephemeral-memory-encryption key assigned to that TD", and shared memory as the channel for "I/O operations such as network access, storage services, invoking hypervisor services". The key is managed by the CPU, not by the host. Intel's overview page adds that TDX "protects both the confidentiality and integrity of the TD CPU state from non-SEAM mode". Our Trust Center puts it in one line: "its memory is encrypted by the CPU and the host cannot read it."
What the host operator can still do
Stop the VM. Intel: "Protecting a TD against denial of service by the VMM is not a security objective of Intel TDX."
Read what leaves the VM. Network packets and disk blocks pass through shared memory, and the Linux kernel documentation is blunt: "Shared mapping content is entirely controlled by the hypervisor." Encrypt in the guest what must stay private: TLS for traffic, encrypted disks for storage.
Open the machine. Intel: "Intel TDX does not defend against replay of memory through physical attacks". The DDRop research of September 2026 showed it with a DDR5 interposer, which Intel called out of scope. Which memory integrity mode the host runs is "not observable from inside the guest" (tdx-guest-probe).
Create the VM in debug mode. A debug TD looks normal from inside. The Intel TDX Module Base Architecture Specification (348549-008US, May 2026, section 15.3): "A guest TD is defined as debuggable if its ATTRIBUTES.DEBUG bit is 1. In this mode, the host VMM can use Intel TDX Module functions to read and modify TD VCPU state and TD private memory". Intel adds that a debuggable TD "is, by nature, untrusted" and that its debuggability "is visible to any third party to which the TD attests". Intel's Quoting Enclave still signs such a quote; a verifier must read bit 0. voltage-verify 0.2.2 (21 October 2026) fails its tdx.debug check unless you pass --allow-debug. On 22 October 2026, on the quote we published on 17 September, it printed:
[PASS] tdx.debug TD attributes 0000001000000000 (0x10000000), DEBUG (bit 0) off: not a debug TDOn a copy of the same quote with bit 0 flipped:
[FAIL] tdx.debug TD attributes 0100001000000000 (0x10000001), DEBUG (bit 0) ON: a debug TD gives no confidentiality, the host can read and modify its memoryWhy the attestation you generate is what counts
No provider's word settles this, ours included. The quote does. It is signed by Intel's Quoting Enclave with a key that chains to the Intel SGX Root CA; VoltageGPU appears nowhere in that chain. It carries the TD attributes, so debug mode shows. And it carries 64 bytes of REPORTDATA chosen by the guest: put your own challenge there and the quote was produced after you asked, not replayed. voltage-verify rejects a bundle made for another challenge:
[FAIL] manifest.challenge challenge differs from the one this verifier issued (replay or foreign bundle)Our Trust Center does not ask you to believe that nobody sees anything; the proof is yours to generate: inside the VM, voltage-verify manifest --challenge auto, then attest, then verify on your own machine. The commands and the SKUs where we ran them are on /api/attestation/evidence; the weekly run is on /proofs; the tutorial reads a real quote field by field. The hardware is run by sub-processors listed on /trust/subprocessors; the proof depends on neither them nor us.
What this proves, and what it does not
A verified quote proves that, when it was produced, the VM was a trust domain, not in debug mode, on an Intel platform that Intel rated UpToDate, and that it was produced for your challenge.
It does not prove which software runs inside. Our Trust Center: "The attestation proves the hardware and the enclave, not which application runs inside. You have root in the VM." We publish no reference values for the VM image, and the RTMR2 register differs between the four VMs whose quotes we have published. It does not prove the host's memory integrity mode or the physical security of the rack, nor anything about data you send out unencrypted; and it applies to Confidential VMs, not to the inference API.
Related questions
Can the provider read my VM if it has root on the host?
Not its private memory or CPU state, unless the TD runs in debug mode. Root on the host does control shared memory, so network and disk traffic the guest does not encrypt, and can stop or delete the VM.
How do I know my VM is not a debug TD?
Read bit 0 of the TD attributes in the quote (byte 168; Linux names it TDX_TD_ATTR_DEBUG_BIT 0). voltage-verify 0.2.2 does it in its tdx.debug check; tdx-guest-probe reads the same bit from inside the guest.
Does the same answer apply to VoltageGPU's inference API?
No. The models run in Intel TDX enclaves at our inference provider, but our API relays your request over TLS and, as the Trust Center says, "handles your request in memory in clear while forwarding it. We do not claim we cannot see it."