Gestor de secretos zero-knowledge para desarrolladores

Por qué .env no es un gestor de secretos

Un archivo .env es texto plano en tu disco: se cuela en commits, se comparte por Slack, vive duplicado en cada máquina del equipo y no tiene rotación, ni auditoría, ni revocación. En cuanto hay más de un desarrollador o un despliegue, .env es una fuga esperando fecha.

Con la llegada de los asistentes de código (Claude Code, Cursor, Copilot) el problema se multiplicó: el fallo de seguridad nº1 del código generado por IA son los secretos expuestos — claves hardcodeadas y .env subidos al repo.

Un gestor de secretos resuelve esto centralizando los valores cifrados y sirviéndolos solo a quien debe leerlos, con un registro de cada acceso.

Cómo funciona Koove: cifras local, subes solo el sobre

Con Koove, el secreto se cifra EN TU MÁQUINA antes de salir de ella (envelope encryption: AES-256-GCM para el valor, X25519 + HKDF para sellar la clave por destinatario). El servidor almacena únicamente texto cifrado — no tiene claves privadas, así que no puede leer nada. Eso es zero-knowledge de verdad, y es verificable: las primitivas son open source.

Migrar es un comando: importa tu .env entero y cada clave queda cifrada para tus consumidores autorizados.

# Instala la CLI (Node.js >= 22)
npm install -g @koove/secrets-cli

# Crea tu app: identidad controladora + código de recuperación BIP39
koove app-init

# Guarda un secreto (se cifra localmente; solo sube el sobre)
koove set DATABASE_URL "postgres://..." --env prod

# O migra tu .env completo de una vez
koove import .env --env prod

Solo descifran consumidores verificados

En el edge móvil, un dispositivo solo se convierte en destinatario tras superar attestation criptográfica real — Apple App Attest (verificado extremo a extremo en dispositivo físico) o Google Play Integrity — y el descifrado local está protegido por biometría. En backend y CI/CD, consumidores autorizados con identidad propia.

El servidor decide QUÉ claves públicas son elegibles (gatea con attestation), pero nunca envuelve ni ve la clave de datos. El escritor cifra directamente para el conjunto autorizado.

Ciclo de vida completo, con límites honestos

Rotación de claves sin downtime, revocación por dispositivo con kill criptográfico (saca al revocado de todos los sobres), código de recuperación BIP39 de 24 palabras para el peor día, detección de anomalías server-side y canary tokens que convierten un robo en una alerta confirmada.

Y el límite que otros no te cuentan: ningún sistema puede "des-entregar" un secreto que un dispositivo ya descifró y cacheó. Para un kill total, rotas el valor. Lo decimos en la CLI, en la documentación y aquí.

¿Koove o un gestor generalista?

Preguntas frecuentes