"The provider must not be able to access customer data during processing." The clause turns up in AI procurement documents constantly now, and the answer offered is almost always the same: confidential computing attestation. It is a good technology that answers a narrow question extremely well.
Procurement is usually asking a wider one.
The gap between the two is not obvious from the marketing, and it is not obvious from the specification either. It is worth understanding before you rely on it, because the failure mode is not that the technology breaks — it is that a strong guarantee about one component gets read as a guarantee about the whole system.
The quick answer
An attestation report proves three things: that code is running on genuine hardware from a named vendor, that the code loaded matches a measurement you can compare against a known-good value, and that the environment is configured as expected. It does not prove the code is trustworthy, that data is protected before it arrives or after it leaves, that side channels are closed, or that anyone verified the report. Recent research demonstrates each of those gaps in production-shaped systems, including token reconstruction from a large language model served inside an Intel TDX enclave.
Key takeaways
- Attestation is an integrity proof about a measurement, not a safety proof about behaviour.
- RFC 9334 separates the roles — Attester, Verifier, Relying Party — and the Relying Party's job is the one organisations most often skip.
- The performance objection is largely obsolete: measured overhead for confidential inference on Blackwell GPUs is about 1–3% when configured correctly.
- Misconfiguration, not the technology, is what costs 30–40%.
- Side channels against TEEs remain an active research area, with a 2026 attack reconstructing prompt and response tokens at BLEU above 0.95 from a TDX-protected serving stack.
- A system that logs a failed attestation and continues has implemented the appearance of a control.
What confidential computing actually is
A trusted execution environment runs code in a hardware-isolated region of memory, encrypted so that the host operating system and hypervisor cannot read it. The category exists to close a specific gap: storage encryption protects data at rest, transport encryption protects it in transit, and neither protects it while it is being computed on.
Intel describes its implementation as a technology that "facilitates the deployment of trust domains (TD), which are hardware-isolated virtual machines (VM) designed to protect sensitive data and applications from unauthorized access". AMD's SEV-SNP and Arm's CCA take structurally similar approaches. NVIDIA extends the boundary to the GPU, which is what makes the technology relevant to AI workloads rather than only to databases.
Attestation is the mechanism by which such an environment proves its state to a remote party. Without it, confidential computing is an unverifiable assertion — you would be trusting the host to tell you honestly that it cannot see your data.
What an attestation report proves
RFC 9334, the IETF's Remote ATtestation procedureS architecture, gives the vocabulary. An Attester produces Evidence — "a set of Claims generated by an Attester to be appraised by a Verifier". A Verifier appraises that evidence against reference values and produces Attestation Results. A Relying Party consumes those results and makes an authorisation decision.
That third role is where most implementations go wrong, and the architecture makes the reason legible: producing evidence and appraising it are automatable, but deciding what to do about the answer is a policy your organisation has to write.
Concretely, on NVIDIA's Hopper and Blackwell hardware the flow is well documented. The GPU carries "a device identity certificate (signed with a device-unique ECC-384 key pair)" which you verify against the NVIDIA Certificate Authority, and you are expected to "ensure that the GPU certificate is not revoked" through OCSP. The GPU then generates "a cryptographically signed set of measurements called an attestation report". NVIDIA operates a Remote Attestation Service as the primary verification path, with local verification available for air-gapped deployments.
NVIDIA states the in-scope threat vectors plainly: "Software attacks, Physical attacks, Software rollback attacks, Cryptographical attacks, Replay attacks." That is a genuinely strong list, and it is worth noticing that it is a list — an enumeration of what is covered, which by construction is also a statement about what is not.
The five things attestation does not prove
That the code is trustworthy
Attestation proves which code is running, not that the code behaves well. If the enclave was built to write inputs to external storage, attestation faithfully proves you are running the version that does that. The measurement is only as meaningful as your review of what it measures.
This is not hypothetical. The RealmEye paper, published in August 2026, observes that "kernel rootkits planted via network or supply-chain attacks can hide processes, tamper with kernel data, and exfiltrate model weights under the cover of the same isolation that defends the VM". The isolation that keeps the host out also keeps the owner out. A compromised guest inside a well-attested enclave is a well-attested compromised guest.
That data is protected before and after
The guarantee covers processing. Data arriving over the network and results written to storage are separate problems with separate controls, and an enclave with an unencrypted output path protects the least interesting part of the lifecycle.
Storage is worse than merely out of scope. A 2026 study of confidential filesystems notes that a malicious cloud provider can "roll back, replay, fork, or tamper with disk state, breaking the integrity and freshness guarantees required by stateful applications". Encrypting the disk does not establish that the disk you are reading is the one you last wrote.
That side channels are closed
This is the gap that has moved most since 2024, and it has moved in the direction of AI workloads specifically.
In August 2026, researchers published SparSEEty, an attack on sparsity-exploiting LLM serving systems running inside Intel TDX confidential virtual machines. By building a neuron-activation oracle from weight-access side channels and inverting the activation traces, it reconstructs "both prompt and response tokens with consistently high BLEU scores (>0.95) across various models and datasets", with monitoring overhead of 3.7% to 7.2%.
The optimisation that makes serving fast — skipping work the input does not need — is the same property that makes the input recoverable from the pattern of work done.
That deserves care in both directions. It is a research result against a particular class of sparsity-exploiting stack, not a break of TDX as such, and the mitigations are known. But it is a direct demonstration that "the provider cannot read your prompts" is a claim about a whole system, and that the memory-access patterns of an inference engine carry more of the prompt than intuition suggests. Intel's own materials carry the appropriate caveat: "No product or component can be absolutely secure."
That the vendor is outside the trust boundary
The certificate chain roots in the silicon vendor. You are trusting that they have not retained the keys and have not been compelled to produce them. You have narrowed trust from provider-plus-vendor down to vendor alone, which is real and valuable — and is not the same as trusting nobody.
Where this matters practically is jurisdiction. If your reason for wanting confidential computing is that a particular government should not be able to compel disclosure, then the location and legal exposure of the attestation authority is part of your threat model, not a detail.
That anyone verified it
An attestation document nobody checks is decoration. Verification means validating the certificate chain, checking revocation, comparing the measurement against a known-good value, and failing closed when it does not match.
Systems that log a mismatch and continue serving have implemented the appearance of the control rather than the control. This is the single most common gap, and it is invisible in a demo — the demo always attests successfully.
What it costs
The performance objection deserves updating, because the honest answer changed recently.
A September 2026 benchmarking study of confidential computing on NVIDIA Blackwell GPUs reports that "confidential inference on Blackwell achieves low single-digit throughput overhead when the stack is configured correctly, at about 1-3%", while "stock inference stacks incur 30 to 40% penalties due to avoidable configurations rather than the achievable operating point". It also finds that "GPU compute, energy draw, and usable memory capacity are unaffected".
The gap between 3% and 40% is configuration, and it has a mechanism. NVIDIA notes that in confidential mode, CPU-to-GPU bandwidth is "limited by CPU encryption performance, which we currently measure at roughly 4 GBytes/sec", while GPU raw compute and memory bandwidth stay "at par with non-confidential mode". Every byte crossing the host boundary is encrypted by the CPU; the GPU itself is not slowed down.
| Property | Effect of confidential mode | What follows for design |
|---|---|---|
| GPU compute throughput | Unaffected | Do not budget for a compute penalty |
| GPU memory bandwidth | Unaffected | Model-side performance is unchanged |
| Usable memory capacity | Unaffected | Batch sizing logic carries over |
| Host-to-device bandwidth | Bounded by CPU encryption, roughly 4 GB/s | Amortise transfers; larger batches, fewer round trips |
| Encrypted collectives | Cost scales with NVLink traffic | Watch multi-GPU sharding strategy |
The design implication is consistent: the cost is per host operation and per unit of cross-device traffic, not per unit of compute. Architectures that move data across the boundary frequently in small pieces pay repeatedly. Batch them and the overhead approaches the low single digits.
It is worth doing the arithmetic on cold starts specifically. At roughly 4 GB/s, moving the weights of a large model from host memory into GPU memory takes a few seconds per ten gigabytes — so a hundred-gigabyte model spends something like half a minute crossing the boundary before it serves a single token. That is invisible in a steady-state throughput benchmark and very visible in an autoscaling policy that assumes replicas come up quickly. If your capacity plan depends on scaling out under load, cold-start time is the number confidential mode actually changes.
Where the model genuinely earns its cost
Three cases, for AI workloads specifically.
Multi-party computation. Two organisations that cannot share raw data each verify the same enclave, send inputs, and receive only the agreed output. Neither sees the other's data and both verified the code. This is the case where attestation is doing work nothing else does.
Protecting weights from the host. Serving a proprietary model on infrastructure you do not control, where the concern is extraction of the weights rather than of user data. If you are weighing this against running the model yourself, the arithmetic is mostly about memory footprint — the same constraint that governs what it takes to serve a large open-weights model, and one UniverseBlend covers from the billing side in its breakdown of the hidden fees in a self-hosting bill.
Regulated inference. Where a specific documented technical control is required and attestation satisfies the auditor. Whether that control matches the underlying risk is a separate question, but the requirement is real — and under the EU AI Act's deployer obligations the evidence you retain about how a system was operated is becoming as load-bearing as the control itself. UniverseBlend's rundown of the records regulators actually ask for is a useful cross-check.
Questions worth asking a vendor
- Can we see an attestation document, and what exactly is our verification procedure?
- What happens when verification fails — does the system stop, or log and continue?
- What is the measurement, and can we reproduce the build that produces it?
- How is data protected in transit into and out of the enclave, and how is disk state protected against rollback?
- What is your process when a side-channel vulnerability is disclosed, and what is the patch path?
- Who holds the attestation signing keys, and under what jurisdiction?
Vague answers to the second and third are the ones to worry about. They usually indicate attestation is available rather than enforced — the difference between a capability and a control.
What this means going forward
Two trends are worth watching, without over-predicting either.
The first is that the performance argument against confidential computing is weakening. When the measured overhead for a well-configured serving stack is a few percent and compute is unaffected, "too slow" stops being a reason and becomes an admission about configuration. That will make it harder to decline the control on cost grounds.
The second is that the research frontier has moved from breaking isolation to reading through it. The attacks that matter now are not escapes; they are inferences from timing, memory access and traffic patterns that isolation was never designed to hide. Defending against those is a property of how the workload is written, not of which TEE you bought.
Both point the same way: the technology is maturing into something you should use, and neither trend converts it into the whole-system guarantee that procurement language keeps asking it to be.
Frequently asked questions
Does confidential computing mean the cloud provider cannot see my data?
It means the host operating system and hypervisor cannot read enclave memory, which is a meaningful and hard-won property. It does not cover data before it enters or after it leaves the enclave, does not prevent inference from side channels, and does not remove the silicon vendor from your trust boundary. Treat it as a strong control over one stage of the lifecycle.
How much performance does confidential computing cost on GPUs?
Recent benchmarking of Blackwell hardware reports roughly 1–3% throughput overhead for confidential inference when the stack is configured correctly, with GPU compute, energy draw and usable memory unaffected. Poorly configured stacks measured 30–40% worse. The cost concentrates in host-to-device transfers, which are bounded by CPU encryption at around 4 GB/s.
Is attestation the same as encryption?
No. Encryption keeps memory unreadable to the host. Attestation is a separate, signed statement about what is running and how it is configured, which a remote party can check before sending it anything. You need both: encryption without attestation gives you no way to know the environment is what it claims.
What does "failing closed" mean in practice?
It means that if the certificate chain does not validate, the certificate is revoked, or the measurement does not match your known-good value, the client refuses to send data and the operation aborts. The alternative — recording a warning and proceeding — is common, and it converts the control into telemetry.
Do we need confidential computing to comply with the EU AI Act?
No. The Act does not mandate any specific technology. It imposes obligations around oversight, logging, data governance and transparency, and confidential computing addresses none of those directly. It can be part of how you meet a data protection requirement, but it is not a compliance control in itself.
Final takeaway
Confidential computing is a real advance and worth using where the threat model calls for it. The performance excuse has largely expired. What has not changed is the scope of the claim: attestation proves that specific code is running on genuine hardware in an expected configuration, and every further assurance people attach to it has to be established some other way.
"The provider cannot access our data" is a statement about an entire system. Attestation is a proof about one component of it. Reading the second as the first is how organisations end up with an excellent guarantee about processing and an unexamined gap on either side of it.
Sources and further reading
- RFC 9334, Remote ATtestation procedureS (RATS) Architecture, IETF, January 2023
- NVIDIA, confidential computing on H100 GPUs — threat model, attestation flow and measured bandwidth limits
- Intel Trust Domain Extensions overview
- Asad and Grunseid, Benchmarking Confidential Computing Performance on NVIDIA Blackwell GPUs, arXiv 2608.26575
- Jo, Park, Lee and Song, SparSEEty: Extracting Tokens from Sparsity-Exploiting LLM Serving Systems via Deterministic Side Channels, arXiv 2608.02995
- Qu et al., RealmEye: Virtual Machine Introspection for Arm CCA Realm VMs, arXiv 2608.12822
- Giantsidi et al., Securing Filesystems for Confidential Computing, arXiv 2608.19924
