Remote Attestation for AI Workloads

An enclave that nobody can inspect is indistinguishable from a normal process that says it is an enclave. Memory encryption is worthless on its own, because the party who benefits from lying about it is the same party running the machine. Attestation is the mechanism that makes the claim checkable: the hardware, not the operator, signs a statement describing what it loaded, and a remote party decides whether that description is acceptable before sending it anything sensitive.

The vocabulary is worth getting right, because the RATS architecture terms map cleanly onto every deployment. An attester (the CVM, the GPU) produces evidence. A verifier checks that evidence against reference values and appraisal policy, and emits an attestation result. A relying party (your key manager, your client device) decides what to do with that result.

Evidence is a measurement, not a description

What the hardware signs is a hash chain over what it loaded, not a human-readable inventory. On a confidential VM the report covers the initial memory image of the guest: firmware, kernel, initrd, kernel command line, and the launch configuration. On AMD SEV-SNP that is the launch digest, signed by a key derived in the AMD secure processor and rooted in a certificate chain back to AMD. On Intel TDX the trust domain's measurement registers are quoted through an SGX-based quoting enclave, which is why TDX attestation inherits SGX's provisioning infrastructure (Misono et al., 2024, Confidential VMs Explained, ACM SIGMETRICS).

The GPU produces its own, separate evidence: firmware versions, the state of the confidential-compute mode bits, and measurements of loaded microcode, signed by a device certificate. NVIDIA's verifier compares those against golden values published in a Reference Integrity Manifest, and returns a signed Entity Attestation Token rather than raw evidence (NVIDIA, NVIDIA Remote Attestation Service). Intel Trust Authority performs the equivalent role for the TDX quote and forwards GPU evidence to NVIDIA's verifier, so a full CPU-plus-GPU appraisal is itself a composition of two verifiers (Intel, GPU Remote Attestation With Intel Trust Authority).

That composition is the first place designs go wrong. Two valid tokens do not by themselves prove that the attested GPU is the one attached to the attested VM. The binding has to be established explicitly, usually by having the CVM include the GPU evidence, or a hash of it, in data it reports under its own key.

Freshness, or you are verifying a screenshot

An attestation report is a statement about a past moment. Without a challenge, a replayed report from a genuinely-good machine proves nothing about the machine you are talking to now. Every sound protocol therefore has the relying party supply a nonce that the attester includes in the signed report, and binds the enclave's public key into the same report so the encrypted channel terminates inside the enclave rather than in front of it.

The second freshness problem has no clean fix: attestation is issued at launch, and the guest keeps running afterwards. Runtime attestation extends the measurement with later events, but a report never says "this machine has not been compromised since boot". It says "this machine started from this image".

What attestation does not prove

It does not prove the software is good. A measurement is an identity. If the image you measured logs every prompt to a bucket, attestation proves faithfully that you are talking to the prompt-logging build. The measurement is only meaningful if you can map the hash back to source you have read, which is why attestation is worth little without reproducible builds or a published transparency log of approved images.

It does not prove which model is loaded, unless weights are part of the measured image or are hashed by code inside the enclave and reported. Weights are usually too large to bake into a launch image, so this binding is something the application has to do deliberately.

It does not survive a broken root of trust. Attestation reduces to trusting the vendor's signing hierarchy. That hierarchy has been attacked: researchers reported extracting the root VCEK seed from EPYC Milan parts by software alone, on systems that reported themselves fully patched (Insecure Despite Proven Updated: Extracting the Root VCEK Seed on EPYC Milan via a Software-Only Attack, 2026, arXiv:2605.12990). With a root seed, valid reports can be forged for machines that are not in the state they claim.

It does not verify itself. If your client accepts any token signed by the vendor's verifier without checking measurements, firmware versions and the nonce against your own policy, you have built an elaborate way of asking the hardware whether it is real and ignoring the answer. The appraisal policy, not the signature, is where the security lives.

Operational reality

Attestation makes fleets brittle in a specific way: every firmware update, kernel patch and microcode revision changes measurements, so the reference values a relying party accepts must be updated in lockstep with the fleet or clients start refusing nodes. Running a strict allow-list of measurements and a rolling upgrade at the same time requires that both old and new values be valid during the window, which is exactly the window an attacker wants you to keep open. Teams usually resolve this with short-lived policy that pins to signed manifests rather than hand-maintained hashes, and with staged rollouts where the attestation policy is deployed before the image.