> Keys like this should never be used by a team. They should never touch a developer or devops workstation. That's the point of KeyMux: keys never leave a secu

> Keys like this should never be used by a team. They should never touch a developer or devops workstation. That's the point of KeyMux: keys never leave a secure enclave. In fact, KeyMux has no logic to load private keys or to perform key operations in-memory, except in the context of ephemeral TLS. The TLS layer does support using HSM keys for mTLS authentication, so you can use a security token for peer mTLS authentication to a network attached HSM. That's the whole point--you can use all the tools built and commonly used with in-memory keys, but using enclaved keys, instead. A follow-on idea I'd like to spend time on, if I have the chance, is to write modules for Vault and/or some KMIP implementation that integrate with the app so that authorization for key operations on a networked-attached key store require the consent of multiple parties (with that consent using local secure enclave-based authentication, of course). So, for example, if you're going to roll a release, one developer or an automated pipeline submits the request but the signing awaits confirmation from other team members.