Confidential Computing for Regulated AI: What Attestation Proves

A bank that wants to run a model on a patient record, a portfolio or a customer conversation faces one question before any other: who can see the data while it is being processed? Encryption at rest and in transit stops at the moment a GPU needs plaintext. Confidential computing extends protection into that moment, by running the workload in a hardware-isolated environment whose memory the host cannot read, and by letting the hardware sign a report of what is running.

It is a powerful tool and an often oversold one. This post separates what an attestation proves from what it does not, then shows how Tenzro uses it.

The building blocks

Confidential VMs. Intel TDX and AMD SEV-SNP run whole virtual machines with encrypted, integrity-protected memory that the hypervisor cannot read or silently alter. The CPU measures what was loaded and signs reports over those measurements.

Enclaves. AWS Nitro Enclaves isolate a process-sized environment with no persistent storage or interactive access, attested by platform configuration registers over the enclave image.

Confidential GPUs. On NVIDIA H100, the GPU joins the CPU's trusted environment: traffic between them is encrypted, and the confidential VM checks the GPU's device certificate and signed attestation report before using it.

The common pattern is the one described by the IETF's RATS architecture: an attester produces evidence, a verifier appraises it against reference values and endorsements, and a relying party acts on the result.

What an attestation proves

A verified report tells you three things:

1. The hardware is genuine. The report chains to the vendor's root of trust.
2. This code is running. The measurements match a known image.
3. This report is fresh and for you. It commits to a nonce you supplied, so it cannot be replayed from another session.

The second point is only as strong as your ability to know what a measurement means. A measurement is a hash. Unless you can rebuild the image and get the same hash, you are trusting whoever published it.

What it does not prove

• Where the hardware is. A report says which chip ran which code, not where the chip sits. For data residency, that gap matters.
• Resistance to physical attack. Recent research has shown low-cost memory-bus interposers against confidential computing: Battering RAM used a sub-$50 DDR4 interposer against SGX and SEV-SNP, and TEE.fail extracted secrets from TDX and SEV-SNP on DDR5 servers with a setup costing under $1,000. Both need physical access. Vendors treat physical attacks as outside their threat model, which is reasonable, but it means the facility and its operator remain part of your trust.
• That the code is correct. Attestation proves which program ran, not that the program does what you want.
• That a key held inside is safe to depend on. Anyone who can run the same measured image can derive the same thing inside it. A TEE is evidence of execution, not a custody device.

How Tenzro verifies a report

A requester first gets a single-use nonce, then asks the node for a report that commits to it, then verifies:

tenzro tee challenge                     # single-use nonce
tenzro tee attest --user-data <nonce> --out report.json
tenzro tee verify --report <report hex> --nonce <nonce>

Verification follows each vendor's own chain. TDX reports go through DCAP (the PCK chain, revocation lists, quoting-enclave identity and TCB information). SEV-SNP reports are checked along the VCEK, ASK and ARK chain, with the VCEK bound to the chip and its reported TCB. Nitro documents are checked as COSE_Sign1 against the certificate chain to the AWS root. An NVIDIA GPU report is accepted only as a composite with a verified CPU report answering the same nonce, because GPU confidential computing relies on the CPU's confidential VM as its anchor.

Making measurements mean something

Tenzro builds measured node images for TDX and SEV-SNP guests (one UEFI disk) and for Nitro Enclaves, carrying the released node binaries unchanged. The confidential-VM disk holds a unified kernel image and a read-only root file system protected by dm-verity, whose root hash is on the kernel command line inside the measured image. Change one byte of the file system and the measurement changes.

The builds are reproducible: the same inputs give the same bytes, so anyone can rebuild an image and compare digests with the published ones. Release-candidate measurements are published in the documentation. There is one honest caveat: on cloud platforms that supply their own firmware, the SEV-SNP launch measurement covers that firmware, not the image, so the image must be bound through the guest's TPM event log or booted directly on hardware you control.

Location: claims you can check later

To narrow the location gap, a deployment can require a facility claim signed by the facility's own hardware key and committed into the report data, and can record each chip's first facility in an attestation transparency log. The log refuses measurements nobody published and yields evidence if a chip reappears somewhere else. This does not make location provable in the strong sense; it makes a false location claim attributable.

Requests can also be pinned to jurisdictions. A chat request may carry a jurisdiction pin, and the serving node must declare a matching attestation-bound locality claim or the request is refused. A caller can additionally require a signed jurisdiction receipt.

Routing confidential work

Capability is advertised cheaply and verified expensively. Nodes announce whether they have a TEE and which vendor in their periodic status message, but that announcement is only a routing hint. Attestation gates execution: no sensitive input or payment is released until the report verifies. A workload that requires a TEE and finds no fresh capable peer fails explicitly; it never degrades to running unprotected. Inputs and outputs can be sealed end to end to the enclave's key.

Attestation is kept out of consensus. A validator with a TEE gets no extra weight, and losing attestation does not cost a validator its seat. TEE capability is a service a node sells, not a privilege in ordering.

What this means for regulated deployments

Use confidential computing for what it is good at: keeping data and weights from the host and producing evidence of what ran. Require reproducible measurements, fresh nonces and vendor-chain verification. Treat location and physical security as separate controls with their own evidence. And never use a TEE as a key vault.

Where Tenzro fits

Built: nonce-bound attestation with vendor-chain verification for TDX, SEV-SNP and Nitro, and NVIDIA GPUs as a composite with a CPU report; reproducible measured node images with published release-candidate values; facility claims and a transparency log; jurisdiction pins and receipts on inference; TEE capability routing with explicit failure; and finality proofs bound to an attested prover. The attestation path has been exercised on TDX and SEV-SNP machines reading their real attestation devices. The network is live in preview; governance decides the steps to testnet and mainnet.