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.

securityinfrastructure

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.

So what Anyone running a Mike fork that stores third-party API keys or recipient emails should watch this thread land before their next security review.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?