Hey everyone, been lurking for a bit and finally have a real question. I'm working on getting our IronClaw deployment ready, and I'm stuck on sealing key management.

We've got a standard dev/staging/prod setup. For our regular services, we use different credential files or environment variables per environment. Easy. But for IronClaw enclaves, the sealing key seems... tied to the hardware? If I understand correctly, it's derived from the platform's root key.

So, if we're testing in dev on actual SGX hardware (we are), wouldn't the enclave seal data with a key that's effectively as strong as the prod one? How do you isolate the data? I don't want a bug in a dev enclave to accidentally seal something that could be unsealed in prod, or vice versa.

My first thought was: why not just use a software-based KMS for this? Have the enclave request an environment-specific key from a KMS at startup, and use *that* for sealing instead of the platform key. You'd get:
- Total separation between environments
- Easy key rotation
- Centralized audit logging

But I'm guessing there's a reason IronClaw doesn't work like that out of the box. Does this break the attestation chain? Is the platform sealing key mandatory for the attestation flow?

What's the standard pattern here? Do you guys just accept that dev/prod sealing keys are cryptographically separated by the MRENCLAVE measurement, so a dev build can't unseal prod data anyway? Or is there a config flag I'm missing to inject a different seed for the sealing key derivation per environment?