The vendor-neutral definition the field uses: protect data in use in a hardware-based, attested TEE, giving confidentiality, integrity, and code integrity.
confidentialcomputing.io
Secure enclaves and confidential computing
Protecting data while a processor is actually working on it. The part of security that used to be the soft spot, now getting a real answer.
A protected boundary around computation
Host system
Protected enclaveDecrypt → compute → encrypt
Isolation from privileged software outside the enclavePlaintext is used inside protected memory.
Encrypted inputEncrypted output
Remote attestationVerify workload identity before releasing a key
Most security guards two moments. This guards the third.
Data sitting in storage is encrypted. Data moving across a network is encrypted. The third moment, data in use, the instant it is decrypted in memory so a processor can work on it, has been the open one. Secure enclaves and confidential computing close that gap.
A secure enclave is a sealed-off region of a chip that runs code and holds data where even the operating system, the hypervisor, and the operator of the machine cannot read it. The hardware encrypts the memory, keeps the keys in silicon, and can prove to you, before you share anything, that the environment is genuine and unmodified. That proof is called remote attestation. Newer chips extend the same idea to GPUs, so models can run on sensitive inputs without exposing them. The rest of this page walks the field: what it is, why it is hard, how it works, what it makes possible, and where it is going.
A sealed room inside the chip.
The frontier has a name and a definition. The field calls it confidential computing, and a vendor-neutral body has pinned down what it means.
Think of data in three states: in transit, at rest, and in use. The first two are encrypted as a matter of course. The third is the one this field is about. The Confidential Computing Consortium defines confidential computing as protecting data in use by running the computation inside a hardware-based, attested Trusted Execution Environment, a TEE CCC 2022. A TEE gives three guarantees: data confidentiality, data integrity, and code integrity.
In plain terms, a secure enclave is a hardware-isolated region where code and data are shielded even from the privileged software you would normally have to trust: the operating system, the hypervisor, other tenants on the same machine, and the operator of the infrastructure. The deep reference on how one actually works is still the SGX writeup Costan 2016.
The landscape today, named neutrally: Intel SGX builds process-level enclaves. Intel TDX and AMD SEV-SNP build VM-level confidential VMs. NVIDIA H100 Confidential Computing reaches the same boundary out to the GPU. Different silicon, one idea.
Protect data during three different states
- In transit
- Encrypt data moving between systems.
- At rest
- Encrypt stored files, objects, and volumes.
- In use
- Protect the execution environment handling plaintext.
The threat model turns inside out.
You are now defending against the software you usually trust. That changes everything about the design, and it is an active research area, not a solved one.
Normally you trust the kernel, the hypervisor, the cloud operator, and your co-tenants. Here you do not. The job is to shrink the trusted core to a tiny, auditable piece and treat everything outside it as untrusted. That single inversion drives the rest.
Memory is exposed by default. DRAM is physically reachable, so the boundary needs hardware memory encryption and integrity, not just access control. Trust also has to be provable at a distance: a remote user needs a way to know they are talking to a genuine, current enclave and not an emulator or a downgraded one, which is what forces attestation and a hardware root of trust.
And enclaves are not magic. Cache-timing and speculative-execution side channels, the Foreshadow family and its successors, show isolation can still leak through the microarchitecture. The honest systematization of the design space and its failure modes is worth reading in full SoK 2022. Performance has a cost too, and accelerators, GPUs and NICs that historically saw plaintext, are the hard frontier.
Define the enclave’s actual threat boundary
| Potential adversary | Design question |
|---|---|
| Host software | Can it inspect protected workload memory? |
| Cloud operator | What access remains outside the TEE? |
| Co-tenant | Which isolation mechanisms apply? |
| Side channel | What information might leak through timing or other observations? |
Exposed data goes in. Only ordered output comes out.
A handful of primitives do the work: a root of trust fused into the chip, memory encryption at the package boundary, a measured boot, and a handshake that proves all of it to someone far away.
It starts with a hardware root of trust: a unique key fused into the chip at manufacture, vouched for by the vendor's certificate authority. Everything else chains back to it. A memory encryption engine then encrypts and decrypts at the package boundary, with keys that are generated in the hardware, scoped per enclave or per VM, and never leave. The operating system and hypervisor sit outside that boundary. They can schedule the workload without ever reading it.
At launch, the TEE hashes its own firmware and code. That measurement becomes the environment's identity. Then comes the handshake. A relying party sends a challenge, the TEE returns its measurement signed by the root of trust, and the verifier checks that signature against the vendor authority and a revocation list before any secret is released inside. A modern, concrete walk through this for a confidential VM is the SEV-SNP e-vTPM paper Narayanan 2023.
Confidential GPUs apply the same playbook. The GPU boots measured, firewalls its own memory, takes data across an encrypted bounce buffer, runs the math on plaintext inside its TEE, and attests just like the CPU. Often the application needs no code changes. And none of this is tied to one vendor: Keystone shows the primitives, isolation plus a small security monitor plus attestation, built on open RISC-V hardware Keystone 2020.
Verify the environment before releasing secrets
- Challenge
The relying party requests fresh attestation evidence.
- Measure
The platform reports the workload and security state.
- Verify
Check signatures, freshness, policy, and platform status.
- Release
Send secrets only if the evidence satisfies the policy.
Compute on data you could not move before.
Regulated data, multi-party data, and private inputs to a model, all on shared or untrusted infrastructure, with the operator unable to read the work.
The payoff is straightforward. Data that was once too sensitive to place on someone else's machine can now be computed on there. For AI, that means running inference over sensitive inputs inside a GPU TEE. The benchmark study on NVIDIA Hopper reports the overhead is mostly the encrypted data transfer, typically under roughly seven percent for common queries, with the cost sitting in data movement rather than the math Hopper 2024.
The deeper shift is verifiable trust instead of trust by reputation. Attestation lets a counterparty check the environment before sharing anything, rather than taking the operator's word for it. And the operator itself is de-privileged: it can run the workload without being able to read it, which shrinks the list of parties you have to trust.
The seven percent figure above is the cited benchmark's result for the hardware it tested. It describes the field, not any one product.
Protect the CPU-to-GPU data path
- CPU TEE
Prepare sensitive inputs inside its protected boundary.
- Protected transfer
Encrypt data moving between the protected components.
- GPU TEE
Run the workload within the GPU’s supported isolation boundary.
- Return result
Protect the transfer back to the authorized recipient.
The shield keeps widening.
From one process to one VM to one GPU to whole accelerated clusters, with portable, standardized ways to verify trust across clouds and chips.
The protected boundary can have different sizes
| Boundary | What is enclosed |
|---|---|
| Process enclave | A selected application component |
| Confidential VM | A virtual machine and its guest workload |
| Accelerated workload | Supported CPU and GPU execution paths |
| Distributed deployment | Multiple attested components and their links |
VM-level TEEs like TDX and SEV-SNP make whole existing workloads confidential with no code changes, a lift-and-shift to confidentiality. Confidential accelerators are heading mainstream: GPU TEEs to begin, then confidential multi-GPU and confidential clusters. Attestation is becoming standardized and interoperable, with vendor-neutral verification directions such as IETF RATS and the Consortium pushing common definitions, so trust can travel across clouds and chips.
Open roots of trust and frameworks like Keystone, plus confidential containers and multi-party patterns, round out the picture. The honest note to close on: the side-channel arms race continues, and the ergonomics of attestation and key management are still maturing. That candor is the point. This is a field moving fast, in the open, and worth understanding on its own terms.
The security conversation has a new question.
Sales conversations carry sensitive material: customer names, pipeline, pricing, what was actually said on a call. Security teams increasingly ask not only where that data is stored, but how it is handled while it is being worked on.
We wrote this page so a technical evaluator can understand the frontier of data-in-use protection on its own terms. The takeaway we want to leave is simple: when sensitive material is involved, it is worth asking how a system handles it while it is being worked on, not only where it is stored. For our actual approach to client isolation, hosting options, and data handling, the specifics live one click away: see Security. For the model itself, our own model, built for sales conversations, see Prism.
The six papers behind this page.
The definitive deep dive on how an enclave actually works: isolation, memory encryption, and attestation. The reference text for the field's foundational primitive.
eprint.iacr.org/2016/086
Shows the TEE building blocks, isolation plus a small security monitor plus attestation, are general and not tied to one vendor. The clearest vendor-neutral how it works.
arxiv.org/abs/1907.10119
Systematizes the design space and the failure modes: side channels, trusted-base size, trade-offs. The honest anchor for why it is hard.
arxiv.org/abs/2205.12742
A concrete, modern look at VM-level confidential computing and how a confidential VM proves itself remotely. Pairs the attestation concept with AMD SEV-SNP.
arxiv.org/abs/2303.16463
Measures the real cost of confidential GPUs for model inference: overhead is mostly the encrypted data transfer, typically under roughly seven percent. Grounds protecting data in use for AI.
arxiv.org/abs/2409.03992
More of the field, explained plainly.
Three more explainers from the same series, each a plain-language tour with links to the source papers.
Back to the research index.
Talk. Done.
You handle the conversation. Prism handles the note, the CRM, and the admin you dread. The easiest way to see it is to hear it.
No app required, just your phone number.