A trusted execution environment (TEE) is a part of a processor that keeps data encrypted even while a program works on it, and proves with a signed report exactly which code it runs.

TEEs are the hardware of confidential computing, the approach to private AI that Apple, Google, Meta, and Microsoft now build on, as we report in Five weeks, seven giants. On 21 October 2026, NVIDIA extended its confidential computing to Grace Blackwell NVL72, a rack of 72 GPUs.

Data has three states, and a TEE protects the third

"In classical computing, data exists in three states: in transit, at rest, and in use," the Confidential Computing Consortium (CCC), a project of the Linux Foundation, writes in its technical analysis. Disk encryption protects data at rest, and TLS protects it in transit, methods that the CCC says "are now commonly deployed."

Data in use is the hard case. A processor works on data in memory, and on an ordinary server that memory holds it in plain text, where the operating system, the hypervisor, and the people who run the server can read it.

Diagram: the three states of data. At rest, stored on a disk, disk encryption protects it. In transit, sent over a network, TLS protects it. In use, in memory while it is processed, a TEE protects it.

The CCC defines confidential computing as "the protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment."

What a TEE is

A TEE is an area of a processor that the hardware walls off from the rest of the machine. The CCC names three guarantees: data confidentiality, data integrity, and code integrity. In its words, "unauthorized entities cannot view data while it is in use within the TEE," and they cannot add, remove, or alter its data or its code.

That shrinks the trusted computing base (TCB), which NIST defines as the "totality of protection mechanisms within a computer system, including hardware, firmware, and software, the combination responsible for enforcing a security policy." On an ordinary server, the TCB takes in the host's operating system, its hypervisor, the cloud's management software, and the people who run them. A TEE cuts it down to the chip, its firmware, and the code inside the TEE.

Diagram: what you must trust. On an ordinary server, you must trust your data and the app, the hypervisor and host OS, the cloud operator and staff, and the CPU, memory, and GPU, and anyone who runs the server can read your data. On a server with a TEE, the TEE holds your data and the app, and the CPU and GPU with the keys inside; the hypervisor, the host OS, the cloud operator, and its staff see only encrypted memory. You trust only the chip and the code you can verify.

TEEs come in two forms:

  • An enclave protects part of one program. Intel SGX, released in 2015, works this way: it sets aside private regions of memory inside one application's process.
  • A confidential virtual machine (confidential VM) protects a whole virtual machine, its operating system included. AMD SEV-SNP and Intel TDX work this way, and AI servers run on them.

Intel is moving to the second form. Diamond Rapids, its next-generation Xeon platform, "will be the last to include Intel SGX," Intel wrote on 9 October 2026, and it keeps investing in Intel TDX, "including trusted I/O with Intel TDX Connect."

Phones have TEEs too. Arm TrustZone splits a processor into a secure world and a non-secure world, and Android's Trusty TEE runs on it.

How the CPU keeps the host out

Two mechanisms do the work: encryption of memory, and control over who may change it.

AMD introduced Secure Encrypted Virtualization (SEV) in 2016 as "the first x86 technology designed to isolate virtual machines (VMs) from the hypervisor," and first shipped it in EPYC 7001 processors in 2017. SEV encrypts each VM's memory with a key of its own. The AMD Secure Processor manages the keys: AMD describes it as a 32-bit Arm Cortex-A5 microcontroller that works as a dedicated security subsystem inside the chip. Each key comes from a hardware random number generator and stays in hardware registers that software cannot read, the hypervisor included. AES engines in the memory controllers do the encryption: 128-bit AES on the first three generations of EPYC, and 256-bit AES-XTS from the EPYC 8004 and 9004 series.

Encryption alone would let a hostile hypervisor replay or move encrypted pages. SEV-SNP, first shipped in EPYC 7003 processors in 2021, adds protection against "data replay, corruption, re-mapping, and aliasing based attacks," in the words of AMD's white paper. Its Reverse Map Table "tracks the owner for each page of memory," so only a VM can write its own pages, and SEV-SNP treats the BIOS, the hypervisor, device drivers, and other VMs as "fully untrusted." Since SEV-ES, the processor's registers are encrypted and protected too, whenever a VM stops running.

Intel TDX builds a hardware-isolated VM that Intel calls a trust domain (TD). A CPU mode of its own, Secure-Arbitration Mode (SEAM), hosts the Intel TDX module, "an Intel-provided, digitally signed, but not encrypted, security-services module" that stands between the hypervisor and each TD, "with the goal of having all system software, including the Hypervisor, out of the trust boundary," according to Intel's white paper. Each TD gets a private key ID of its own, and each key ID gets "a CPU-generated, unique, and ephemeral AES-XTS 128-bit key." For integrity, TDX either adds a 28-bit message authentication code (MAC), based on SHA-3, to memory, or uses a logical scheme that blocks access by software. TDX runs on 5th Gen Xeon Scalable and Xeon 6 processors.

How a GPU joins the TEE

AI models run on GPUs, so a TEE on the CPU alone would leave the model's work outside it. NVIDIA calls the H100 "the first ever GPU to introduce support for confidential computing," and its Blackwell GPUs carry it further.

Diagram: how a GPU joins the TEE. On the left, the CPU TEE holds a confidential VM on AMD SEV-SNP or Intel TDX. In the middle, shared memory holds a bounce buffer with only ciphertext. On the right, the GPU TEE holds the GPU in confidential computing mode, which decrypts inside the GPU. The transfers are encrypted, over PCIe to the GPU; an SPDM session sets the keys and the attestation, and the GPU takes no work until its attestation passes.

NVIDIA's documents describe how the GPU protects its work in confidential computing mode:

  • Each GPU holds "a private signing key that is fused at the time of manufacturing and never exposed to software, firmware, or the host system." Its certificate chains up to NVIDIA's certificate authority, which shows that NVIDIA made the GPU.
  • The driver inside the confidential VM opens an SPDM session with the GPU's firmware, and CUDA programs run only after the GPU's attestation succeeds, NVIDIA's whitepaper says.
  • Every transfer between the CPU and the GPU is encrypted with 256-bit AES-GCM and passes through a bounce buffer in shared memory, so the host sees only ciphertext. The GPU decrypts the data inside itself. The H100's HBM memory sits in the GPU package and is not encrypted: NVIDIA considers it "secure against everyday physical attack tools."
  • Performance counters "are disabled in full CC-On mode," and so is debugging over JTAG.
  • Since driver R590 of December 2025, up to eight Blackwell GPUs can serve one confidential VM over "encrypted NVLink connections."

The GPU's math runs at normal speed. The cost sits at the boundary with the CPU, where every launch of work and every copy of data is encrypted; for inference, NVIDIA wrote in July, "secure work submission latency is often the larger factor." On a tuned stack, the cost comes to a few percent of throughput, as we report in our article on open-weight models.

The protection now reaches whole racks. NVIDIA's announcement of 21 October 2026 covers Grace Blackwell NVL72 and HGX Rubin NVL8 systems, and says that "Google Cloud is extending support for Confidential Bare Metal to A4X Max instances powered by NVIDIA GB300 NVL72 systems."

Remote attestation proves what runs

Encryption keeps outsiders out. Remote attestation shows what is inside: that the TEE is genuine, which code it runs, and how current its firmware is. It takes three steps.

  1. When the TEE starts, the chip measures it: it computes a hash of the code and data loaded into it. A change of one byte changes the hash.
  2. The code inside creates a key pair and asks the chip for a report. On AMD SEV-SNP, the report holds the launch measurement, a SHA-384 hash; the TCB version, the levels of the chip's firmware and microcode; the guest's policy, such as whether debugging is allowed; and 64 bytes of report data that the code chooses, typically a hash of its public key and a nonce from whoever asked. An Intel TDX report carries MRTD, the measurement of the initial contents of the TD, four runtime measurement registers (RTMRs), designed to resemble the PCRs of a TPM, and 64 bytes of REPORTDATA.
  3. The chip signs the report with a key that only it holds. On AMD, that key is usually the Versioned Chip Endorsement Key (VCEK), "unique to each AMD chip running a specific TCB version," and its certificate, from AMD's Key Distribution Service, chains up to the AMD SEV Key (ASK) and the AMD Root Key (ARK). On Intel, the TDX module's report can be verified only on the same machine, so a TD Quoting Enclave turns it into a quote, signed with a key that the platform's Provisioning Certification Key (PCK) certifies, in a chain up to an Intel certificate authority. An NVIDIA GPU signs with its fused key, which chains up to NVIDIA.

Diagram: what an attestation report holds and what your device verifies. The report holds the measurement, a hash of the code at launch; the TCB version, the firmware and microcode; the policy, debugging off; the report data, a public key and a nonce; and a signature with a key only the chip holds. Your device verifies that a genuine chip signed it, that the firmware is up to date, that the code matches the public release, and that the report is fresh, and then it encrypts to the public key. If the verification fails, nothing is sent.

The verifier, such as the user's device, then confirms five things:

  • The signatures chain up to the chip maker's root key, so a genuine chip made the report.
  • The TCB version includes the latest security fixes. Of one fix in 2025, AMD wrote: "A confidential guest can verify the mitigation has been enabled on the target platform through the SEV-SNP attestation report."
  • The measurement equals the hash of the software published for that release.
  • The nonce is the one it sent, so the report is fresh.
  • The public key in the report is the key it encrypts to.

For a GPU, NVIDIA's Remote Attestation Service or a local verifier "compares the evidence against the golden measurements," the reference values that NVIDIA publishes for its firmware, according to NVIDIA's attestation docs.

The expected measurement comes from the code. When the code is open source and its build is reproducible, anyone can rebuild it and get the same hash. The signature of each release can then go into a public transparency log, such as Sigstore's Rekor, which aims to provide "an immutable, tamper-resistant ledger" and stays append-only. Apple's Private Cloud Compute works this way: "user devices will be willing to send data only to PCC nodes that can cryptographically attest to running publicly listed software," Apple wrote in 2024.

Verify first, then encrypt

Attestation replaces a promise with verification, as long as the verification runs on the user's side before any data leaves. The CCC calls this order "Verify-then-Trust."

The device then encrypts its message to the public key in the report with Hybrid Public Key Encryption (HPKE), RFC 9180, a scheme for "public key encryption of arbitrary-sized plaintexts for a recipient public key." Every server on the way carries only ciphertext. If the verification fails, the device sends nothing.

What a TEE leaves out

A TEE narrows whom you must trust. Four things stay outside it:

  • The chip makers, whose root keys and designs anchor every report.
  • Physical attacks on the server.
  • Bugs in firmware, which the makers fix with updates that raise the TCB version in the report, so a verifier can refuse a chip that has not been patched.
  • Metadata: a TEE hides what a request says, not that it was sent, when, or how large it was.

Intel and AMD design their TEEs against attacks through software. AMD's white paper says that "on-line DRAM integrity attacks, such as attacking the DDR bus while the VM is actively running, are out of scope," and Intel's says that "Intel TDX does not defend against replay of memory through physical attacks." Researchers have shown such attacks with a device placed between the processor and its memory: Battering RAM in 2025, with a "$50 interposer" on DDR4 memory; TEE.fail in 2025, which read DDR5 memory with a device built for under $1,000 and forged an Intel TDX quote; and DDRop in 2026, with $159 in parts. Each needs physical access to the server, and AMD and Intel answered that such attacks fall outside their threat models.

Operators answer with physical security and with proof of where machines run. Apple keeps "an append-only ledger of all Google Cloud hardware" in its fleet, with "at least two separate roots of trust from independent vendors," and Intel is developing Platform Owner Endorsements, which let a remote party establish who physically holds the hardware that a workload runs on.

Next, the GPU joins the TEE directly

Today, data between the CPU and the GPU passes through bounce buffers. TEE-I/O removes that step. TDISP, part of the PCI Express specification, lets a device such as a GPU join the CPU's TEE, and IDE gives the PCIe link "confidentiality, integrity, and replay protection," in the words of Intel's TDX Connect specification. Intel's version is Intel TDX Connect, and AMD's is Trusted I/O, formerly SEV-TIO. Linux 6.19, released on 8 February 2026, ships the shared core for TEE-I/O, the PCI TSM, with AMD's first driver for it, and NVIDIA calls Blackwell "the first TEE-I/O capable GPU in the industry."

What it means for a private chat

Thinkr's private lane, the default, runs on these TEEs. Before your browser sends a word, it verifies the remote attestation of the enclave that it talks to, an AMD SEV-SNP confidential VM, up to AMD's root key, and compares its measurement with the signed release in a public transparency log. Then it encrypts your chat with HPKE to the key in the report. That enclave verifies each model enclave the same way before it forwards a chat; the model enclaves run on Intel TDX or AMD SEV-SNP, with NVIDIA GPUs in confidential computing mode. If the verification fails, nothing is sent. How privacy works shows every step.

Sources