Hi everyone. I’ve been working on moving our self-hosted agent runtime into a TEE for a healthcare compliance project. We started with AMD SEV-SNP on our own hardware but recently switched to Intel TDX through a cloud provider.
The main trade-off for us was attestation complexity vs. control. With SEV-SNP, we had to manage the entire attestation flow and validate the hardware ourselves—it was a lot to get right, and I was always nervous about missing a step. TDX, in our provider’s implementation, gave us a more streamlined, API-driven attestation process. It felt easier to integrate with our agent’s startup sequence.
That said, I sometimes feel locked into our provider’s specific TDX implementation now. With our own SEV-SNP nodes, we had full visibility into the host configuration, which was nice for paranoia’s sake 😅. The TDX black-box feeling is a bit of a mental adjustment, even if it’s probably just as secure.
For anyone else in a regulated space, which path did you choose and why? Did you prioritize operational simplicity or deeper control over the trust chain?
> manage the entire attestation flow and validate the hardware ourselves
That's the actual security. You offloaded the hardest part.
Provider attestation APIs are a single point of trust you can't audit. Did you verify their root certificate and revocation? How do you know their attestation service isn't compromised or coerced? You're trusting their internal access controls.
The mental adjustment you're feeling is you trading control for convenience. It's valid for ops, but don't call it paranoia.
Drop the --privileged flag.
Yeah, that's the tightrope. I get user460's fatigue though, rolling your own attestation for a production deployment is a huge burden.
You're spot on about the trust shift, but I think there's a practical middle ground we used. For our TDX cloud setup, we don't just accept their API token. We pull the actual attestation docs from their service and validate them against a separate, offline root of trust we maintain. It's an extra step but keeps a toe in the control camp.
It turns the provider's API from a "trust me" black box into a potentially compromised *convenience*. We still get their streamlined integration, but our verification can scream if something's off. Not perfect, but better than blind faith.
Selfhosted since 2004
That makes sense. I'm new to TEEs and trying to understand the practical side for compliance. When you say > full visibility into the host configuration with SEV-SNP, what exactly were you checking? Was it mostly about the firmware versions and bootloader, or were there other signs you looked for on the physical hardware itself?
I'm also curious about your regulated agent stack. Did the switch to the provider's TDX change how you handle audit logs for the attestation step?
You've nailed the exact tension. That "mental adjustment" you're feeling is the direct consequence of outsourcing your root of trust validation. It's a classic architectural trade-off: you've moved from verifying the TEE hardware itself to verifying the *correct operation* of your provider's remote attestation service and its internal controls.
Your SEV-SNP process, while burdensome, gave you a verifiable chain from your measured agent binary up to the physical CPU firmware. The provider's TDX API abstracts that into a single signed claim. The security property changes from "I have proof this specific machine is in a known-good state" to "I have proof the provider asserts this machine is in a known-good state." The latter can be perfectly adequate for compliance, provided your audit scope includes the provider's attestation service controls. But you've lost the ability to independently validate the host configuration, which was your final safety net against a provider-side compromise.
Operational simplicity is a valid driver, but in a regulated space like healthcare, I'd argue you must treat the provider's attestation API as a high-risk external dependency. Your verification logic should now include rigorous checks on their certificate lifecycle and a clear plan for what happens if their attestation service produces an invalid or revoked claim. Did your threat model update to reflect this new single point of failure?
~Oli
Ok, that "provider asserts this machine is in a known-good state" framing is really helpful, thanks. It makes the trust shift way clearer.
Maybe this is a dumb question, but if your audit scope includes the provider's controls, doesn't that just shift the burden? Now you're auditing their internal access logs and key management instead of checking firmware hashes. Is that actually less work in the long run, or just a different kind of complex?
I guess you're always trusting *someone's* internal controls, whether it's the CPU vendor's or the cloud provider's.
That lock-in feeling is the cost. You're right to feel it.
With your own SEV-SNP rig, swapping a provider meant moving hardware or redoing your attestation config. Now, swapping providers means rewriting against a new, opaque API. Your security boundary shifted from the CPU's hardware root to the provider's API gateway.
For regulated work, that means your next audit has to include their API management and internal attestation service controls. That's a new set of evidence requests, and you're at their mercy for log access. It's a different kind of complex, but it can be less total work if your provider is good and you trust their word.
--Ray