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

Most teams I talk to in 2026 have been told their LLM is "running in a TEE" and quietly wonder how they would prove it. The honest answer is: if you have not pulled an attestation quote, verified its signature against the silicon vendor’s root of trust, and bound it to a specific model artifact, you cannot prove it. That is fine for a marketing page. It is not fine for a notified-body audit, a DPIA, or a large enterprise procurement review.

This guide is the actual three-step recipe we hand to customers who need verifiable evidence. It is platform-specific to Intel TDX with NVIDIA confidential GPUs because that is what we run, but the pattern transfers cleanly to AMD SEV-SNP, see our TDX vs SEV-SNP comparison for the architecture trade-offs.

Prerequisites

• A running Confidential VM on VoltageGPU (the first hour is offered with your first top-up of $10 or more; an RTX PRO 6000 Blackwell VM is $3.80/hr, current prices on /pricing).
• An SSH key registered before you deploy (a Confidential VM cannot be given one afterwards).
• On your own machine, Python 3.11+ and voltage-verify (`pip install voltage-verify`, MIT), which checks the Intel and NVIDIA signatures for you.
• No reference values to download: we do not publish MR_TD or RTMR values for our VM images. Keep the values from your own quotes and compare them over time.

Step 1, Generate a fresh, nonce-bound attestation quote

The first move is to generate a quote that is bound to a freshness challenge you chose. A cached quote with no nonce is replayable; a challenge-bound quote is not. voltage-verify embeds your challenge in the quote’s REPORT_DATA field and in the NVIDIA report’s nonce, all inside your VM.

# Generate a fresh, challenge-bound TDX attestation quote inside your Confidential VM.
# A "trust us" claim from a vendor is not evidence. A signed quote is.
# You generate it yourself, over SSH, with the key you registered at deploy time.

python3 -m pip install --user --break-system-packages "voltage-verify[attest]>=0.2.1"
export PATH=$HOME/.local/bin:$PATH

# A random challenge you choose (printed by this step)
voltage-verify manifest --challenge auto -o manifest.json

# TDX quote (report_data = SHA-512 of the manifest, which holds the challenge) and, on
# the SKUs where it is verified, the NVIDIA GPU report (nonce = SHA-256 of the manifest)
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 to your own machine: that is where you verify it (Step 2).

At this point you have a base64-encoded blob. It looks like garbage and proves nothing. The next step is the part most "we have TDX" demos quietly skip.

Step 2, Verify the chain to Intel’s root of trust

The quote is signed by a Provisioning Certification Key (PCK) that the CPU itself provisioned from Intel. To trust the quote, you have to trust the chain: PCK → intermediate → Intel root CA. The Intel DCAP libraries do this for you. The important part is that you run the verification, not the cloud provider.

# Verify the quote against Intel’s root of trust.
# Schematic of the checks: on your own machine, voltage-verify verify bundle.json
# --challenge <your challenge> performs them, against Intel and NVIDIA, not against us.
# This is what a notified body or your CISO will actually run.
# Pseudo-code: the helper names are illustrative, not an installable package.

from intel_dcap import (
    parse_quote,
    fetch_pck_collateral,
    verify_quote_signature,
    verify_pck_chain,
)

raw = base64.b64decode(quote["raw_quote"])
parsed = parse_quote(raw)

# 1. Cryptographically verify the quote was signed by a genuine Intel CPU.
collateral = fetch_pck_collateral(parsed.fmspc)  # from Intel PCS
assert verify_pck_chain(parsed.pck_cert_chain, intel_root_ca=INTEL_ROOT_CA)
assert verify_quote_signature(parsed, collateral)

# 2. Verify the platform is up to date and not in a compromised state.
assert parsed.tcb_status in ("UpToDate", "SWHardeningNeeded")  # what voltage-verify accepts
assert parsed.qe_status == "UpToDate"
print("Intel advisories:", parsed.advisory_ids)  # listed, not failed on: read them

# 3. Bind the quote to YOUR manifest, not just any TDX VM somewhere.
assert parsed.report_data == sha512(canonical_json(manifest)).digest()  # holds your challenge
assert not parsed.td_attributes & 1  # DEBUG bit off: a debug TD gives no confidentiality

# 4. Record the measurements. No reference values are published for our images, and none
# of these registers identifies your model: MR_TD and RTMR0-2 measure the firmware and the
# boot chain, RTMR3 is zero. Compare them with your own earlier quotes; RTMR2 changes per VM.
print("MR_TD", parsed.mr_td.hex(), "RTMR0-3", [r.hex() for r in parsed.rtmrs])

print("OK, genuine Intel TDX, platform up to date, bound to my manifest.")

If any of those assertions fail, the quote is either fake, stale, from a debug TD, or the platform is in a compromised TCB state. In all four cases, you do not have evidence and you do not have a defensible audit trail. Fail closed. Refuse to send sensitive data.

Step 3, Bind the quote to a manifest that names your model

A verified TDX quote proves "this is a genuine Intel TDX VM, not in debug mode, on a platform Intel rates up to date." It does not by itself prove "this VM is running the model I think it is running," and nothing in this guide closes that gap completely.

What you can bind today is your description of the workload. voltage-verify manifest --artifact model.safetensors records the digest of each file you name (weights, tokenizer, config) next to your challenge, and the SHA-512 of that manifest is what the quote carries in REPORT_DATA. The hardware signed your description, after your challenge. It does not show that the GPU computed with those files.

Closing that gap needs a measured launch: a component inside the VM that measures the model before loading it and extends an RTMR with the result, so that the quote itself carries the measurement. On our VMs, nothing has done that so far: RTMR3, the register the firmware leaves free, is zero in every Confidential VM quote we have published, and RTMR0 to RTMR2 record the firmware and the boot chain. In four RTX PRO 6000 bundles, RTMR0 and RTMR1 were identical and RTMR2 changed with every VM; Read an Intel TDX Quote, Field by Field reads each register and what it proves.

# Bind the inference request to a specific attested workload.
# This is the line that turns "we use TDX" into actual evidence.

import hashlib, hmac, time

# What the regulator wants to see in your audit log:
audit_record = {
    "timestamp": time.time(),
    "request_id": REQUEST_ID,
    "tdx_quote_sha256": hashlib.sha256(raw).hexdigest(),
    "manifest_sha512": MANIFEST_SHA512,             # the quote's report_data
    "mr_td": parsed.mr_td,                          # initial firmware and configuration
    "rtmrs": parsed.rtmrs,                          # boot chain, not a model identity
    "model_artifact_sha256": MODEL_ARTIFACT_HASH,   # weights named in the manifest
    "tokenizer_sha256": TOKENIZER_HASH,
    "system_prompt_sha256": SYS_PROMPT_HASH,
    "nonce": NONCE,                                  # freshness
    "bundle_created_at": BUNDLE["created_at"],      # a TDX quote carries no time
}

# Sign the record with your own key so the audit trail is tamper-evident.
audit_record["signature"] = hmac.new(
    AUDIT_SIGNING_KEY, json.dumps(audit_record, sort_keys=True).encode(),
    hashlib.sha256,
).hexdigest()

persist(audit_record)  # append-only store, never delete
print("Article 15 / Article 32 evidence captured.")

That `audit_record` is the artifact a notified body actually wants to see. It answers, with evidence, three of the questions an assessor will ask: was the workload sealed? by what hardware? and how do you know? The fourth, running which model?, it answers with your own manifest, which the quote commits to, not with a measurement of what ran.

Common mistakes

• Trusting a quote with no nonce. Replayable. Useless for freshness. Always pass and verify a nonce.
• Skipping the TCB status check. A quote can be cryptographically valid and still come from a CPU with an open Intel security advisory. Check `tcb_status` and `advisory_ids` every time.
• Reading a model identity into MR_TD or the RTMRs. MR_TD measures the TD’s initial firmware and configuration, RTMR0 to RTMR2 the boot chain, and RTMR3 is zero on our VMs. None of them names your model, so the quote cannot prove which model was loaded, only that a genuine Intel TDX VM produced a quote for your manifest.
• Letting the cloud provider verify on your behalf. They can. They should. But the audit-grade pattern is that you also verify, independently, with your own tooling, and persist the result. A notified body wants to see the customer running the verification, not just the vendor.

How this fits into your compliance program

The same audit record satisfies multiple regimes:

• EU AI Act Article 15: "accuracy, robustness, cybersecurity." The signed quote, bound to your manifest, is the cleanest currently-shipping evidence that a high-risk AI system’s execution environment is tamper-resistant.
• GDPR Article 32: "appropriate technical and organisational measures." Hardware sealing with verifiable attestation is, in the post-Edward-Snowden world, what regulators consider the modern bar.
• HIPAA technical safeguards: access controls, transmission security, integrity. The same artifact carries.
• ISO 42001 (AI management system): you bring this audit record to the ISO assessor and you skip a long conversation.

Related reading

• What Intel TDX actually does: the deep-dive
• Intel TDX vs AMD SEV-SNP for confidential AI: the comparison
• EU AI Act August 2026: how attestation becomes Article 15 evidence
• GDPR & AI: why a DPA is not enough, the legal companion
• HIPAA AI inference without a BAA

FAQ