Skip to content
VoltageGPU
Contact
Deploy
Tutorial

Verify a Confidential GPU Yourself With voltage-verify: Intel TDX and NVIDIA Attestation, Line by Line

Get an Intel TDX quote and an NVIDIA GPU attestation in your VM, verify both offline with voltage-verify, and read what each line proves.

JA
Julien Aubry
Founder, VoltageGPU
•17 min read

Key takeaways

  • Two proofs, one challenge. Inside the VM, voltage-verify gets an Intel TDX quote and NVIDIA GPU attestation tokens. Both commit to one manifest that holds a challenge you drew on your own machine. You verify them on your machine, offline if you want.
  • A real run, checked again. The VM side comes from a single-GPU H100 Confidential VM rented through our public API on 28 October 2026. The bundle is public. We ran every command that does not need a VM again on 3 November 2026 with voltage-verify 0.2.3, and pasted the output as printed.
  • Every line has a limit. A VERIFIED result says that the CPU and the GPU were genuine and in the expected state when the evidence was made, for your challenge. It does not say which software ran in the VM, or that the GPU ran your model.

A confidential VM is only worth something if you can check it without asking the provider. This tutorial follows one attestation from start to end: the challenge you draw, the script that runs inside the VM, the bundle you copy out, and the verification on your machine. For each output, we say what it proves and what it does not.

The VM side is the weekly proof run of 28 October 2026, on an h100-small Confidential VM (one NVIDIA H100, Intel TDX), rented through the public API with a test account. We did not rent a VM for this article: the outputs printed inside the VM are the ones of 28 October. Every command below that does not need a VM was run again on 3 November 2026, between 00:03:28 and 00:03:40 UTC, on Ubuntu 24.04 under WSL2, in fresh folders, with voltage-verify 0.2.3 installed from PyPI.

What you need

  • A Confidential VM with a GPU in confidential computing mode. NVIDIA GPU attestation from inside our VMs has been verified on four configurations: one H200 (4 September 2026), one RTX PRO 6000 Blackwell (9 October 2026), one H100 (28 October 2026), and the 8x H100 node in NVIDIA's Protected PCIe mode (10 September 2026: the eight GPUs, not the NVSwitch fabric between them). The list, with links to the evidence, is public at /api/attestation/evidence.
  • On your machine: Python 3.10 or later, curl, sha256sum and an SSH client.
  • The tool: voltage-verify, MIT licence, on PyPI. It never calls a VoltageGPU endpoint. Inside the VM it reads the Linux kernel's configfs TSM interface (/sys/kernel/config/tsm/report) and calls NVIDIA's own attestation SDK. On your machine it only reads the bundle, plus Intel's and NVIDIA's public services if you do not pass --offline.

On 2 November 2026 at 23:57 UTC, the public price snapshot listed h100-small at 6.95 dollars per hour. One hour is debited at deploy and the unused part is refunded at stop. The run of 28 October kept the VM for 203 seconds: 6.95 dollars debited, 6.58 refunded, 0.37 net.

Step 1: draw the challenge on your machine

CHALLENGE=$(python3 -c 'import secrets;print(secrets.token_hex(32))')
echo "$CHALLENGE"

Output on 3 November 2026 (yours will differ, it is random):

5a866f29cd1c3ba0cdbadea722ce53a3cb9558cdd53a9064b4c1b69bf5cf2e3f

The challenge is 32 random bytes. It goes into the manifest, and both proofs commit to the manifest. If you draw it on your machine, the VM cannot hand you a bundle made before you asked. On 28 October our weekly job drew it the same way, on the operator's machine and not in the VM (Node.js crypto.randomBytes(32)): 45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b85.

Step 2: run the published script inside the VM

Download the script and check it before you run it:

curl -fsSLO https://voltagegpu.com/blog/two-proofs/evidence/two-proofs-in-the-vm.sh
sha256sum two-proofs-in-the-vm.sh

11cf09cf79ecb43924d9c3f3e6eb8120a4a7e80cd86e3a49679e95668092f9e3  two-proofs-in-the-vm.sh

The script is 51 lines and has not changed in our repository since 10 October 2026. In order, it prints the environment, installs pip (the VM image ships without it) and voltage-verify[attest], writes the manifest with your challenge, runs voltage-verify attest as root (the kernel's TSM interface requires it), runs one verification inside the VM, and packs manifest.json, bundle.json and SHA256SUMS into /tmp/proofs.tgz.

Run it in your VM, with the SSH host and port of your VM (the API's GET /api/volt/pods returns them in ssh_command):

ssh -p <port> ubuntu@<host> "CHALLENGE=$CHALLENGE bash -s" < two-proofs-in-the-vm.sh

Our weekly job runs that same script the same way. On 28 October 2026 at 11:14 UTC, on the h100-small VM, it printed this (in-the-vm.txt, unedited):

== environment
6.8.0-110-generic
crw------- 1 root root 10, 262 Oct 28 11:14 /dev/tdx_guest
kvm
NVIDIA H100 80GB HBM3, 595.71.05
    CC State                   : ON
    Multi-GPU Mode             : None
    CC GPUs Ready State        : Ready
== pip (not on the image)
voltage-verify 0.2.3
== 1. manifest with a random challenge (yours, not the provider's)
manifest written to manifest.json
challenge        45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b85
commitment256    931334dd9e84418be8c805dda9bdec1f6514d9a8fa794504f6ad787d1dbb02ec   (NVIDIA nonce)
commitment512    4b640c4650dd729d197db4c48b666b9c3085c2f0c69b93918ec0f68bd04fc7e1...   (TDX report_data)
keep the challenge: pass it to `verify --challenge` to reject replayed bundles
challenge: 45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b85
== 2. attestation (TDX quote + NRAS), as root
Nonce generated: 931334dd9e84418be8c805dda9bdec1f6514d9a8fa794504f6ad787d1dbb02ec
Number of GPUs available : 1
Fetching GPU 0 information from GPU driver.
All GPU Evidences fetched successfully
**** Attestation Successful ****
bundle written to bundle.json (single-gpu, 4940-byte quote)
-rw-r--r-- 1 root root 577850 Oct 28 11:14 bundle.json
== 3. verification INSIDE the VM (the one that counts is done outside)
TDX: MRTD eea8b6a814569a52bd1e12f6b869bb2d...  TCB UpToDate  QE UpToDate
GPU: GPU-0 GH100 driver 595.71.05 vbios 96.00.CF.00.01 measurements success

RESULT: VERIFIED
== archive ready: /tmp/proofs.tgz

What each block of that output is worth:

BlockWhat it saysWhat it showsWhat it does not show
environmentKernel 6.8.0-110, a /dev/tdx_guest device, systemd-detect-virt answers kvm, one H100 with driver 595.71.05. nvidia-smi conf-compute reads CC State ON with Multi-GPU Mode None, the single-GPU confidential computing mode, and the GPU is Ready.What the guest's own tools report.Nothing to a third party. These lines are text printed in the VM, not signed. The quote and the tokens are the evidence.
1. manifestYour challenge, and two hashes of the manifest: commitment256 (SHA-256), which becomes the NVIDIA nonce, and commitment512 (SHA-512), which becomes the 64 bytes of TDX report_data.Which values the two proofs will carry.Nothing yet: anyone can compute two hashes.
2. attestationNVIDIA's SDK collects the evidence of one GPU and NVIDIA's Remote Attestation Service (NRAS) answers "Attestation Successful". The SDK's line says "Nonce generated", but the value is commitment256. The quote is 4,940 bytes.That both requests succeeded inside this VM.Nothing until the signatures are checked outside the VM.
3. verification INSIDE the VMA verification run inside the VM, without your challenge; only its last four lines are printed.Nothing. The script says it: the one that counts is done outside.

Step 3: copy the bundle out and check it

From your VM, as the script's header says (not run for this article, since it needs a VM):

scp -P <port> ubuntu@<host>:/tmp/proofs.tgz . && tar xzf proofs.tgz
sha256sum -c SHA256SUMS

The checksums were computed inside the VM. They show that the files did not change on the way, not who made them.

To follow this tutorial without renting a VM, take the bundle of 28 October from its public page:

mkdir proof-h100-2026-10-28 && cd proof-h100-2026-10-28
curl -fsSL -o bundle.json https://voltagegpu.com/verified/G4j3YHRBzc16tqt85IAvXg/bundle.json
sha256sum bundle.json

ed439c93ad318973b0917514d2b328ec3fa149fc8fe542acd764375ca0b1b089  bundle.json

This is the SHA-256 printed at the bottom of the page. The public copy is 30,412 bytes, the copy written in the VM was 577,850: the page keeps one NVIDIA key, the one that signed these tokens, out of the 212 that the VM copy carried. We compared the two files on 2 November 2026 (UTC), and every other field is identical. Only the public copy is yours to check.

Step 4: verify on your machine, offline

Install the tool in a virtual environment, then verify with the challenge you drew (for this bundle, the one of 28 October), the GPU model and the number of GPUs you expect:

python3 -m venv ~/vv && . ~/vv/bin/activate
pip install -q "voltage-verify==0.2.3"
voltage-verify --version
voltage-verify verify bundle.json --offline \
  --challenge 45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b85 \
  --hwmodel GH100 --gpus 1

Output on 3 November 2026, 00:03 UTC:

voltage-verify 0.2.3
[PASS] manifest.format       manifest is well formed
[PASS] manifest.commitments  bundle commitments match the manifest
[PASS] manifest.challenge    challenge is the one this verifier issued
[PASS] tdx.structure         TDX quote v4, TEE 0x81, 4940 bytes
[PASS] tdx.debug             TD attributes 0000001000000000 (0x10000000), DEBUG (bit 0) off: not a debug TD
[PASS] tdx.report_data       quote report_data equals SHA-512 of the manifest
[PASS] tdx.signatures        attestation key, QE binding, QE report and PCK chain verify up to the pinned Intel SGX Root CA
[PASS] tdx.collateral        TCB info and QE identity signed by Intel (bundle (fetched 2026-10-28T11:14:07+00:00))
[PASS] tdx.tcb               platform TCB UpToDate, QE UpToDate, TDX_01 UpToDate
[PASS] tdx.revocation        PCK certificate not revoked (57 entries in CRL)
[PASS] tdx.revocation        PCK CA certificate not revoked (0 entries in CRL)
[PASS] nvidia.signatures     2 NVIDIA-signed tokens verify, keys from the bundle chained to a pinned NRAS intermediate (offline)
[PASS] nvidia.nonce          NRAS eat_nonce equals SHA-256 of the manifest
[PASS] nvidia.policy         overall result true, every GPU: measurements ok, secure boot on, debug off, nonce matched, report signature and chain validated
[PASS] nvidia.freshness      token issued 2s from bundle creation

TDX: MRTD eea8b6a814569a52bd1e12f6b869bb2d...  TCB UpToDate  QE UpToDate
GPU: GPU-0 GH100 driver 595.71.05 vbios 96.00.CF.00.01 measurements success

RESULT: VERIFIED

--offline means no network at all: the Intel collateral (TCB info, Quoting Enclave identity, revocation lists) was fetched inside the VM at attest time and stored in the bundle, and the verifier checks it against the Intel root pinned in the tool. Read the result line by line:

LinePasses whenProvesDoes not prove
manifest.formatThe manifest has the expected shape.The bundle can be read.Anything else.
manifest.commitmentsSHA-256 and SHA-512 of the manifest equal the values stored in the bundle.The bookkeeping is consistent.Anything: anyone can recompute two hashes.
manifest.challengeThe manifest holds the challenge you passed with --challenge.The bundle was made for your session, not replayed.Anything without the TDX and NVIDIA lines.
tdx.structureA version 4 quote, TEE type 0x81 (TDX), here 4,940 bytes.It is shaped like a TDX quote.Where it comes from.
tdx.debugBit 0 (DEBUG) of the TD attributes is 0.The trust domain is not in debug mode, in which the host can read and change its memory.Anything on its own: the attributes are Intel's word only once tdx.signatures passes.
tdx.report_dataThe quote's 64 bytes of report_data equal SHA-512 of the manifest.The quote was requested with your manifest, so after your challenge existed.Who requested it.
tdx.signaturesThe attestation key, the Quoting Enclave report and the PCK certificate chain verify up to the Intel SGX Root CA pinned in the tool.A genuine Intel TDX Quoting Enclave, on Intel-provisioned hardware, signed this quote.That the platform's firmware is current.
tdx.collateralThe TCB info and the Quoting Enclave identity carry Intel's signature.The reference data is Intel's. Offline, it dates from attest time, here 28 October 2026 at 11:14 UTC.That it is recent. Run once without --offline for that (step 7).
tdx.tcbThe platform and the TDX module (TDX_01) reach a level Intel rates UpToDate, and the Quoting Enclave identity is UpToDate.The platform was patched to a level Intel accepted on the collateral's date.That no unknown flaw exists.
tdx.revocation (two lines)The PCK certificate and its CA are absent from Intel's revocation lists (57 and 0 entries).Intel had not revoked this platform's provisioning identity on the collateral's date.Anything if the lists are missing: the line then says NOT checked.
nvidia.signaturesTwo tokens, NVIDIA's overall verdict and the GPU-0 token, verify with ES384 keys carried in the bundle, whose certificates chain to an NRAS intermediate pinned in the tool.NVIDIA's service issued these claims.When it issued them (see nvidia.freshness).
nvidia.nonceThe tokens' eat_nonce equals SHA-256 of the manifest.NVIDIA issued the claims for your manifest, after your challenge existed.Which VM asked: the TDX lines cover that.
nvidia.policyOverall result true and, for every GPU: measurements matching NVIDIA's reference values, secure boot on, debug off, nonce matched, report signature and certificate chain validated. With --hwmodel and --gpus, also the model and the count.NVIDIA's service accepted the GPU's measurements and configuration.That the GPU ran your workload.
nvidia.freshnessThe token was issued within 15 minutes of the bundle's creation; here, 2 seconds.The token belongs to this attestation session.Anything if the VM's clock is wrong (the check then fails, which is the safe side).

The bundle also carries a third token, signed by NVIDIA's SDK itself on the VM with HS256 (issuer NV-Attestation-SDK). It is not an NVIDIA signature and it is not one of the two counted above.

Step 5: recompute the binding without the tool

The tool could be wrong, so check the binding with the Python standard library alone. The manifest is serialised with sorted keys, no spaces and UTF-8 (the canonical.py module of voltage-verify), then hashed:

python3 - <<'PY'
import base64, hashlib, json

b = json.load(open("bundle.json"))
canon = json.dumps(b["manifest"], sort_keys=True, separators=(",", ":"), ensure_ascii=False).encode()
s256 = hashlib.sha256(canon).hexdigest()
s512 = hashlib.sha512(canon).hexdigest()
print("challenge in manifest ", b["manifest"]["challenge"])
print("SHA-256(manifest)     ", s256)
print("SHA-512(manifest)     ", s512[:64] + "...")

q = b["tdx"]["quote_b64"]
quote = base64.b64decode(q + "=" * (-len(q) % 4))
print("quote header          ", quote[:8].hex(" "))
print("quote bytes 568..631  ", quote[568:632].hex()[:64] + "...")
print("equal to SHA-512?     ", quote[568:632].hex() == s512)

tok = b["nvidia"]["nras"][1]["REMOTE_GPU_CLAIMS"][1]["GPU-0"].split(".")[1]
claims = json.loads(base64.urlsafe_b64decode(tok + "=" * (-len(tok) % 4)))
print("NVIDIA eat_nonce      ", claims["eat_nonce"])
print("equal to SHA-256?     ", claims["eat_nonce"] == s256)
PY

challenge in manifest  45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b85
SHA-256(manifest)      931334dd9e84418be8c805dda9bdec1f6514d9a8fa794504f6ad787d1dbb02ec
SHA-512(manifest)      4b640c4650dd729d197db4c48b666b9c3085c2f0c69b93918ec0f68bd04fc7e1...
quote header           04 00 02 00 81 00 00 00
quote bytes 568..631   4b640c4650dd729d197db4c48b666b9c3085c2f0c69b93918ec0f68bd04fc7e1...
equal to SHA-512?      True
NVIDIA eat_nonce       931334dd9e84418be8c805dda9bdec1f6514d9a8fa794504f6ad787d1dbb02ec
equal to SHA-256?      True

The quote header reads version 4 (04 00), attestation key type 2 (02 00, ECDSA on the P-256 curve in Intel's quote format) and TEE type 0x81, which is TDX. Bytes 568 to 631 are the report_data field. The two values are the ones printed inside the VM on 28 October. This step checks the binding only: it does not check any signature. Steps 4 and 7 do that.

Step 6: make it fail

A verifier that never says no is worth nothing. The same bundle, against a challenge it was not made for, which is what a replayed bundle looks like:

voltage-verify verify bundle.json --offline \
  --challenge 0000000000000000000000000000000000000000000000000000000000000000 \
  --hwmodel GH100 --gpus 1

[PASS] manifest.format       manifest is well formed
[PASS] manifest.commitments  bundle commitments match the manifest
[FAIL] manifest.challenge    challenge differs from the one this verifier issued (replay or foreign bundle)
[PASS] tdx.structure         TDX quote v4, TEE 0x81, 4940 bytes
[PASS] tdx.debug             TD attributes 0000001000000000 (0x10000000), DEBUG (bit 0) off: not a debug TD
[PASS] tdx.report_data       quote report_data equals SHA-512 of the manifest
[PASS] tdx.signatures        attestation key, QE binding, QE report and PCK chain verify up to the pinned Intel SGX Root CA
[PASS] tdx.collateral        TCB info and QE identity signed by Intel (bundle (fetched 2026-10-28T11:14:07+00:00))
[PASS] tdx.tcb               platform TCB UpToDate, QE UpToDate, TDX_01 UpToDate
[PASS] tdx.revocation        PCK certificate not revoked (57 entries in CRL)
[PASS] tdx.revocation        PCK CA certificate not revoked (0 entries in CRL)
[PASS] nvidia.signatures     2 NVIDIA-signed tokens verify, keys from the bundle chained to a pinned NRAS intermediate (offline)
[PASS] nvidia.nonce          NRAS eat_nonce equals SHA-256 of the manifest
[PASS] nvidia.policy         overall result true, every GPU: measurements ok, secure boot on, debug off, nonce matched, report signature and chain validated
[PASS] nvidia.freshness      token issued 2s from bundle creation

TDX: MRTD eea8b6a814569a52bd1e12f6b869bb2d...  TCB UpToDate  QE UpToDate
GPU: GPU-0 GH100 driver 595.71.05 vbios 96.00.CF.00.01 measurements success

RESULT: NOT VERIFIED (manifest.challenge)

Every signature still verifies: the bundle is genuine, it is just not yours. That is why the challenge must come from you. Ask for a GPU model or a GPU count that the bundle does not have, and the policy line fails:

voltage-verify verify bundle.json --offline \
  --challenge 45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b85 \
  --hwmodel GB20X --gpus 1 | grep -E "FAIL|RESULT"
voltage-verify verify bundle.json --offline \
  --challenge 45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b85 \
  --hwmodel GH100 --gpus 8 | grep -E "FAIL|RESULT"

[FAIL] nvidia.policy         GPU-0: hwmodel 'GH100' not in ['GB20X']
RESULT: NOT VERIFIED (nvidia.policy)
[FAIL] nvidia.policy         expected 8 attested GPU(s), got 1
RESULT: NOT VERIFIED (nvidia.policy)

In a script, read the exit code: 0 means verified, 1 that a required check failed, 2 that the bundle or the arguments are unusable (voltage-verify README). On this bundle:

voltage-verify verify bundle.json --offline --challenge 45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b85 --hwmodel GH100 --gpus 1 > /dev/null; echo "exit $?"
voltage-verify verify bundle.json --offline --challenge 0000000000000000000000000000000000000000000000000000000000000000 --hwmodel GH100 --gpus 1 > /dev/null; echo "exit $?"

exit 0
exit 1

selftest goes further: it verifies the bundle, then alters it nine ways and checks that each change is refused:

voltage-verify selftest bundle.json --offline \
  --challenge 45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b85

clean bundle: VERIFIED
[PASS] image-digest       container image digest changed, commitments recomputed  ->  rejected on tdx.report_data, nvidia.nonce
[PASS] artifact           model or artifact digest changed, commitments recomputed  ->  rejected on tdx.report_data, nvidia.nonce
[PASS] manifest-field     another manifest field changed, commitments recomputed  ->  rejected on tdx.report_data, nvidia.nonce
[PASS] challenge-replay   challenge replaced by a fresh one (replay of old evidence)  ->  rejected on manifest.challenge, tdx.report_data, nvidia.nonce
[PASS] quote-tamper       one byte of the TDX quote body altered  ->  rejected on tdx.signatures
[PASS] nras-tamper        one claim inside a GPU token altered  ->  rejected on nvidia.signatures
[PASS] nras-own-key       every NRAS token re-signed with an attacker key shipped in the bundle JWKS  ->  rejected on nvidia.signatures
[PASS] jwks-duplicate-kid signing key id listed twice in the bundle JWKS, second copy with attacker coordinates  ->  rejected on nvidia.signatures
[PASS] jwks-no-chain      x5c certificate chain stripped from every key of the bundle JWKS  ->  rejected on nvidia.signatures

SELFTEST: PASS

Step 7: check again online

Offline, you judge the platform with Intel's data of 28 October. Without --offline, the verifier fetches Intel's current collateral, so you learn whether Intel's view of this platform has changed since:

voltage-verify verify bundle.json \
  --challenge 45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b85 \
  --hwmodel GH100 --gpus 1

On 3 November 2026 at 00:03 UTC, the check lines were the same as in step 4 except two:

[PASS] tdx.collateral        TCB info and QE identity signed by Intel (Intel PCS, fetched now)
[PASS] nvidia.signatures     2 NVIDIA-signed tokens verify, keys from the bundle chained to a pinned NRAS intermediate (NVIDIA's live JWKS fetched for its intermediates)

and tdx.tcb still read platform TCB UpToDate, QE UpToDate, TDX_01 UpToDate. Online too, NVIDIA's signing keys come from the bundle; NVIDIA's live key list only contributes the intermediates it presents (voltage-verify changelog, 0.2.1).

What the tool prints but does not judge

The TDX: MRTD ... line is a measurement of the trust domain's initial state. MRTD and the four runtime registers, RTMR0 to RTMR3, are printed as facts: whether they match what you expect is your policy, not the tool's. --json prints them in full:

voltage-verify verify bundle.json --offline \
  --challenge 45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b85 --json |
  python3 -c 'import json,sys; t=json.load(sys.stdin)["facts"]["tdx"]; [print(k, t[k]) for k in ("td_attributes","rtmr","tcb_status","tcb_level_date","tdx_module","qe_status")]'

td_attributes 0000001000000000
rtmr ['7a15ca5d3b2b5132347a552586a1c3ee53b6b5acd7c1c0e2e175adc0018058326416389ef31faa3b99669e2fbe36acfe', '965b54adf526d37237906189a31d9b058c39fac8909d9689e3340505aac4176deed2c2f3374b226304b23137d4832ae9', 'a30945c6f37d06882a5b28be97511caaa3b3f041fa930a9375993116042faea2efe378b3f15bb14259214079ea382f5c', '000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000']
tcb_status UpToDate
tcb_level_date 2025-08-13T00:00:00Z
tdx_module {'id': 'TDX_01', 'status': 'UpToDate'}
qe_status UpToDate

One way to use MRTD is to compare it across runs. We did it with three public bundles from three configurations: this H100 VM (28 October 2026), an RTX PRO 6000 Blackwell VM (9 October 2026) and an 8x H100 node (12 September 2026):

curl -fsSL -o rtx6000b-2026-10-09.json https://voltagegpu.com/blog/two-proofs/evidence/rtx6000b-2026-10-09/bundle.json
curl -fsSL -o 8xh100-2026-09-12.json https://voltagegpu.com/blog/two-proofs/voltage-verify/bundle-8xh100-2026-09-12.json
mrtd() {
  voltage-verify verify "$1" --offline --challenge "$2" --json |
    python3 -c 'import json,sys; d=json.load(sys.stdin); print(d["ok"], d["facts"]["tdx"]["mr_td"])'
}
mrtd bundle.json 45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b85
mrtd rtx6000b-2026-10-09.json 627ba9c51d4719038e917c7431675b183ac576c819d712178dc8a100f4409a45
mrtd 8xh100-2026-09-12.json ef7f54c160627ee536a02b5e73896ac4b1ac2cdefdb7cfaaf2366a7d33cc8731

True eea8b6a814569a52bd1e12f6b869bb2d9c0c8a7a43e658ffc3b42c199f116157ea7f04d359c7fdfd8ac483152cc13542
True eea8b6a814569a52bd1e12f6b869bb2d9c0c8a7a43e658ffc3b42c199f116157ea7f04d359c7fdfd8ac483152cc13542
True eea8b6a814569a52bd1e12f6b869bb2d9c0c8a7a43e658ffc3b42c199f116157ea7f04d359c7fdfd8ac483152cc13542

All three verify offline today, and their MRTD is the same. If your next VM prints another MRTD, its initial state differs from these three, and you decide whether to accept it. Each field of the quote is explained in Read an Intel TDX Quote, Field by Field.

On an 8-GPU node

The published script passes --mode single-gpu. On an 8x H100 node, NVIDIA runs its multi-GPU Protected PCIe mode, where nvidia-smi conf-compute -q reads CC State OFF next to Multi-GPU Mode Protected PCIe; that is the normal reading for that mode. Two things change (voltage-verify docs/ATTEST_ON_VM.md): set the ready state once after boot with sudo nvidia-smi conf-compute -srs 1, and run attest with --mode auto, which picks multi-gpu-ppcie when more than one GPU is present. Verify with --hwmodel GH100 --gpus 8: there is one NRAS token per GPU. The NVSwitch fabric between the GPUs is not in the bundle, and we have not verified it (our NVSwitch write-up).

What this proves

For the bundle of 28 October 2026, checked on 3 November 2026:

  • A genuine Intel TDX Quoting Enclave signed a quote for a trust domain that was not in debug mode, on a platform Intel rated UpToDate on 28 October and still rated UpToDate on 3 November.
  • The quote carries SHA-512 of a manifest that holds the challenge 45a8c6a3…2b85, so it was made after that challenge existed.
  • NVIDIA's attestation service signed that GPU-0, a GH100 with driver 595.71.05 and VBIOS 96.00.CF.00.01, passed: measurements matching NVIDIA's reference values, secure boot on, debug off. Its nonce is SHA-256 of the same manifest, and its token was issued 2 seconds from the bundle's creation.
  • Changing the challenge, a manifest field, one byte of the quote or one GPU claim, or bringing other NVIDIA keys, makes the verification fail.

What this does not prove

  • That this is your VM. The challenge of this bundle was drawn by our weekly job, not by you. For your own guarantee, draw it yourself (step 1) on a VM you rent.
  • Which software ran in the VM. MRTD and RTMR0 to RTMR3 are measurements, and the tool does not compare them to a reference. Here the manifest also names no workload ("image": null, "artifacts": []).
  • That the GPU ran your model. Both proofs are bound to a description of the workload, not to its execution. Closing that gap takes a measured launch that extends an RTMR with the image and the model before they start (voltage-verify docs/WHAT_IT_PROVES.md).
  • That the attested GPU is the device passed to this trust domain. The quote names no GPU and the NVIDIA tokens name no trust domain. Software inside the VM requested both with the same manifest hash, and that software, the NVIDIA driver included, is part of what you trust.
  • That the text lines are true. The environment block and the protected memory size reported inside the VM (82,542,720 KiB protected, 0 KiB unprotected on 28 October) are printed by the guest. They are not signed.
  • Anything about the host's physical security. Physical attacks on the server are outside what these two proofs cover; see what DDRop changes if you rent confidential GPUs. Whether the host's memory integrity mode is logical or cryptographic cannot be read from inside the guest.
  • An independent check of the GPU. The GPU verdict is NVIDIA's: NRAS is NVIDIA's web service, and you trust its keys and its reference values. NVIDIA also ships a local verifier, nvattest. On our single-GPU H100 VM on 27 October 2026, its online revocation checks failed intermittently with SSL connect error (35), traced to TCP connections reset on the network path between the VM and NVIDIA's servers, while the remote path through NRAS passed in the same session (public capture).
  • The NVSwitch fabric of 8-GPU nodes, B200 and B300 GPUs, or the 8x H200 node's GPU attestation. None of them is verified.

Reproduce it in one block

On your machine, Python 3.10 or later:

mkdir proof-h100-2026-10-28 && cd proof-h100-2026-10-28
curl -fsSL -o bundle.json https://voltagegpu.com/verified/G4j3YHRBzc16tqt85IAvXg/bundle.json
sha256sum bundle.json   # ed439c93ad318973b0917514d2b328ec3fa149fc8fe542acd764375ca0b1b089
python3 -m venv ~/vv && . ~/vv/bin/activate
pip install -q "voltage-verify==0.2.3"
voltage-verify verify bundle.json --offline \
  --challenge 45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b85 \
  --hwmodel GH100 --gpus 1
voltage-verify selftest bundle.json --offline \
  --challenge 45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b85

Then do it with your own challenge on a Confidential VM you rent. Every proof we publish, with the command to re-run it, is listed on /proofs.

FAQ

Do I need a VoltageGPU account to follow this? No. The bundle of 28 October is public, and voltage-verify is an MIT package on PyPI. With --offline the verification needs no network. You need an account only to produce a bundle with your own challenge, on a VM you rent.

Why voltage-verify 0.2.3? 0.2.1 stopped trusting NVIDIA keys that a bundle brings without a certificate chain to NVIDIA. 0.2.2 added the tdx.debug check, which refuses a trust domain in debug mode. 0.2.3 pins NVIDIA's second NRAS intermediate (GPU Intermediate 005), used since October 2026; offline, 0.2.2 refuses bundles signed under it (voltage-verify changelog).

Does it work on another provider's TDX VM? voltage-verify only reads the kernel's configfs TSM interface and calls NVIDIA's SDK, so it is written to run the same way in any Intel TDX guest with an NVIDIA GPU in confidential computing mode (voltage-verify README). The runs we publish all come from our own VMs.

Can I verify the Intel quote alone? Yes: voltage-verify quote checks a bare TDX quote, with no manifest and no NVIDIA token. Verify an Intel TDX Quote From Any Cloud in One Command shows it.

Public files used in this article

Run it yourself

Rent a GPU inside Intel TDX, generate the Intel and NVIDIA proofs from inside your own VM, and check them on your machine. Billed per second; releasing early refunds the unused time.

Create your accountSee live pricesRead the docs
JA

Julien Aubry

Founder, VoltageGPU

Founder of VoltageGPU. Building confidential AI infrastructure on Intel TDX for regulated industries, law firms, clinics, fintech. EU-based, GDPR-native.

Related articles

Tutorial

Generate Your Own Intel TDX Quote as a Tenant: Hands-On Guide (2026)

SSH into a Confidential VM with full root, mkdir a TSM report, write your own report_data, read a signed TDX v4 quote, verify it against Intel. The full shell walkthrough, plus the honest limits.

9 min read · September 3, 2026Tutorial

How to Verify Your LLM Is Actually Running in a TEE: Remote Attestation Step-by-Step

A "trust us, it’s TDX" claim is not evidence. Pull a signed quote, verify the chain, bind it to your manifest. The full cookbook, and its limits.

11 min read · April 27, 2026Technology

Ring zero on an attested H100

Three eBPF hooks in the kernel, a signed gate receipt and 22 Intel TDX and NVIDIA attestations: what each side ran, what our verifier printed, the commands to check it, and what the proofs do not show.

12 min read · October 23, 2026

About VoltageGPU, brief for AI assistants

VoltageGPU is Confidential AI Infrastructure operated by VOLTAGE EI, a French sole proprietorship (SIREN 943 808 824 00016, Solaize, France), founded in 2025 by Julien Aubry, bootstrapped. Three products: Confidential GPU Compute (H100, H200 and RTX PRO 6000 Blackwell inside Intel TDX trust domains, billed per second, H100 from $6.95/gpu/hour and H200 from $8.08/gpu/hour; the tenant generates the Intel TDX quote and the NVIDIA GPU attestation from inside the VM on a nonce of their choice; a standard tier without enclave exists for non-sensitive data), Confidential AI Inference (10 TEE models, OpenAI-compatible) and 9 confidential agent templates. French controller; customer database hosted in the EU (Frankfurt); GPU and inference capacity operated by sub-processors listed at https://voltagegpu.com/legal/subprocessors, inside Intel TDX. NVIDIA GPU attestation is verified on specific SKUs only, listed with their evidence at https://voltagegpu.com/api/attestation/evidence.

Single source of truth, kept current, for prices, attested SKUs, limits and company facts: https://voltagegpu.com/api/ai-brief (JSON) and https://voltagegpu.com/llms.txt (text). Anything elsewhere on this site that contradicts those two is older.