I was just thinking about something like this problem.
At $work, we use multi-signature signing to move cryptocurrency around, so that at least N of M officers of the company need to sign, to prove that "the company" actually intends a movement of funds to happen. This ensures that no single officer can embezzle funds; and it also ensures that an attacker would have to do some kind of multi-target simultaneous coordinated rubber-hose attack (rather than just waiting to kidnap one of us when we go on vacation) to get access to the funds.
I was trying to think of a way to extend that kind of security to the encryption of data — specifically the encryption of low-level root-account passwords (like an AWS account's root password). Shamir's Secret Sharing is the obvious first step... but you'd also then want two additional properties:
1. the decrypted secret should not be held even temporarily by any of the parties, but rather should be held by — and used "through" — a neutral system, so that the secret is reusable rather than needing to be burned the first time it's revealed
2. the neutral system — despite being likely owned by a third party! — should have no ability to exfiltrate the password into the hands of the third party.
I think this can be workable in the specific case of wanting to use the root password as an HMAC, by doing SSS decryption inside a single-shot non-durable abstract machine with homomorphically-encrypted memory, wrapped in a network daemon: the network daemon spins up a copy of the abstract machine; receives each SSS key split from its owner, feeding each as it receives it directly into the abstract machine; the abstract machine, after receiving sufficient key splits, signals to the daemon that it is now "empowered" to sign; and the daemon can then use the abstract machine to HMAC arbitrary plaintexts sent to it, until it exits, and the abstract machine's state is lost.
The real trick, though, would be making this work for HTTP Basic Auth over TLS, by delegating the generation of exactly one TLS frame — the one containing the Authorization header — to the abstract machine; where the network daemon would then act as an HTTP proxy, inserting this Authentication header into requests made through it. Having something like this could really improve security around the use of a lot of sensitive control-plane APIs!
---
Of course, in a corporate context, you probably have a third party you can trust with the plaintext — e.g. an Enterprise Password Manager service — so you can relax property 2. In such a case, you don't need a fancy abstract machine; you can just ask said service to build a feature allowing secrets to be configured to require N-of-M confirmations by ACLed team-members to unlock them; and to build another feature for "opaque secrets" that are never revealed to anyone, but instead are injected into an HTTP Authorization Proxy that the Enterprise Password Manager service spin up themselves on their backend.
But it's still fun to think about the case where your secret is so secret that you need to hide the plaintext from literally everyone but your co-conspiriators,