RESEARCH & VALIDATION
Confidential Mode
Is Not a Field.
A broker releasing model weights to a GPU has to know the memory protections were switched on. Every implementation reads a boolean beside the attestation report. That boolean is written by the software being tested.
What Proves the Protection Was On.
Confidential compute on a GPU firewalls a protected region of device memory so that the machine's operator cannot read what a workload is holding. For anyone releasing valuable model weights onto hardware they do not run, that property is the whole basis of the decision.
So a verifier needs to establish it, and the obvious way is to read it. The attestation evidence carries a field stating whether the mode is on, and implementations gate on that field. The field is populated by whichever software assembled the evidence, which is the software the verifier is trying to test.
That makes the question worth asking properly. Is the mode stated anywhere the device itself signs? On 25 September 2026 every signed surface an NVIDIA H100 will produce was examined on live hardware to find out.
ATTESTATION IN ACTION / LIVE H100
Search Every Surface.
Watch What Is Missing.
Each signed surface the device produces, what was searched, and what came back.
Twenty-two claims covering secure boot, debug status, measurement result, architecture, report parsing, nonce match, signature verification, driver and VBIOS reference measurements, and three certificate chains with their revocation status. None concerns confidential compute. Versions three and four exist; version five returns 404, so nothing newer is pending.
Captured from live hardware. Two NVIDIA H100 80GB HBM3 devices, one with confidential compute on inside a TDX guest and one with it off. Values are reproduced from those captures; this walkthrough makes no requests.
The Evidence Is the Answer.
The first three surfaces say the same thing by omission. The appraisal does not name the mode. The report does not move when the mode's own control is operated. The certificates describe identity and firmware, not configuration.
The fourth capture is where the question changes shape. A device of the same model, capable of confidential compute with the feature switched off, was asked for the same evidence. It produced none. Both the attestation report and the certificate chain refused, while the other queries on the same interface answered normally.
So the mode is not a value to read out of the evidence. The evidence is the value. A device without the protection cannot produce a signed attestation report, which means a report that verifies could only have come from a device that had it.
The consequence is worth stating plainly, because it inverts the usual instinct. The field that implementations reach for does not exist in signed form, and it never needed to. The bytes sitting next to it already carry the property, and they carry it with a signature rather than an assertion.
Measured at a Defined Boundary.
Two devices, one in each state, examined on 25 September 2026. The report layout was derived from the bytes rather than from published documentation, and confirmed independently: a firmware measurement in the certificate extension matches the same value in the report, so two separately signed structures agree.
Read the Measurement Scope
The device with confidential compute on ran inside an Intel TDX guest. Reports were pulled with the guest-operable confidential-compute control switched on, then off, then after a memory-size change. All sixteen opaque fields were byte-identical across all three, and of 128 differing bytes in the whole report, 96 are the signature and 32 are the nonce.
The device with the mode off was capable of confidential compute with the feature disabled and no confidential CPU support present. Every device node was available and the non-attestation queries succeeded, which is what distinguishes an unavailable feature from a blocked interface.
One device per state, on different driver versions. A driver cause for the refusal is unlikely, but two machines cannot exclude it. A third configuration was not tested: a confidential host with the GPU mode deliberately disabled, which requires control of the host rather than of a guest.
A verified report establishes the state of the device that produced the bytes, not of the device a verifier is talking to. Evidence relayed from another protected GPU still verifies. That is a separate binding question and it is what bounds this result.
What Has Not Been Said.
Two devices behaved consistently, and a vendor statement would settle what two devices cannot. The open question is whether attestation report generation is gated on confidential mode by design, such that a device with the mode disabled can never produce a verifiable report.
If it is, the property described here is a guarantee rather than an observation, and verifiers can rely on it. If it is not, there is a configuration somewhere that produces a report without the protection, and anyone reasoning the way this article does should know before they build on it.
That question is with NVIDIA, and this note is published partly to ask it in public.
Have a Deployment in Mind?
We’re working with model builders, sovereign AI programs and enterprises to define the conditions for shared model custody.
Explore a Design Partnership