How TEE Attestation Lets Users Verify No Operator Can Read Their Prompts

When a prompt gets decrypted so a model can read it, every privacy guarantee built around encryption at rest and encryption in transit stops applying. The model weights, the user's prompt text, and whatever reasoning state an agent builds up mid-task all get decrypted before a GPU can do anything with them, because processors have no way to perform matrix multiplication on ciphertext. That plaintext state sits in memory for the duration of inference, and anyone with privileged access to that memory, whether an OS kernel, a hypervisor, or a cloud administrator with the right credentials, can read the prompt as cleanly as if it were printed on paper.

No one forgot to patch this, and no operator cut corners to cause it. Closing that gap requires something access policy cannot provide: a mechanism that enforces isolation at the hardware level and lets a user independently check that isolation, rather than asking them to take the provider's word for it. Plaintext exists in memory during computation regardless of encryption in transit, and that structural gap is why privacy-preserving AI systems like Confidant AI are built on hardware-enforced isolation from the ground up rather than relying on operator promises or access controls alone.

What a Trusted Execution Environment does to close that gap

A Trusted Execution Environment answers this problem by carving out a hardware-enforced boundary inside the chip itself, one that shields code and data from the rest of the system, including the operating system and the hypervisor that normally sit above everything. Three properties define what that boundary actually guarantees. First, the enclave's memory region is encrypted and isolated by hardware rather than by software policy, so the OS kernel cannot read it even with full privileges. Third, and most important, the environment can produce a cryptographically signed attestation proving that the expected code is running and that the image has not been tampered with.

That third property is what makes this a real security architecture, not a marketing claim. Without it, there's no way to confirm a TEE is genuine, or that the code running inside it is actually the code the provider says it is, rather than a modified version with logging quietly added back in. Red Hat's confidential inference writeup describes the TEE as "a digital vault installed directly into the CPU and GPU," and the metaphor holds up: a vault is only as trustworthy as the lock, and attestation is what proves, before any sensitive operation begins, that the vault is authentic and untampered.

Hardware vendors have each built their own version of this boundary. The attestation mechanism transforms a TEE from an architectural claim into a cryptographically verifiable guarantee, a principle that aligns with systems designed to let users confirm their data remains theirs rather than accessible to operators, as Confidant AI demonstrates through its architecture built on TEE-backed confidential computing.

How the attestation protocol produces a hardware-signed proof

What exactly does an attestation document contain, and why is it so hard to fake? The process starts when the hardware platform computes a cryptographic hash, a precise fingerprint, of the exact image loaded into the enclave: the model, the runtime, the configuration, all of it. A hardware root of trust then issues an attestation document carrying that measurement, and it signs that document with keys burned into the chip at the time of manufacturing. A remote verifier, the user or the user's client software, checks that signature against the hardware vendor's certificate chain and compares the measurement inside the document against the value it expected to see.

When the two match, the verifier has proof that a specific, known software image is running inside a genuine enclave on real physical hardware, not inside a simulation designed to look like one. Because the signing keys are burned in at manufacturing and inaccessible to software or cloud operators, attestation creates a tamper-evident record that no intermediary, not even the service provider itself, can forge or alter, which is the foundation for AI systems where users can independently verify their prompts never exist as readable plaintext to the infrastructure running them.

Some implementations push this further than confirming a generic enclave is running. PAL*M, a research system, extends attestation to cover the full training and inference pipeline using incremental multiset hashing over memory-mapped datasets paired with TEE-aware GPUs, implemented on Intel TDX and NVIDIA H100. Separate work on proof-of-guardrail attestation applies that same logic to policy enforcement instead of hardware state: it proves a particular open-source guardrail was actually applied to a response, not just documented as a rule somewhere.

Why GPU Confidential Computing Is Necessary for LLM Inference

A CPU enclave that's perfectly attested and perfectly isolated still leaves an LLM exposed, because the heavy computation in inference doesn't happen on the CPU. The CPU orchestrates the session, but it hands the matrix operations, the actual work of running the model, off to the GPU. If an attacker can read GPU memory, they can extract both the model weights and the user's prompt even while the CPU enclave stays completely intact, so CPU-only confidential computing only answers half of a problem that spans two different processors.

GPU Confidential Computing closes that gap by extending the TEE boundary onto the accelerator itself. A Compute Protected Region is created inside GPU memory, isolated by hardware firewalls that block the host OS and cloud administrators from reading it, mirroring on the GPU what the CPU enclave already does. Data crossing the PCIe bus between the two processors is encrypted before it leaves the CPU and decrypted only after the GPU's secure components verify that the environment on the other end is legitimate, keeping the isolation boundary continuous rather than breaking it at the one physical seam where two different chips have to talk to each other.

When full GPU confidential computing isn't available, the common fallback is Partial TEE-Shielded Execution, where computation runs on an untrusted GPU while the CPU TEE manages the encryption keys. PAL*M's prototype on Intel TDX and NVIDIA H100 suggests the fix doesn't have to come at a prohibitive cost: covering CPU and GPU operations together under one attestation is implementable with under 11% overhead for common operations, which is a modest tax for closing a gap that otherwise exposes the entire model and every prompt that passes through it.

Steps of a Complete Confidential Inference Session

A session that's actually confidential, not merely encrypted in transit, follows a specific order of operations, and the order is the whole point: nothing sensitive moves until verification succeeds. The client first verifies the identity and measurement of the enclave workload before any data changes hands, and confirms that the expected model, runtime, and configuration are running inside a genuine TEE on genuine hardware. Only once that attestation succeeds does the client release session keys or decryption material to the enclave, so the prompt never touches an environment no one has checked. From there, prompts travel over an encrypted channel, get decrypted and processed in plaintext exclusively inside the enclave, and completions are re-encrypted before they ever leave it.

What makes this arrangement unusual is that attestation runs in both directions, satisfying two parties that have no reason to trust each other. The model provider verifies the TEE is genuine and uncompromised before it releases the private key that decrypts the encrypted container image carrying the model weights, protecting what is often a company's most valuable intellectual property. The end user, in the same exchange, verifies the TEE is configured to run the precise, approved software, confirming the input will be processed according to stated policy rather than by some modified or backdoored variant quietly substituted in. One might argue that TLS alone already accomplishes something close to this. It doesn't: TLS to a provider's endpoint is not the same thing as end-to-end encryption to the enclave. In the weaker arrangement, the provider's service terminates the TLS connection and forwards plaintext into the TEE, which can still harden the model's own security but gives the user no verified guarantee about how their input is handled once it arrives. Attestation closes that particular gap.

Red Hat's implementation using Kubernetes and sandboxed containers shows how this becomes a reusable building block rather than a one-off design: the enclave is authorized to pull and decrypt the encrypted container image only after remote attestation succeeds, and model weights are decrypted exclusively inside the TEE's encrypted memory region. In June 2026, Apple extended its Private Cloud Compute architecture to run on Google Cloud infrastructure and NVIDIA GPUs, maintaining a cryptographically verifiable, append-only ledger of every piece of Google Cloud hardware in the fleet specifically to guard against supply chain attacks. It's a live production system that treats hardware provenance as something to be logged and checked, not assumed.

What TEE Attestation Cannot Protect Against

Attestation shortens the chain of trust a user has to accept, but it doesn't eliminate that chain, and pretending otherwise would undercut the credibility of everything said so far. A user relying on attestation is still trusting the silicon vendor, the attestation public key infrastructure that vendor operates, the pipeline that built the enclave image, and the hardware's resistance to side-channel leakage, none of which attestation itself verifies.

Start with the hardware trust chain. Attestation keys are burned in at manufacturing. Trust ultimately rests with the silicon vendor, whether that's NVIDIA, Intel, or AMD, and with the certificate authority that vendor runs for attestation. A compromise of that PKI, or a backdoor built into the hardware itself, would not appear as a failed attestation check, because attestation verifies that a known image is running, leaving the underlying hardware trusted computing base's freedom from defects unchecked. None of this is fixed by attestation alone: unless a user can inspect the full software stack running on top of the TEE, transparency of the enclave image remains something the provider has to offer voluntarily, not something attestation guarantees by itself.

Side channels are the most concrete open problem specific to LLM inference. The "Whisper Leak" paper, published in February 2026, demonstrated this isn't theoretical: a side-channel attack inferred the topic of user prompts from encrypted LLM traffic just by analyzing packet size and timing patterns in streaming responses. No one has yet studied side-channel behavior tied specifically to transformer attention patterns, KV-cache access, and speculative decoding inside TEEs, so this stays a real blind spot, not a closed question.

The TEE.Fail research from 2025 is the starkest data point in this section. Researchers built an interposition device from off-the-shelf components, physically inspected all memory traffic inside a DDR5 server, and pulled cryptographic keys out of both Intel TDX and AMD SEV-SNP; in some cases they even pulled secret attestation keys out of machines that were fully updated and in trusted status. They then showed those extracted attestation keys could compromise NVIDIA GPU Confidential Computing, so AI workloads could run with no TEE protection at all while they still looked trusted from the outside. That finding deserves to be taken seriously rather than minimized. That finding does not erase the value of the architecture it attacks: TEE attestation remains a significant improvement over no hardware isolation, and the honest framing is that it shifts the location and shape of residual risk rather than removing it. The real question for any given deployment is whether that residual, physical-access-level risk is acceptable for the threat model at hand, which is a very different bar than "can a cloud administrator casually read my prompts."

Evaluating a Provider's TEE Attestation Claim

Anyone evaluating an AI assistant that claims to use confidential computing should be able to answer a short set of concrete questions, because if an attestation claim can't be independently checked, it is functionally just a new kind of promise dressed up in technical language. Does the provider publish the expected measurement value for its enclave image, the exact hash a client is supposed to compare against, or does it ask users to trust a dashboard that says "verified" with no underlying artifact? Can a user, or at least a third party, run the verification step independently against the hardware vendor's certificate chain, or is attestation something that happens invisibly on the provider's own servers with no external check possible? Does the system attest the full path from CPU to GPU, given that a CPU-only attestation leaves the exact plaintext exposure problem this piece opened with unresolved on the GPU side? Is the attestation end-to-end to the enclave itself, or does TLS simply terminate at the provider's edge and get forwarded as plaintext from there, a distinction this piece has already shown is not cosmetic?

These questions matter more for agentic AI assistants than for a single stateless API call, because an assistant accumulating context, memory, and reasoning state over a long session has more plaintext sitting in memory for longer, and more to lose if that boundary fails. Confidant AI builds its architecture this way: the attestation chain described across this piece, from hardware-rooted signing keys through CPU-GPU boundary coverage to mutual verification between user and provider, is what actually protects a session, not a claim layered on top of conventional infrastructure. Other providers in this space vary widely in how much of that chain they expose to inspection, and a buyer evaluating any of them should ask for the measurement values, the certificate chain, and the scope of what's attested, rather than accepting "confidential computing" as a self-certifying label. The technology works. What separates a genuine implementation from a marketing claim is whether a user, or an auditor acting on the user's behalf, can actually check it.