BYOK y secretos: tus claves no tocan mi servidor

El servidor no necesita saberlo todo

Cuando tu producto consume modelos de pago, alguien paga la factura de inferencia. Cobrar tú el margen parece negocio hasta que llega la primera factura sorpresa o la primera fuga de claves. El modelo BYOK (bring your own keys) invierte la relación: cada usuario conecta sus propias API keys del proveedor que ya paga, y tu servidor jamás ve el secreto en claro.

El flujo exacto

1. El usuario pega su key una vez en el dashboard.
2. El navegador genera una clave simétrica, cifra la API key con AES-256-GCM vía WebCrypto y envía solo el criptograma al servidor para custodiarlo.
3. En cada ejecución, el servidor devuelve el criptograma, el navegador lo descifra en memoria y firma la petición al proveedor desde el cliente o vía un proxy que nunca registra el secreto.
4. La key en claro no vive en tu base de datos, ni en tus logs, ni en tus backups. No puede filtrarse lo que nunca se almacenó.

Lo que nunca debes hacer

Guardar keys en localStorage en claro, pasarlas como parámetro en URLs, imprimirlas en logs de error o reutilizar una única key maestra para todos los usuarios. Cada una de estas prácticas convierte una brecha menor en un incidente mayor. La regla es binaria: el secreto en claro existe solo en la memoria del navegador del dueño, y solo durante la ejecución.

Auditoría y rotación

Cada uso de cada key queda registrado (cuándo, qué modelo, cuántos tokens) para que el usuario vea su consumo y detecte anomalías. La rotación es un botón: nueva key, nuevo cifrado, la anterior deja de existir. Sin migraciones, sin downtime.

Ejercicio

Dibuja dónde viven hoy los secretos de tu sistema en un diagrama de tres cajas (cliente, tu servidor, proveedor) y marca en rojo cada lugar donde un secreto aparece en claro. Cada marca roja es una línea de este capítulo que te falta por aplicar.

En la próxima lección: cómo saber si tu cambio de prompt mejoró algo o solo lo movió.