Trusted Execution Environments

A trusted execution environment, or TEE, is a secure, physically isolated region on a processor where code and data can be executed with strong confidentiality guarantees. Unlike the general-purpose computing environment where most applications run, a TEE is designed so that even the host operating system or highly privileged system administrators can’t access or modify what's happening inside. 

The idea is that security shouldn't depend entirely on a software stack or on trusting the people who operate the infrastructure. A TEE enforces protections at the hardware level with capabilities built into the processor itself.  

TEEs were originally developed to protect sensitive operations like digital rights management and mobile payments. They’re now a foundational technology for confidential computing, which protects data while it’s actively being processed, not just at rest or in transit.

When a workload is set to run inside a TEE, the processor creates an isolated execution context, or protected enclave, separate from the rest of the system at the hardware level. Memory assigned to the enclave is encrypted with keys generated and managed by the processor, making its contents unreadable to anything outside the enclave boundary. 

Before any sensitive data or encryption keys are released, the TEE performs what’s known as “attestation,” which proves the environment can be trusted. Specifically, the hardware generates a cryptographic report on the processor's identity, the state of the firmware, and the code loaded into the enclave. This report is then signed using a key embedded in the processor itself, which can’t be extracted or copied. A relying party, which could be either an automated key management system or a human security officer, verifies the report to confirm the environment is genuine and unmodified before any sensitive material is released. 

Once the environment is deemed secure and the keys are released, the workload runs inside the enclave. When the workload is complete, the memory is cleared and the enclave is torn down. 

The main benefit is protecting data during active computation, the "data in use" state that’s more vital than ever in the age of AI inference.  

For organizations that work with regulated data, TEEs give you compliance capabilities that go far beyond old-school policies and manually written logs. Attestation generates cryptographic evidence of the security state at the time of processing, meaning you can easily demonstrate to auditors and regulators that data was protected during computation. 

Meanwhile, for organizations deploying AI models, TEEs protect both the data flowing through the model and the model weights themselves. Model weights loaded for inference are visible in plaintext, making them readable by anyone with access. But model weights are always encrypted inside a TEE, protecting valuable intellectual property that can take many years and resources to build. 

TEEs also enable collaboration that would otherwise require participants to trust one another or a third party. Multiple financial institutions, for example, can contribute data to a joint analysis running inside a TEE where none of them, and not even the infrastructure operator, can see the other's inputs. This level of collaboration is very valuable for use cases like medical research, drug discovery or risk modeling.

Key features include: 

Hardware-enforced memory isolation. The defining feature of a TEE is that its memory boundary is enforced by the processor, not by software. This means the isolation holds against privileged system administrators or malicious threats that software-based security alone can’t stop. 

Memory encryption. Data inside a TEE's memory is encrypted at the hardware level. Even if you had physical access to the machinery, you’d only have useless encrypted bytes and not readable data. The encryption keys are managed by the processor and never exposed to software. 

Remote attestation. Before a workload starts, the hardware can generate a signed report with cryptographic proof of the execution environment's authenticity. 

Attestation-gated key release. Key management systems can be configured to release encryption keys only to environments that have passed attestation. This ensures sensitive data and model weights are never decrypted outside a verified TEE. 

Code integrity verification. The code loaded into a TEE is measured as part of the attestation process. Any modification to the code, including unauthorized patches or malicious substitutions, would show up as a different measurement and cause attestation to fail. 

Isolation from privileged software. The TEE operates independently of the host OS and hypervisor. Neither can read the enclave's memory, modify its code, or inject instructions into it. 

TEE support is implemented in the processor itself, so the starting requirement is a CPU or GPU that includes TEE capabilities. 

On the CPU side, the major supported architectures are Intel Trust Domain Extensions (TDX), which provides VM-level confidential computing on Intel Xeon Scalable processors; AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP), which provides similar VM-level isolation on AMD EPYC processors; and Intel Software Guard Extensions (SGX), an earlier Intel implementation that operates at the application enclave level rather than the VM level. 

GPU-level TEE support is essential for AI workloads because inference runs on GPUs. NVIDIA's Hopper (H100, H200) and Blackwell (B200, RTX Pro 6000) GPUs come with native confidential computing support.  

Beyond the processor, you need an operating system and hypervisor that support TEE technology, an attestation framework to verify TEE reports (either vendor-operated or locally deployed for air-gapped environments), and a key management system capable of enforcing attestation-gated key release.

AI inference has created a pressing security problem that conventional controls don’t address. When an AI model processes a query, both the input data and the model's weights must be present in memory in usable form for the computation to occur. On conventional infrastructure, this means both the data and the model exist in plaintext in GPU memory during inference, essentially readable by anyone with access. 

When an AI model runs inside a TEE, the model weights are loaded in encrypted form and decrypted only within the hardware-enforced enclave boundary. Input data is processed inside that same boundary. Neither the model weights nor the inference data are ever visible during computation. 

This has concrete implications for two separate parties. For enterprises deploying AI on sensitive data like patient records, financial transactions or any other classified information, TEEs ensure that the AI workload can run on that data without exposing it to the infrastructure provider or anyone with system access. For AI model owners deploying proprietary models on third-party infrastructure, TEEs ensure that model weights can’t be extracted by the infrastructure operator or any attacker who obtains access. 

Attestation adds the compliance dimension. Every inference operation in a TEE-protected environment can produce a cryptographically verified record of the environment at the time of processing. This gives you the evidence you need for regulatory requirements that data was protected during active computation. 

As we’ve discussed, TEEs protect sensitive data with three mechanisms that work together: 

1. Isolation. When sensitive data enters a TEE for processing, it enters an environment that’s physically separated from the rest of the system's memory space. The processor enforces this boundary at a level below the operating system, so no software process can read or write the TEE's memory from outside, regardless of the access level. 

2. Encryption. The memory pages assigned to the TEE are encrypted using keys managed entirely by the processor. These keys never appear in any register or memory location accessible to software. Even if an attacker were to physically probe the memory, they would see useless figures. The data is only decryptable within the processor's secure execution context. 

3. Attestation-gated access. Before sensitive data enters the TEE, the system can require the TEE to prove its identity and integrity. The attestation report signed by the hardware confirms that the processor is genuine, the firmware is unmodified, and the code that will process the data matches what was expected and authorized. A key management system that enforces attestation-gated release will only provide decryption keys after the verification succeeds. If any component of the environment is unexpected (wrong firmware version, modified code, different hardware, etc.), the verification fails, and the data isn’t released. 

Understanding these differences can help clarify when TEEs are the right tool for the job. 

TEEs vs. application-layer security. Application-layer controls such as input validation, access management and output filtering operate within the software stack. They can be modified, bypassed or circumvented by anyone with the right system privileges, whether it’s a rogue insider or someone more malicious. TEEs operate below that stack at the hardware level. 

TEEs vs. encryption at rest. Encryption at rest protects data stored on disk from unauthorized access. That’s important, but it does nothing for data once it's loaded into memory for computation. TEEs specifically address the in-memory, in-use state that at-rest encryption leaves unprotected. 

TEEs vs. network-level controls. Firewalls, VPNs and network segmentation protect data in transit and control which systems can communicate. They don't affect what happens to data inside a system during computation. TEEs protect the computation itself, not the network path. 

TEEs vs. hypervisor-based isolation. Traditional VM isolation relies on the hypervisor to enforce boundaries between virtual machines. A compromised or malicious hypervisor could potentially read the memory of the VMs it manages. TEEs are isolated from the hypervisor; the hardware enforces the boundary, so a compromised hypervisor wouldn’t expose TEE contents. 

TEEs vs. software enclaves without hardware backing. Some security approaches implement "enclave" concepts in software with OS-level isolation. These give you relatively useful separation, but can be bypassed by anyone with kernel-level access. TEEs are distinguished by the fact that their isolation is enforced by the hardware, meaning the protection doesn't depend on the trustworthiness of any layer above the hardware.

As AI adoption has skyrocketed over the past few years, trusted computing hardware has advanced significantly as well. One of the most consequential developments is the extension of TEE capabilities to GPUs. 

NVIDIA's Hopper architecture (H100, H200) introduced native confidential computing support for GPUs, extending hardware-enforced memory encryption and attestation to the GPU execution environment for the first time at production scale. Blackwell (B200, RTX Pro 6000) expands on this, delivering performance improvements that make confidential AI inference competitive with non-confidential workloads on previous-generation hardware. NVIDIA's upcoming Vera Rubin architecture is expected to take yet another step forward, with substantially higher inference throughput per megawatt, relevant to both performance efficiency and the economics of confidential AI deployments at scale. 

On the CPU side, Intel TDX has matured into a production-ready technology for VM-level confidential computing, providing a broader memory footprint and simpler application model than the earlier SGX enclave approach. AMD SEV-SNP continues to be widely deployed in cloud confidential computing offerings. Both Intel and AMD have added stronger firmware integrity guarantees and improved side-channel mitigations in recent processor generations. 

The ability to attest both CPU and GPU environments in a single chain of trust is another important and relatively recent development for AI workloads. Because AI inference spans both CPU orchestration and GPU computation, verifying each in isolation creates gaps. Composite attestation covers the full stack. 

Post-quantum cryptography readiness is also an emerging consideration for TEE key management. The encryption schemes that secure TEE memory and attestation signatures will eventually need to be updated to withstand quantum-computing attacks. Leading HSM and key management vendors are beginning to add support for post-quantum algorithms ahead of that transition.

Modern confidential computing has largely addressed this. Fortanix Confidential Computing Manager (CCM) supports a "lift-and-shift" approach for many workloads: existing containerized AI applications can be converted to run in a TEE-protected environment without modifying the application code. CCM handles the enclave lifecycle, attestation, and policy enforcement at the infrastructure layer, allowing teams to bring existing model-serving pipelines, RAG frameworks, and inference applications into a confidential computing environment without rebuilding them. 

NVIDIA's Confidential Computing support on Hopper and Blackwell GPUs is designed to work with existing AI frameworks, including PyTorch and TensorFlow. Workloads that run on conventional NVIDIA GPUs can run on confidential computing-enabled GPUs using the same frameworks and APIs; protection is applied at the hardware layer, so no changes to the application code are needed. 

The critical requirement is that both the CPU TEE and the GPU TEE are properly configured and attested, and that the key management system enforces attestation-gated key release for the model weights and data involved. Fortanix's platform makes the transition to a confidential execution environment operationally manageable for teams that aren't specialists in low-level enclave programming. 

The answer is to run your GenAI workloads inside a trusted execution environment where the cloud provider is cryptographically excluded from accessing your data during processing. 

On conventional cloud infrastructure, the cloud provider operates the hardware and software layers your workload runs on. Even with encryption at rest and in transit, data is eventually decrypted so it can be processed, meaning the cloud provider's administrators could technically read it even if their policies prohibit it. 

When a GenAI application runs inside a TEE on cloud infrastructure (using confidential computing-enabled instances offered by major cloud providers, or on privately operated infrastructure), the cloud provider can’t access the memory contents of the running workload. Cryptographic attestation gives you independent, verifiable proof that the environment is genuine and that your data is being processed in an isolated, protected venue. 

With all of that in mind, these are the steps you should consider: 

• Use a cloud instance or on-premises hardware with both CPU and GPU TEE support 
• Deploy your GenAI application through a confidential computing platform that handles attestation and key management 
• Configure your key management to release decryption keys only to attested environments 
• Verify the attestation report before releasing any sensitive data or model weights into the inference environment.  

Fortanix Confidential Computing Manager and Data Security Manager automate that workflow, making it feasible without deep expertise in enclave programming. 

Confidential computing spans hardware vendors, platform providers and cloud services. 

At the hardware layer, Intel, AMD, and NVIDIA provide the processor-level TEE capabilities that all confidential computing solutions build on. Intel TDX and AMD SEV-SNP provide CPU-level VM isolation. NVIDIA's Hopper and Blackwell GPU architectures provide GPU-level confidential computing for AI workloads. 

At the platform layer, Fortanix Confidential AI is purpose-built for AI and analytics workloads, including composite CPU and GPU attestation, attestation-gated key management, and support for on-premises, sovereign, and hybrid deployments. It protects both the data passing through AI models and the model weights across inference with confidential computing, which Fortanix pioneered over a decade ago. 

Major cloud providers including Microsoft Azure, Google Cloud and AWS offer confidential computing instances based on Intel TDX or AMD SEV-SNP. These provide CPU-level TEE capabilities within their respective cloud environments. For workloads where data sovereignty requires that the cloud provider itself cannot access the data, or where model weights must be protected from the infrastructure operator, organizations typically layer a dedicated confidential computing platform like Fortanix on top of the cloud provider's hardware

Secure LLM inference and training requires confidential computing support at both the CPU and GPU layers, since large language model computation is GPU-intensive. Platforms that only protect the CPU environment leave data unprotected where inference actually happens: the GPU. 

Fortanix Confidential AI is the most comprehensive platform made specifically for this purpose. In fact, Fortanix is validated on Dell AI Factory with NVIDIA, supporting on-premises and sovereign AI factory deployments. 

NVIDIA's Confidential Computing offering, available on Hopper and Blackwell GPUs through NVIDIA AI Enterprise, provides the GPU-level hardware foundation and integrates with attestation services through NVIDIA's Remote Attestation Service (NRAS). This is the hardware layer that platforms like Fortanix build on. 

Microsoft Azure's confidential computing VM options with NVIDIA GPU support provide a cloud-based way to achieve TEE-protected inference, although the cloud provider trust model still applies to the infrastructure layer. 

Securing AI models and training data in the cloud with confidential computing requires tools that address both hardware isolation and key management, because hardware TEEs alone don't enforce who can access the keys that decrypt model weights and training data. 

Fortanix Confidential AI does this using Fortanix Confidential Computing Manager, which handles composite attestation across CPU and GPU TEEs and verifies the integrity of the execution environment before any keys are released. Meanwhile, Fortanix Data Security Manager enforces attestation-gated key release to ensure encryption keys for model weights and training data are delivered only to environments that have passed verified attestation.  

For training data, Fortanix supports confidential fine-tuning workflows in which training occurs within attested TEEs, ensuring the training data is never exposed in plaintext outside the verified enclave during fine-tuning. This protects organizations that are fine-tuning models on proprietary or regulated datasets from both infrastructure-level exposure and insider access during training. 

NVIDIA's GPU confidential computing capabilities are available through cloud providers or on-premises and provide the hardware needed for these workloads. Fortanix integrates with NVIDIA's attestation infrastructure to include GPU attestation in the composite verification chain.

The main requirement for preventing AI training data and prompts from leaking to cloud or model providers is a platform that:  

1. Enforces protection at the hardware level. 
2. Can prove that protection cryptographically. 

This is what Fortanix Confidential AI was built for. The platform runs AI model inference and fine-tuning within hardware-enforced trusted execution environments, where the cloud provider's or model provider's infrastructure can’t access the memory contents of the running workload. Model weights, inference prompts, training data, intermediate computations, and outputs are all processed within the attested enclave, encrypted in hardware memory and invisible to anyone outside the verified TEE. 

Being able to verify it all is crucial. A cloud or model provider might have a policy that promises not to access your data, but a promise isn’t proof. For enterprises in regulated industries, organizations handling classified data, and model owners who want to protect proprietary IP, cryptographically verified evidence is the standard. 

For enterprises evaluating platforms on this basis, think about these key questions:  

• Does the platform protect GPU memory as well as CPU memory?  
• Does it produce independently verifiable attestation evidence? 
• Does it support on-premises or sovereign deployment if cloud infrastructure itself is off-limits? 
• Does the key management component meet relevant certification standards for regulated industries? 

Fortanix answers yes to all four.