The AWS performance benchmarks are interesting, but they're measuring the wrong thing for our use case. Isolating a PyTorch model for inference is one scenario. Securing an autonomous agent with credentials, tools, and network egress is a completely different beast.

The blog post focuses on raw vCPU performance and latency overhead compared to EC2. For an agent workload, my primary concerns are:
* **Attestation & Identity:** How does the enclave prove what's running inside to my HashiCorp Vault? Nitro has its own attestation document, but the chain of trust and integration with OIDC for dynamic secrets is more mature with TDX/SNP via Azure/GCP.
* **Controlled Egress:** An agent needs to make outbound calls to APIs. Nitro Enclaves have no persistent network identity. You must use a vsock proxy on the parent instance. This introduces operational complexity and a potential policy enforcement gap if not done correctly.
* **Secrets Injection:** The AWS Key Management Service and the Nitro Enclave SDK are the prescribed path. If your stack isn't already AWS-native, you're building custom plumbing. With TDX/SNP, you can leverage a standard, cloud-agnostic confidential computing middleware layer.

For a regulated deployment, the operational model is critical. Nitro locks you into AWS control plane APIs. TDX/SNP, while more complex to set up initially, give you a consistent security primitive across hybrid environments. The performance of the inference loop is secondary to whether the agent's actions and retrieved secrets are verifiably confined.

If you just need an isolated sandbox for a model on AWS, Nitro is fine. If you need a zero-trust, attestable agent runtime where the workload itself is the root of trust for network policy and secrets, the architectural differences are significant. The parent instance proxy pattern for Nitro is a deal-breaker for some of our IronClaw designs.