Key Takeaways
- Seven API calls and one SSH session take you from nothing to a verified Intel TDX quote and NVIDIA GPU attestation on your own challenge, checked on your own machine. No dashboard, no ticket, no human on our side.
- We tested it with nothing but the documentation and found two things broken: a wrong SSH command in the pod listing, and a reproduce list that started with a tool the image does not ship. Both are fixed in production.
- The whole run cost 0.60 dollars and the bundle, checksums and verification transcript are public, so anyone can re-run the verifier on them.
- This page is written for humans and for coding agents. The same sequence is in llms.txt, and the tiers endpoint returns the in-VM commands as data.
We sell Intel TDX virtual machines with an NVIDIA GPU passed through, and the whole pitch is that you generate the attestation yourself, on a challenge you chose, and verify it without trusting us. On 16 September a customer asked a simple question: does that also work through the API, end to end, with no dashboard? We said yes. Then we checked, following only our own public documentation, and the honest answer was: not quite. Two things were broken. Both are fixed, the run that found them is public, and this is the sequence as it works today.
The rules of the test
One API key, the documentation page, nothing else. No internal tools, no provider console, no reading our own source code. If a step needed something the documentation did not say, that counted as broken. The tier was the cheapest attested one, an RTX PRO 6000 Blackwell VM at 3.80 dollars per hour, so the whole exercise could be repeated as often as needed.
The sequence, from the outside
# 1. Live inventory, with the attestation block per SKU
curl -s https://voltagegpu.com/api/confidential/vm/tiers \
-H "Authorization: Bearer $VOLTAGE_API_KEY"
# 2. Register your ed25519 public key (a VM binds it at creation)
curl -s -X POST https://voltagegpu.com/api/volt/ssh-keys \
-H "Authorization: Bearer $VOLTAGE_API_KEY" -H "Content-Type: application/json" \
-d '{"name":"laptop","public_key":"ssh-ed25519 AAAA..."}'
# 3. Deploy. One hour is charged upfront, refunded per second on release.
curl -s -X POST https://voltagegpu.com/api/confidential/vm/deploy \
-H "Authorization: Bearer $VOLTAGE_API_KEY" -H "Content-Type: application/json" \
-d '{"name":"proof-run","resource_name":"rtx6000b-small","hardstop_hours":1}'
# 4. Poll until ssh_ready is true (about two minutes), then use ssh_command
curl -s https://voltagegpu.com/api/volt/pods \
-H "Authorization: Bearer $VOLTAGE_API_KEY"
# 7. Release. The unused part of the prepaid hour comes back.
curl -s -X POST https://voltagegpu.com/api/volt/pods/<id>/stop \
-H "Authorization: Bearer $VOLTAGE_API_KEY"Steps 1 to 3 went through in seconds. The tiers endpoint returns, for every SKU, an attestation block: whether the proof has been published, on what date, the URL of the evidence, and the exact commands to reproduce it inside the VM. An agent does not need to read a web page to know what to run. Step 4 is where the test broke.
Broken thing one: the SSH command was wrong
The pod listing returned a ready-made command pointing at the gateway used by the container tier. A VM is reached directly, on its own address and port, and the listing simply did not contain them. The dashboard knew them, because it reads a session-only route; an API user had no way to learn them at all. The documentation said “ready to use SSH command” and the command answered Permission denied (publickey).
The listing now returns provider_status, ssh_ready, ssh_host, ssh_port, ssh_user and a working ssh_command. One detail only the re-run taught us: the address is assigned about 16 seconds after deploy, but the SSH daemon only answers once the provider reports the VM running, around two minutes later. Between the two, ssh_ready is false and the command is null, so a script cannot connect too early.
Broken thing two: the first reproduce command failed
The attestation block listed four commands, starting with a plain pip install. The VM image ships without pip. Anyone following the API to the letter would have failed on line one. The list now reflects what actually runs, and it is the same list you see below.
# Steps 5 and 6, inside the VM (the image ships without pip) curl -sS https://bootstrap.pypa.io/get-pip.py | python3 - --user --break-system-packages python3 -m pip install --user --break-system-packages "voltage-verify[attest]" export PATH=$HOME/.local/bin:$PATH # A challenge you choose, printed by this step voltage-verify manifest --challenge auto -o manifest.json # Both proofs, bound to that challenge: TDX quote + NVIDIA GPU report sudo env PATH=$PATH PYTHONPATH=$(python3 -c 'import site;print(site.getusersitepackages())') \ voltage-verify attest --manifest manifest.json --mode single-gpu -o bundle.json # Copy bundle.json and manifest.json to your own machine, then: pip install voltage-verify voltage-verify verify bundle.json --challenge <the challenge printed above> --hwmodel GB20X --gpus 1 # RESULT: VERIFIED voltage-verify verify bundle.json --challenge 0000...0000 # RESULT: NOT VERIFIED (manifest.challenge) <- a replayed bundle is rejected voltage-verify verify bundle.json --offline --challenge <the challenge> # RESULT: VERIFIED <- Intel collateral is embedded in the bundle
Inside the VM this takes about 19 seconds wall clock, pip bootstrap included. The manifest step prints a random challenge; the TDX quote carries its SHA-512 in report_data, the NVIDIA tokens carry its SHA-256 as nonce, so both proofs are bound to the same value the tenant chose. The wrong-challenge line is the interesting one: a bundle replayed from another run, or from another provider, is rejected. The offline run works because the Intel collateral is embedded in the bundle at attest time.
What it cost, and what is public
Then the stop call, and the refund: 3.20 of the 3.80 dollars came back. The whole run, deploy to verified bundle on a laptop to release, cost 0.60 dollars. Two control runs after the fixes cost 0.14 dollars together; one of them was released at 16 seconds and refunded in full because the machine had never actually started.
The bundle, the manifest, the checksums computed inside the VM and the verification output from the laptop are at /blog/two-proofs/evidence/rtx6000b-api-2026-09-17/README.txt. The shell script that produces such a folder from inside any of our VMs is at two-proofs-in-the-vm.sh. The public index of which SKUs have a published attestation, and which do not and why, is at /api/attestation/evidence, no account needed. The verifier is MIT, on PyPI and on GitHub.
If you are handing this to an agent
Give it an API key from your account settings, this page, and https://voltagegpu.com/llms.txt. Tell it to register an SSH key before deploying, to poll ssh_ready rather than a timer, to copy the bundle out and verify it with a fresh challenge on its own side, and to release the VM when done. Every one of those steps is a JSON response, and the price of a mistake is measured in cents.
What we take from it
“It works through the API” is a claim like any other. The only test that counts is the one that knows nothing but the documentation, and it found in ten minutes what a week of reading the code had not. If you sell attestation, run that test before a customer does. If you buy it, ask your provider for the run.
The longer explanation of the two proofs themselves, with the real outputs from an H200, is in Two proofs, yours, not ours. The API reference is at docs.voltagegpu.com/api-reference.