willchen96 gives stored API keys their own lock
User API keys can no longer be encrypted with a borrowed credential - the project now demands a dedicated secret or refuses to run.
When users store their own API keys, the backend encrypts them at rest. Until now, if the purpose-built encryption secret wasn't set, the system quietly reached for other credentials instead - including the master key that grants privileged access to the database. That coupling meant two unrelated things shared one secret, and rotating or redeploying either one could ripple into the other in ways nobody could easily predict.
The fix is small but pointed: user keys must be protected by a secret that exists for exactly that job. If it's missing, the backend now fails loudly and stops, rather than silently substituting a shared credential. That forces whoever runs the system to provision the right secret on purpose instead of leaning on a borrowed one by accident.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?