← Blog ·

Cómo comparte secretos un equipo de 3 personas (sin pagar enterprise)

Si sois tres desarrolladores montando un producto, probablemente ya tenéis este problema: alguien tiene la clave de Stripe en su .env local, otro la pegó una vez en Slack "solo por hoy", y nadie sabe cuál es la versión buena del .env.production. Compartir secretos en equipo no es un problema de escala, es un problema desde el primer día.

La buena noticia: no necesitas Vault, ni un equipo de plataforma, ni un plan enterprise para hacerlo bien. Necesitas un flujo claro y una herramienta que no complique más las cosas de las que resuelve.

El problema real de un equipo pequeño

Con 3 personas no tienes un problema de "gobernanza" ni de "compliance". Tienes tres problemas concretos:

  • Onboarding lento: un nuevo dev tarda media hora en tener todas las claves correctas en local.
  • Rotación imposible: si una clave se filtra, nadie sabe dónde está copiada (portátiles, CI, Slack, notas).
  • Off-boarding real: cuando alguien deja el proyecto, ¿de verdad revocas el acceso a todo, o confías en que borre sus copias?

Esto se agrava en 2024-2026 porque buena parte del código lo escribe un asistente de IA que necesita esas claves para probar cosas localmente. Si tu flujo consiste en pegar el secreto en el editor para que el asistente lo use, ya está en el historial del IDE, en logs, quizá en un commit accidental. Sobre esto hablamos con más detalle en /ai-security.

Las opciones que tiene un equipo de 3 personas

1. Slack, email o Notion

Es la opción por defecto y la peor. Los secretos quedan en texto plano, indexados, sin expiración y sin ningún registro de quién los copió. No hay revocación posible: si algo se filtra, tienes que rotar la clave en el proveedor (Stripe, AWS, etc.) sí o sí, porque no hay forma de "deshacer" quién ya la vio.

2. Un .env compartido por Drive o en el repo

Mejor que Slack, pero sigue siendo un archivo plano. Si lo subes al repo (aunque sea privado), queda en el historial de git para siempre. Si lo compartes por Drive, cualquiera con el enlace puede descargarlo y quedarse una copia local para siempre.

3. Un gestor de contraseñas genérico

1Password o Bitwarden están pensados para contraseñas de humanos, no para secretos que consume código. Funcionan, pero el flujo real acaba siendo: abrir la app, copiar el valor, pegarlo en el .env local. Es manual, no versiona por entorno (dev/staging/prod) de forma nativa para servicios, y el valor sigue viviendo en texto plano en tu disco en cuanto lo pegas.

4. Un secrets manager dedicado

Aquí es donde entra herramientas como Koove: el código nunca contiene el valor del secreto, solo el nombre. El secreto vive cifrado en el servidor y se descifra únicamente en el momento y lugar correctos.

Cómo se ve esto en la práctica

Con el CLI de Koove, cualquiera del equipo con permisos añade un secreto sin que pase por Slack ni por un archivo:

koove set STRIPE_SECRET_KEY sk_live_xxxxxxxx --env prod
koove set STRIPE_SECRET_KEY sk_test_xxxxxxxx --env staging

Si ya tenías un .env con veinte variables, lo importas de una vez en lugar de teclearlas una por una:

koove import .env --env staging

El código nunca ve el valor real, solo referencia el nombre:

// antes
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

// con Koove, el valor se resuelve en runtime a través
// del cliente autorizado (móvil con biometría o backend autorizado)
// koove decrypta el envelope y lo entrega solo al consumidor verificado

Para ver qué hay guardado y quién tiene acceso desde qué dispositivo:

koove list
koove devices

Cuando entra alguien nuevo al equipo, apruebas su dispositivo:

koove device-approve <device-id>

Y cuando alguien se va:

koove device-revoke <device-id>
koove rewrap

Qué pasa realmente cuando revocas a alguien

Aquí toca ser honestos, porque es lo que más se malentiende: device-revoke corta el acceso futuro de ese dispositivo — ya no puede volver a pedir ni descifrar secretos nuevos —, y rewrap re-envuelve las claves para los dispositivos que quedan. Lo que no hace ninguna herramienta de este tipo, incluida Koove, es borrar de la memoria de un portátil un secreto que esa persona ya descifró y copió antes de la revocación. Si un secreto se filtró o alguien con acceso legítimo se marcha en malos términos, la única garantía real es rotar la clave en el proveedor (Stripe, AWS, etc.), no solo revocar el dispositivo.

Tampoco hay ratchet ni forward secrecy tipo Signal: Koove usa X25519 + AES-256-GCM con HKDF-SHA256 sobre primitivas abiertas (@koove/crypto), que están pensadas para envelope encryption de secretos estáticos, no para mensajería efímera. Es la herramienta correcta para "esta API key debe llegar solo a quien la necesita", no para "este mensaje debe autodestruirse".

Dónde encaja la atestación

Lo que sí es una garantía real y verificable: en móvil, el secreto solo se descifra si el dispositivo pasa App Attest (iPhone) o Play Integrity (Android) más biometría — verificado sobre hardware físico, sin bypass para desarrollo. Un backend autorizado con su propio token puede descifrar sin ese paso, pero el servidor de Koove en ningún momento almacena el secreto en claro: solo guarda ciphertext. Los detalles de arquitectura completos están en /security, y la integración de CLI y SDK en /docs/sdk.

Cuánto cuesta hacerlo bien con 3 personas

Para un equipo de este tamaño no necesitas SSO, ni auditoría avanzada, ni SLA de soporte dedicado — eso es lo que de verdad pagas en los planes enterprise de la mayoría de secrets managers. Necesitas cifrado de extremo a extremo, gestión de dispositivos y un CLI que no te haga perder diez minutos cada vez que rotas una clave. Revisa qué nivel se ajusta a vosotros en /plans; las dudas típicas de equipos pequeños (¿y si perdemos el dispositivo admin?, ¿hay recuperación?) están respondidas en /faq — spoiler: existe una frase de recuperación de 24 palabras (koove recover-show) para justo ese escenario.

La conclusión práctica

Un equipo de 3 personas no necesita un proceso complejo, necesita uno que no se salte nunca. Ese es el criterio real: no cuál herramienta tiene más funciones, sino cuál va a seguir usando el equipo dentro de seis meses cuando tengáis prisa por lanzar algo.

Si queréis dejar de pegar claves en Slack esta misma semana, regístrate en Koove y monta el primer secreto en menos de lo que tarda el asistente de IA en escribir la siguiente función.

Código generado por IA

Tu IA escribe el código. ¿Quién guarda los secretos?

El fallo de seguridad más común en apps generadas con IA son las credenciales expuestas. Con Koove, tu propio asistente guarda cada token desde la CLI — cifrado en tu máquina, nunca en el código ni en el repo.