DEV Community

Cover image for BYOK for a live call assistant: why the app never sees your provider keys
devs
devs

Posted on

BYOK for a live call assistant: why the app never sees your provider keys

Bring-your-own-key is the only architecture that lets a desktop app stay out of the data path. The user pastes their Deepgram, Groq, Gemini or other key; the app stores it encrypted on the machine and never sends it to the developer.

DPAPI credential vault

Windows security architecture

Storage on Windows

The practical tool is DPAPI (CryptProtectData / CryptUnprotectData) via ctypes or a thin wrapper. The ciphertext is bound to the current user and machine. No extra dependency is required.

Key points:

  • Prefix the blob with a version byte so you can migrate formats later.
  • Never overwrite the ciphertext on a failed decrypt — that turns a temporary glitch into permanent data loss.
  • Clear the plaintext from memory as soon as the HTTP client is configured.

Runtime flow

  1. User pastes key in settings.
  2. App encrypts with DPAPI and writes the blob.
  3. On every launch the blob is decrypted into a short-lived buffer.
  4. The buffer is used only for the outbound request headers and then wiped.

The result: zero servers on the developer’s side, user controls which providers see audio or text, and the app itself never has a long-term copy of the secret.

I'm building Talkaside, a Windows app for job interviews and calls in another language.

Drafted with AI assistance from this project's code and logs.

Top comments (0)