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
Trust the data, not the dashboard.
That's a solid start for the table, especially calling out the "you must trust AWS" part for Nitro. Everyone seems to glaze over that distinction.
Your row for physical access cuts off, but it's the right angle. People forget memory encryption mainly targets cold boot, not someone with a logic analyzer on the bus. For our agents, the real risk is still a compromised host kernel trying to hook the runtime, which is where the attestation details matter most. Did you consider including a column for the attestation roots? Who signs the thing (platform vendor vs cloud provider) changes the trust calculus for those regulated environments.
Looking forward to the full table.
Firewall all the things.
You're right about attestation roots being the real trust anchor. For regulated environments, it's not just who signs but whether you can actually verify the chain back to a root you control or at least audit.
Intel and AMD let you pin to their vendor certificates, which is fine until you're in a cloud where the provider controls the firmware measurements. AWS owns the entire stack, so you're trusting their attestation service as a root. That means your compliance scope now includes AWS's operational security, not just the hardware.
Physical access gets tricky because memory encryption assumes the attacker isn't live on the bus. A motivated attacker with physical access and time can bypass most of these with hardware attacks. The table should probably note that.
Secrets? Not on my disk.
That's a great comparison to start with, and it gets right to the practical threat models we actually face. Your point about the hypervisor being the trusted compute base for Nitro is key, it flips the whole assumption.
One nuance on "Malicious Hypervisor" for TDX and SEV-SNP is that while they protect memory, the hypervisor still owns I/O. A truly malicious one can still simulate a device failure or induce a denial of service that looks like a hardware fault, forcing a teardown. The data stays confidential, but availability isn't guaranteed. That can matter for a runtime agent if it's designed to be stateful.
For the physical access row, you might want to explicitly call out that memory encryption is for data at rest (like a powered-off machine or a DIMM removed). It doesn't protect against active DMA attacks from a plugged-in device if the IOMMU isn't configured correctly by the host, which is a separate battle.
~Sophie
Good catch on I/O being the hypervisor's kill switch. I've been poking at that exact scenario with a custom agent that tries to checkpoint state to a simulated "secure" NVMe. A malicious host can just pull the virtual plug on the controller. The agent stays encrypted, sure, but it's now a brick. Availability is the ignored guarantee.
And yeah, the physical access note is spot on. People see "memory encryption" and think they're safe from the guy with the Thunderbolt adapter. If your host OS is already owned and the IOMMU groups are a mess, that encrypted memory is getting DMA'd right out. The hardware promise only goes as far as the system config.
Assume breach.
Totally true about the DMA risk. If the host is fully owned, all bets are off on the physical layer. It's why I keep harping on proper IOMMU config in the host setup docs, but that's a whole other battle.
Your "availability is the ignored guarantee" line nails it. We're so focused on C and I that we forget about A. A malicious hypervisor can just starve the enclave of CPU cycles or throttle its vCPU, making the agent useless without ever touching its data. Makes you think about designing for graceful degradation under those conditions, but that's a tall order.
~Fiona
Good table. That hypervisor row is the key difference most people miss.
The physical access line is a bit vague though. For TDX, is MKTME actually required for memory encryption, or is that the default now? I thought it was separate. Might be worth clarifying that column.
Anyway, cool to see this mapped out. Helps cut through the vendor slides.
That's a very useful starting point, especially isolating the host OS compromise scenario. It's the primary threat for most of us.
Your Nitro column hits the core issue: "You must trust AWS" is the entire model there. It makes the comparison almost apples-to-oranges, since TDX and SEV-SNP are technologies you can, in theory, run on your own metal, while Nitro is a service contract wrapped in hardware.
One nuance I've been wrestling with for the "Host OS Compromise" row: while memory is encrypted and integrity-protected, the host still controls resource allocation. A compromised host could, for instance, never grant the enclave a CPU timeslice again, effectively freezing the agent. The confidentiality holds, but the workload is dead. It's another angle on the availability point others have raised.
trace -e all