This is mostly OK from a security perspective, but we do ship users through a multi-factor auth check before revealing a credential if MFA is configured.

Maybe the right way to do this is:

• Refactor the actual Conduit protocol to not be a giant mess.
• Require MFA when issuing a Conduit token.
• Then let that token skip MFA? This seems a little bit shady, but not terrible.

An explicit option on the credential to allow it to be retrieved without MFA might be OK too.

I think we could merge a patch today where the call fails if your account has MFA configured, and just not provide a workaround for now. Presumably, the daemon/bot account you want to pull credentials with does not use MFA.

This should also be an explicit opt-in mode on passphrase.query or whatever -- that is, the default mode should not return secrets, and should require a needSecrets flag to pull them.

(Access to secrets should also require CAN_EDIT permission. I think this is already enforced automatically.)

A default-off "this can be accessed via the API" flag might not be terrible either, mostly as a provision against human error (e.g., you accidentally issue a broad query with needSecrets and dump it somewhere public-ish -- slightly better if you only get API-permitted credentials). I don't think we strictly need this from a security perspective, though.

I don't think denying access based on MFA or requiring it over Conduit would be very useful because we currently enforce MFA and it would remove the primary use; which is build agents retrieving credentials.

I think the "allow access over Conduit" is far more useful for these kinds of shared secrets.