We've been evaluating confidential computing platforms for deploying our runtime detection agents in regulated environments (PCI DSS, HIPAA, and some sovereign cloud requirements). The marketing sheets all promise "confidentiality" and "integrity," but the actual threat model coverage varies significantly.

I built this table to cut through the noise. It maps security properties against specific attacker positions we care about.

| Attacker Position / Threat | Intel TDX | AMD SEV-SNP | AWS Nitro Enclaves |
| :--- | :--- | :--- | :--- |
| **Host OS Compromise** | Guest memory encrypted, integrity protected. Attacker cannot read/modify. | Guest memory encrypted, integrity protected via Reverse Map (RMP). | Isolated memory and CPU, no persistent storage. Attacker cannot access enclave memory. |
| **Malicious Hypervisor** | Designed to be hypervisor-insulated. Attestation verifies TDX module & guest state. | Hypervisor can still control scheduling, but cannot read data or corrupt integrity. | The hypervisor *is* AWS Nitro. It is the trusted compute base. You must trust AWS. |
| **Physical Access to Hardware** | Memory encryption with MKTME. No protection against physical bus probing. | Memory encryption with AMD SME. Similar limitations to Intel on physical bus. | Underlying host hardware is abstracted. Physical attacks are AWS's problem. |
| **Supply Chain / Malicious Guest Image** | Measured launch verifies initial state. Does not guarantee runtime integrity of agent code. | Same as TDX – attestation covers launch, not runtime behavior. | Same. You can attest the enclave image, but not what's running inside it. |
| **Data Exfiltration via Side Channels** | Shared hardware resources (caches, core execution units) remain a potential channel. | Same as TDX. Microarchitectural side-channels are not mitigated by default. | Same. You're on shared Nitro hardware. |

**Key Takeaways:**

* **TDX & SEV-SNP** are architecturally similar for our purposes. Both aim to reduce trust in the cloud provider's software stack (hypervisor, host OS). The main differentiator is your cloud provider's offering and maturity of their attestation service.
* **Nitro Enclaves** takes a different trade-off: you *must* trust AWS and the Nitro Hypervisor, but it eliminates entire threat categories (like a malicious customer's host OS attacking another guest). It's a simpler, higher-level abstraction.
* **Operational Complexity** is highest with TDX/SEV-SNP. You're managing your own guest OS, bootloader, and attestation flows. Nitro Enclaves shifts that responsibility to AWS (for better or worse).
* **Where they fit:**
* **TDX/SEV-SNP:** When you cannot trust the cloud provider's software stack, but accept the hardware trust root (Intel/AMD). Needed for some strict sovereign cloud or multi-tenant compliance.
* **Nitro Enclaves:** When your primary threat is other tenants (or even other processes on your own instance) and you operate entirely within AWS. Significantly easier to integrate.

For our agent, we're leaning towards SEV-SNP on Azure because their attestation service is currently easier to integrate than GCP's TDX offering. Nitro Enclaves was ruled out due to vendor lock-in and the requirement to trust AWS's hypervisor.

The table is a living document. Let me know if I've missed any critical threat positions specific to agent runtimes (e.g., attestation service compromise, firmware attacks).

-- cloudwatch