verifiable.pro

Main subject

Trusted execution environments for AI

A trusted execution environment (TEE) is a processor mode designed to keep a running AI workload's memory from the host and its operator. Its hardware also signs a report on the software it loaded. This page explains what a checked report establishes. It also tracks the platforms, services and attacks that change what such a report can show.

Why TEEs are this site's main subject

What a checked attestation report establishes, and what it leaves to trust

A checked report shows

  • Genuine hardware from the vendor launched the measured software in a protected mode.
  • The platform runs the firmware versions named in the report, if the verifier checks them against data the vendor signed.
  • The report is fresh, if it carries the random value (nonce) that the verifier chose.
  • Your connection ends inside the environment the report describes, if the report is bound to the session key.

You still trust

  • The chip vendor's design, firmware and keys. The vendor's threat model leaves out some physical attacks and side channels.
  • Whoever publishes the reference values, and the verifier that compares the report with them.
  • The measured software, including how it handles inputs loaded after launch.
  • The operator, which can still stop or restart the environment.

A report identifies the software that was loaded; it does not show that the software behaves correctly or that an output is right.

Remote attestation for AI workloads, explained How to read a remote attestation report How other approaches compare with TEEs

Open questions and core techniques

Key questions

  1. What does a valid attestation report establish? What does it leave open, such as software correctness, physical attacks or the machine's location?
  2. How can outsiders confirm that attested measurements correspond to software images they can inspect?
  3. When attestation evidence covers both a confidential VM and a GPU, is it bound to the same machine and session?
  4. Which parties must still be trusted, including the chip vendor, the cloud operator and the developer of the measured software?
  5. How much performance does confidential inference cost on current GPUs? Which configuration choices drive the overhead?

Core techniques

Confidential virtual machines
AMD SEV-SNP and Intel TDX run a whole virtual machine in encrypted, integrity-protected memory. The hardware is designed to keep that memory from the hypervisor, the software that manages virtual machines. Keys rooted in the hardware sign attestation reports about the machine's launch state.
GPU confidential computing
In confidential-computing mode, an NVIDIA GPU isolates workload memory behind hardware firewalls and exchanges encrypted data with a confidential VM. The GPU also produces a signed attestation report, which can be checked with NVIDIA's Remote Attestation Service or locally.
Attestation-gated key release
In the IETF's RATS architecture for remote attestation, the attester is the environment that produces evidence. A verifier compares that evidence with reference values. A relying party, such as a key server, releases decryption keys only when the verifier's result meets its policy.
Transparency logs for server software
The operator records the measurements of every production software image in an append-only log. Client devices send data only to servers whose attested measurements match a logged release. Outside researchers can inspect those releases (Apple Private Cloud Compute).
Non-targetable request routing
A third-party relay using Oblivious HTTP hides the client's IP address from the operator. An attacker who wants to steer a user's requests by IP address must therefore compromise both the relay and the operator's load balancer (Apple Private Cloud Compute).
Platform and location binding
Confidential-VM attestation is bound to evidence from the host's Trusted Platform Module (TPM). A verifier can then confirm that the workload runs on a specific machine in a trusted data center. The binding is designed to block attestation reports relayed from other machines (Proof of Cloud).

Learn TEEs in order

  1. 1

    Explainer · 8 min read · verifiable.pro Research, automated.

    What makes an AI system verifiable?

    After this you can separate a provider's claim from the evidence that could support it, and name what a check leaves to trust.

  2. 2

    Explainer · 8 min read · verifiable.pro Research, automated.

    Remote attestation for AI workloads, explained

    After this you can name the attester, verifier and relying party in an AI service, and say what a valid report leaves open.

  3. 3

    Guide · 9 min read · verifiable.pro Research, automated.

    How to read a remote attestation report

    After this you can check a report's signature chain, firmware versions, measurements, freshness and connection binding before sending data.

  4. 4

    Analysis · 9 min read · verifiable.pro Research, automated.

    Private AI Compute Services: What the Published Designs Let Outsiders Check

    After this you can compare what Apple, Meta, Google and Cohere let outsiders check about the software that handles requests.

  5. 5

    Analysis · 8 min read · verifiable.pro Research, automated.

    Three Ways to Check an AI Answer: Proofs, Enclaves and Re-execution Compared

    After this you can decide when a TEE's evidence is enough and when to add re-execution or a proof.

  6. Planned CPU TEEs compared: Intel TDX, AMD SEV-SNP and Arm CCA

  7. Planned GPU confidential computing for AI inference

  8. Planned How TEEs fail: physical, side-channel and configuration attacks

CPU TEEs and GPU confidential computing

CPU TEEs

Intel TDX

What is isolated
Whole virtual machines (VMs), called trust domains. Their memory is encrypted and integrity-protected, and the hardware is designed to isolate it from the host and the hypervisor.
Signing key, reference values and threat model
What signs the evidence
The processor's report is converted into a quote signed with an attestation key. The key's certificate chain traces back to an Intel certification authority, and Intel aims to publish the certificates and revocation lists for that chain.
Where reference values come from
A measurement register holds the measurement of the trust domain's initial memory. Software inside the trust domain can extend runtime registers with measurements of code and data it loads later. The expected values come from whoever publishes the VM image.
Out of scope, as the vendor states it
Intel says TDX does not prevent all types of hardware attacks. It places DDRop's physical memory attacks outside its standard threat model for confidential computing.

Sources: Remote attestation for AI workloads, explained · Intel TDX Demystified: A Top-Down Approach · How to read a remote attestation report · Researchers Say DDRop Memory Interposer Can Forge Intel TDX Attestation

AMD SEV-SNP

What is isolated
Whole virtual machines with encrypted, integrity-protected memory. SEV-SNP is designed so that a malicious hypervisor can neither read nor tamper with that memory.
Signing key, reference values and threat model
What signs the evidence
AMD's firmware signs reports with a Versioned Chip Endorsement Key (VCEK). Each chip has its own VCEK, derived from the versions of the chip's trusted components, so a valid signature also identifies those versions. The VCEK's certificate chain traces back to the AMD Root Key (ARK).
Where reference values come from
The AMD Secure Processor measures the VM's initial memory pages and their placement, producing a launch digest. The expected values come from whoever publishes the VM image.
Out of scope, as the vendor states it
AMD lists memory-bus attacks on a running VM as out of scope. It also says its hardware does not specifically prevent architectural side channels.

Sources: AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More · Remote attestation for AI workloads, explained · How to read a remote attestation report

Arm CCA

What is isolated
Hardware-isolated environments called Realms, created by the Realm Management Extension (RME) and managed by the open-source Realm Management Monitor (RMM). The host hypervisor still decides which Realms run and what memory they receive. But the architecture is designed to stop it from accessing or modifying their code and data.
Signing key, reference values and threat model
What signs the evidence
Not yet covered here
Where reference values come from
Not yet covered here
Out of scope, as the vendor states it
Not yet covered here

Sources: Arm Confidential Compute Architecture

GPU confidential computing

NVIDIA Hopper and Blackwell confidential computing

What is isolated
Workload memory on the GPU, which NVIDIA's design places behind hardware firewalls. On H100, the GPU works with a confidential VM on Intel TDX or AMD SEV-SNP. Data transfers, command buffers and CUDA kernels are encrypted before they cross the PCI Express bus between the VM and the GPU.
Signing key, reference values and threat model
What signs the evidence
An identity key burned into the GPU's fuses, whose certificate chain traces back to NVIDIA's certificate authority. The GPU signs an attestation report of its measurements.
Where reference values come from
Reference integrity manifests (RIMs): reference values that NVIDIA generates and signs as part of its driver and GPU firmware builds. NVIDIA's Remote Attestation Service (NRAS) or a local verifier compares the GPU's measurements with them.
Out of scope, as the vendor states it
NVIDIA says the H100's on-package memory is not encrypted and is considered secure against everyday physical attack tools.

Sources: Confidential Computing on NVIDIA H100 GPUs for Secure and Trustworthy AI · NVIDIA Attestation · Remote attestation for AI workloads, explained · Benchmarking Confidential Computing Performance on NVIDIA Blackwell GPUs

A relying party needs CPU and GPU evidence tied to one machine and one session. TEE.fail showed that NVIDIA GPU attestation reports can be borrowed from other machines, because they are not bound to a specific confidential VM.

3 sources

TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition · Remote attestation for AI workloads, explained · How to read a remote attestation report

AI services that publish attestation evidence

Apple, Meta, Google and Cohere route some AI requests to servers whose chips sign a record of the software they loaded. Their published designs differ in what anyone outside each company can check about that software.

ServiceSoftware recordWho checks the attestationWhat outsiders can inspect
Apple Private Cloud Compute (PCC) on Apple silicon
3 sources
Public append-only log; binaries published within 90 days of being loggedUser's devicePublic binaries, Apple's Virtual Research Environment (VRE), some source code, bug bounty
Apple PCC on Google Cloud (preview)
2 sources
Same log; the VRE cannot yet parse these releasesUser's device; protections still being phased inResearch program due later in 2026
Meta Private Processing
4 sources
Measurements in a publicly witnessed ledgerUser's deviceBinaries shared under agreement, bug bounty, published audit
Google Private AI Compute
3 sources
Ledger of digests for critical componentsGoogle's infrastructure; user's device for the memory storeAudits with internal access, open-source memory server
Cohere Model Vault Encrypted
2 sources
Policy registered with Intel Trust AuthorityCustomer's client, via Intel's tokenCohere says its stack is open source

This comparison covers what each provider's publications let outsiders check. It does not rank security, because a system can be well built without being open to review.

As of

Attacks and limits

We list published attacks on TEEs and documented limits, newest first. These attacks target platforms. We have not checked which services are affected.

  1. Trail of Bits review of Google Private AI Compute memory

    No physical access

    What it defeated
    Trail of Bits found that Google sends truncated hashes of response fragments outside the trusted boundary, for a check on whether responses repeat copyrighted text. It also found two flaws, since fixed, in Google's attestation and ledger checks. They would have let two or more unauthorized insiders acting together deploy modified services without a publicly visible ledger entry.
    Access needed, vendor's position and status
    Access needed
    For the ledger flaws, two or more unauthorized insiders acting together. Trail of Bits rated the hash issue hard to exploit.
    Vendor's position
    Google plans a filter inside the enclave so that most hashes never leave it.
    Status
    Eight of ten findings are resolved. The high-severity hash issue remains. Trail of Bits says the planned filter reduces the risk without eliminating it.

    Sources: Google Says It Will Add Encrypted Per-User Memory to Private AI Compute · Private AI Compute Services: What the Published Designs Let Outsiders Check

  2. DDRop

    Needs physical access

    What it defeated
    On Intel TDX, the researchers made a rogue VM pass remote attestation with a legitimate workload's measurement. On AMD SEV-SNP, they copied a victim's memory pages.
    Access needed, vendor's position and status
    Access needed
    A brief, one-time physical visit to install a DDR5 interposer, a small device on the server's memory bus. The attacker also needs control of the host operating system, hypervisor and BIOS. The parts cost $159 per interposer when ten are built.
    Vendor's position
    Intel and AMD say it falls outside their threat models. Intel says it is evaluating further hardening and detection. AMD does not plan to assign a Common Vulnerabilities and Exposures (CVE) identifier or release mitigations.
    Status
    The researchers say software or firmware updates can make the attack harder. A lasting fix, they say, needs memory encryption with integrity and freshness, so that the processor can detect altered or outdated data.

    Sources: Researchers Say DDRop Memory Interposer Can Forge Intel TDX Attestation · Private AI Compute Services: What the Published Designs Let Outsiders Check

  3. Trail of Bits audit of WhatsApp Private Processing

    No physical access

    What it defeated
    Configuration files and the tables that describe hardware to the operating system sat outside the measurement, so tampering with them would not have changed it. The client also trusted the patch level the firmware reported about itself. Reports carried no random value (nonce) from the client, so they could be replayed.
    Access needed, vendor's position and status
    Access needed
    A malicious insider or hypervisor, or an attacker who had compromised a TEE once.
    Vendor's position
    Meta fixed these four findings. For example, the client now checks the patch level against AMD's signed certificate. Each report also carries the client_random nonce from the TLS handshake.
    Status
    The final report, dated 26 August 2025, lists 16 of 28 findings as resolved, four as partly resolved and eight as unresolved. The eight unresolved findings are rated low or informational. Two of the partly resolved findings are rated high: attestation is not bound to Meta-specific machines, and the VM images are not yet fully reproducible.

    Sources: Trail of Bits Reports 28 Findings from Its Pre-Launch Audit of WhatsApp Private Processing

  4. Battering RAM

    Needs physical access

    What it defeated
    Gave plaintext access to Intel Scalable SGX enclave memory and broke AMD SEV-SNP attestation.
    Access needed, vendor's position and status
    Access needed
    An interposer costing under $50, placed between the processor and DDR4 memory.
    Vendor's position
    Intel and AMD said physical attacks on DRAM are out of scope for their current products.
    Status
    The attack works on fully patched systems. The interposer behaves normally during boot-time checks and creates address aliases only later, at runtime. An alias makes two addresses lead to the same memory location.

    Sources: Battering RAM: Low-Cost Interposer Attacks on Confidential Computing via Dynamic Memory Aliasing

  5. TEE.fail

    Needs physical access

    What it defeated
    Extracted keys from Intel TDX and AMD SEV-SNP machines, including an Intel attestation key used to forge TDX quotes. It also showed that NVIDIA GPU attestation reports can be borrowed from other machines, because they are not bound to a specific confidential VM.
    Access needed, vendor's position and status
    Access needed
    A DDR5 memory-bus interposer.

    Sources: TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition

  6. BadRAM

    Needs physical access

    What it defeated
    Bypassed AMD SEV-SNP memory protections and replayed a genuine attestation measurement for a backdoored VM.
    Access needed, vendor's position and status
    Access needed
    A memory module whose serial presence detect (SPD) chip has been altered to misreport the module's size. The equipment costs under $10.
    Status
    AMD shipped firmware that checks memory configuration at boot. Intel TDX and Scalable SGX already had such checks.

    Sources: BadRAM: Practical Memory Aliasing Attacks on Trusted Execution Environments

  7. Undated

    Architectural side channels

    No physical access

    What it defeated
    Confidentiality that relies on memory encryption alone. A side-channel attack infers data from effects of the computation, such as timing, without reading protected memory.
    Access needed, vendor's position and status
    Access needed
    Software on the host, such as a malicious hypervisor.
    Vendor's position
    AMD says SEV-SNP hardware does not specifically prevent architectural side channels.
    Status
    Cohere lists hardware side channels among the residual risks of Model Vault Encrypted.

    Sources: AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More · Remote attestation for AI workloads, explained · Cohere Introduces Confidential Computing for Model Vault in Beta

As of

Responses

Proof of Cloud ·

Proof of Cloud is a proposed design that binds confidential-VM attestation to evidence from the host's Trusted Platform Module (TPM). This tells a verifier that the workload runs on a machine in a trusted data center. It is designed to block attestation reports relayed from other machines.

Sources: Proof of Cloud: Data Center Execution Assurance for Confidential VMs

Latest TEE coverage

All TEE coverage on Latest

  1. OPAQUE Says Its Team Is Joining Anthropic as the Company Winds Down

    · OPAQUE Systems · verifiable.pro Wire, automated. Stack layers: Software & runtime, Hardware & compute.About trusted execution environments.

  2. CSET Says Ping-Based Checks Backed by Inspections Are the Most Feasible Way to Track Exported AI Chips

    · Center for Security and Emerging Technology, Georgetown University · verifiable.pro Wire, automated. Stack layers: Policy, Hardware & compute.About trusted execution environments.

  3. Meta Says It Is Extending Private Processing to Its AI Glasses

    · Engineering at Meta · verifiable.pro Wire, automated. Stack layers: Software & runtime, Hardware & compute.About trusted execution environments.

  4. Google Says It Will Add Encrypted Per-User Memory to Private AI Compute

    · Google DeepMind · verifiable.pro Wire, automated. Stack layers: Software & runtime, Hardware & compute.About trusted execution environments.

  5. Cohere Introduces Confidential Computing for Model Vault in Beta

    · Cohere on X · verifiable.pro Wire, automated. Stack layers: Software & runtime, Hardware & compute.About trusted execution environments.

Primary documents and terms

Architecture and standards

Terms to know

Trusted execution environment (TEE)Confidential VMGPU confidential computingRemote attestationAttesterVerifier (attestation)Relying partyAttestation evidenceMeasurementReference valueAttestation reportAttestation resultEndorsementFreshnessRoot of trustTrusted computing base (TCB)Verifiable transparencyOblivious HTTP (OHTTP)Side-channel attackConfidential computing