easterbrooka lays the plumbing for envelope encryption on Mike's backend
API keys and share recipients are about to stop sitting in the database as plaintext - but nothing is wired up yet, and that's the point.
easterbrooka has landed the cryptographic groundwork for encrypting the sensitive fields in Mike's backend - the user-supplied Claude and Gemini API keys, and the email addresses people share workflows with. It's a deliberately boring drop: the new encryption library, a wrapper around AWS's key-management service (which holds the master key outside the database), a helper that lets the app still look people up by email without storing the address in the clear, and a database migration that adds the new ciphertext columns alongside the old plaintext ones. None of it is switched on yet.
The split is the interesting choice. By shipping the primitives in isolation, easterbrooka makes the harder follow-up - rewiring the live code paths to read and write both at once during the cutover - reviewable on its own terms. The threat model is named plainly: this defends against someone stealing the database. It does not defend against someone stealing the backend's master credentials.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?