Marked as helpful by the asker
Your instinct is right. Rules for bring-your-own-key:
- The key goes in once and never comes back out to the browser. The frontend sends it to a server function on save; after that the UI only shows
sk-...a1b2. - Store it encrypted with a secret the database doesn't hold. In Supabase, Vault does exactly this (encrypted at rest, key managed outside your tables). Or encrypt in your Edge Function with a key from an env var (AES-GCM via Web Crypto) and store only the ciphertext.
- Calls to OpenAI happen server-side: the browser calls your Edge Function, which checks the user, decrypts their key, calls OpenAI, returns the result.
- RLS: nobody, not even the owner, can
selectthe encrypted column from the client. Only the function (service role) reads it.
That way a leaked table dump or a buggy policy gives an attacker ciphertext, not working keys.
ok so the browser never touching the key again is the main change. makes sense kwame_o
Moved it to an edge function + Vault. Bolt did most of the work once I told it exactly these 4 rules. kwame_o
Add a rate limit to that edge function too, otherwise one user's script can burn another user's key if you ever mix up ids. 
nils_tw
nils_tw Did not know about Vault. Using this for my Replit app too. halima_s
