We used to manage our agent signing keys with an HSM cluster. It worked, but the operational overhead was brutal. Provisioning, physical security audits, vendor lock-in, and the latency for each signature operation added up. The HSM was a fortress, but our agents needed to move.

Switched to sealing keys inside TEEs (Intel TDX, specifically). The private key material is now generated inside the attested enclave, used there, and never exists in plaintext outside the CPU package. The sealing operation binds the key to the enclave's identity and the platform's TCB.

Our current flow for an IronClaw agent:

* Key generation and sealing happens during provisioning.
* The sealed blob is stored in regular cloud storage (encrypted at rest, but that's just extra).
* At runtime, the agent starts in the TDX enclave, attests to the coordinator, then unseals the key for session establishment.

The critical code is simple. This is the kind of thing that would be a bug farm in C, but Rust's ownership model plus the `tdx-tdcall` crate keeps it manageable:

```rust
let sealed_key = tdx::seal(
&key_material,
&enclave_identity,
SealPolicy::Mrenclave,
)?;
// Write `sealed_key` to persistent storage
```

**Questions for the thread:**
* Has anyone implemented a similar sealing strategy with AMD SEV-SNP or AWS Nitro Enclaves? The attestation flows are different and I'm evaluating portability.
* How are you handling TCB recovery? A sealed blob is useless if the platform firmware updates. We maintain a separate, offline HSM as a recoverable root for re-sealing during authorized updates, but it's clunky.
* Is anyone using a hybrid approach? For example, a root key in an HSM that certifies enclave-held operational keys, to avoid the recovery problem.

The security properties are different from an HSM. You're trading a physical boundary for a cryptographic one tied to the silicon and firmware. For horizontally scaling agents, the trade-off is worth it, but the reliance on the CPU vendor's TCB implementation is non-trivial.