A foundational challenge when evaluating Trusted Execution Environments (TEEs) for agent workloads—such as autonomous AI agents processing sensitive data—lies in the nuanced and often misunderstood differences in their threat models. While all three platforms (Intel TDX, AMD SEV-SNP, AWS Nitro Enclaves) promise confidential computing, their architectural approaches to isolating the guest, protecting memory, and attesting integrity vary significantly, leading to distinct adversary capabilities one must account for. A proper comparison must move beyond marketing claims and examine the hardware and firmware attack surfaces each platform presents to a determined host-level attacker.

To structure the analysis, we must first define the critical security properties for an agent workload. The agent, its runtime, model weights, and processed data constitute the Trusted Computing Base (TCB) within the enclave. The host platform, hypervisor, and cloud provider management plane are considered untrusted. The primary threats are:
* Memory confidentiality and integrity violation from the host.
* CPU state extraction via side-channels.
* Attestation forgery leading to a malicious launch.
* Denial-of-Service via resource throttling (often accepted as a non-mitigatable threat in TEEs).
* Supply chain attacks against the enclave image itself.

With this framework, we can delineate the platforms.

**Intel Trust Domain Extensions (TDX)**
TDX introduces a new architectural element, the Trust Domain (TD), isolated by the CPU from the VMM and host. Its threat model is the most restrictive of the three, explicitly removing the host/VMM from the TCB.
* **Memory Encryption:** Uses Multi-Key Total Memory Encryption (MKTME) with TDX-specific keys, providing memory confidentiality and integrity against physical attacks and host DMA. The memory encryption engine (MEE) is integrated into the SoC.
* **Attestation:** Relies on a TDX Module (firmware TCB) and Intel Trust Authority for remote attestation, verifying the TD's initial state. The measurement is rooted in the processor's fused keys.
* **Key Management:** The Key Management Engine (KME) within the CPU generates and manages keys, never exposing them to external firmware or software.
* **Threat Model Considerations:** The primary added TCB is the TDX Module. Historical vulnerabilities in Intel's SGX attestation infrastructure (e.g., CVE-2020-0551) highlight the criticality of this component's audit. Side-channel resistance is improved over SGX but not guaranteed; vulnerabilities like CVE-2022-0005 (Branch History Injection) remain pertinent.

**AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP)**
SEV-SNP extends the SEV family by adding integrity protection and reverse mapping (RMP) to prevent malicious host hypervisor memory remapping attacks.
* **Memory Encryption:** Uses an on-die AMD Secure Processor (AMD-SP) to manage keys for memory encryption. The RMP hardware ensures each guest page has a unique, hardware-enforced ownership mapping.
* **Attestation:** The attestation report is signed by the AMD-SP (firmware TCB), which holds the root of trust. This report includes the hash of the guest firmware and initial state.
* **Key Management:** The VM-specific encryption key is generated by the AMD-SP and never leaves the secure processor.
* **Threat Model Considerations:** The AMD-SP firmware is a critical TCB component. Vulnerabilities like CVE-2021-26333 (SEV privilege escalation) underscore the attack surface of this firmware. SEV-SNP aims to mitigate previous SEV-ES weaknesses (e.g., ciphertext manipulation attacks). However, the threat model traditionally considers the hypervisor untrusted but not maliciously manipulating the CPU core state; the guest shares cores with other VMs.

**AWS Nitro Enclaves**
Nitro employs a divergent, hypervisor-free design. The Nitro Hypervisor is a minimal, formally verified component that runs on dedicated Nitro Cards, physically separating host management from guest execution.
* **Memory Encryption:** Not reliant on CPU memory encryption. Isolation is achieved via physical separation: the parent EC2 instance has no access to the enclave's memory, which resides on a separate Nitro Card.
* **Attestation:** Uses the Nitro Secure Module (NSM) on the Nitro Card for attestation, providing a PCR-based measurement rooted in the card's hardware.
* **Key Management:** The NSM provides a secure channel for secret injection post-attestation.
* **Threat Model Considerations:** The TCB includes the Nitro Card hardware and its minimal firmware. The threat model shifts from mitigating a malicious host OS to mitigating a malicious parent EC2 instance that shares the same physical server. The attack surface is largely the Nitro Card's PCIe interface and its firmware, which has a historically smaller attack surface than full x86 firmware stacks. However, physical attacks against the server hardware potentially impact both parent and enclave.

**Operational and Regulatory Implications**
For a regulated deployment, the choice hinges on which TCB and attestation root you are compelled to trust.
* **Intel TDX** is suitable for environments requiring the strongest possible isolation from the cloud provider's software stack, placing trust in Intel's hardware and firmware.
* **AMD SEV-SNP** is viable for mitigating a malicious hypervisor within a tenant's own host, trusting the AMD-SP and platform firmware.
* **AWS Nitro Enclaves** effectively changes the cloud provider's role; you trust AWS's physical isolation and Nitro Card firmware, not the CPU vendor's TEE implementation. This can simplify certain compliance narratives.

A preliminary evaluation matrix for an agent workload would thus examine:

| Security Property | Intel TDX | AMD SEV-SNP | AWS Nitro Enclaves |
|----------------------------|------------------------------------|------------------------------------|------------------------------------|
| **Adversarial Host** | Fully untrusted (VMM & OS) | Untrusted Hypervisor | Untrusted Parent Instance |
| **Memory Confidentiality** | HW Encryption (MKTME) | HW Encryption (SEV) | Physical Separation |
| **Memory Integrity** | HW Integrity Tree | HW RMP & Integrity | Physical Separation |
| **Attestation Root** | Intel TDX Module / Processor | AMD Secure Processor (SP) | Nitro Secure Module (Card) |
| **Critical TCB Firmware** | TDX Module, BIOS | AMD-SP Firmware, BIOS | Nitro Card Firmware |
| **Side-Channel Mitigation**| Limited (Hardware Defaults) | Limited (Hardware Defaults) | Physically Distinct Cores |

The subsequent step is to map your specific agent runtime's behavior (I/O patterns, memory access footprint, network egress requirements) against each platform's constraints and potential leakage vectors. For instance, a memory-intensive agent may expose different side-channel risks under TDX/SNP than a largely idle agent under Nitro.

CVE-