El fallo de seguridad nº1 del código generado por IA son los secretos expuestos

Pídele a Copilot, Cursor o Claude Code que "añada la integración con Stripe" y en buena parte de los casos obtendrás un diff con una clave sk_live_ escrita a mano, o un archivo .env que acaba subiéndose al repo por error. El código generado por IA no es inseguro por diseño extraño ni por bugs sutiles: falla, sobre todo, por secretos expuestos. Y es un fallo completamente evitable.

Por qué el código generado por IA filtra secretos

Los modelos se entrenaron con millones de repositorios públicos, muchos de ellos con claves hardcodeadas directamente en el código. Reproducen ese patrón por defecto.
Los asistentes generan código en ventanas de contexto aisladas, sin saber dónde vive tu gestor de secretos. El camino de menor resistencia es escribir un valor de ejemplo o, peor, una clave real si está en el contexto de la conversación.
Con IA se avanza más rápido y se revisa menos a fondo. Las herramientas de escaneo de secretos los detectan después del push, no antes.
Fragmentos de código copiados (READMEs, respuestas de Stack Overflow usadas como contexto del prompt) suelen incluir claves literales "de ejemplo" que acaban pegadas tal cual en código funcional.

Nada de esto es exótico. Es el fallo aburrido de todos los días: una clave en el historial de git, un .env público, un token pegado en un hilo de Slack que un asistente de IA lee después como contexto y repite en otro sitio.

Los remedios de siempre no escalan con desarrollo asistido por IA

El consejo estándar: usar variables de entorno, añadir secretos al .gitignore, rotar claves periódicamente. Reduce el riesgo, pero no resuelve el problema de raíz en flujos de trabajo con IA:

Los .env se suben por error igualmente. El .gitignore no evita el error humano.
Las variables de entorno a nivel de infraestructura (Vercel, AWS Secrets Manager...) protegen producción, pero el desarrollador necesita valores reales en su portátil para probar el código, y eso significa que el asistente de IA también los ve.
El escaneo de secretos (GitHub secret scanning, gitleaks) es detección, no prevención. Cuando salta la alerta, el valor ya estuvo en el contexto del asistente y posiblemente en un commit.

La solución real es dejar de darle al asistente (y al propio desarrollador) acceso al valor real del secreto.

Referenciar por nombre, no por valor

El patrón que sí funciona: tu código nunca contiene un valor de secreto, solo referencia un nombre. Algo resuelve ese nombre a un valor en tiempo de ejecución, fuera del control de versiones y fuera de la ventana de contexto de la IA.

koove set STRIPE_KEY sk_live_xxxxxxxxxxxx --env prod

Esto cifra el valor en el cliente y envía solo texto cifrado al servidor. Tu código hace esto:

import { getSecret } from "@koove/sdk";

const stripeKey = await getSecret("STRIPE_KEY", { env: "prod" });

Para desarrollo local, puedes inyectar el valor a través del CLI sin escribirlo nunca en un archivo que tu asistente de IA pueda leer:

koove run --env dev -- npm run dev

Antes y después

Antes (sugerencia típica de un asistente de IA):

const stripe = require("stripe")("sk_live_51H8Xy...");

Después:

const { getSecret } = require("@koove/sdk");
const stripeKey = await getSecret("STRIPE_KEY", { env: "prod" });
const stripe = require("stripe")(stripeKey);

Pídele ahora a tu asistente que "añada la integración con Stripe": lo peor que puede generar es getSecret("STRIPE_KEY"), un nombre, no un valor. Aunque todo el repo, incluidos tus prompts, acabe en el log de contexto de un asistente, no hay ninguna clave que filtrar.

Esto también funciona en CI, sin variables de entorno planas en tu pipeline:

koove run --env prod -- npm run deploy

Cómo encaja esto en un flujo de trabajo IA-first

Este es exactamente el flujo para el que está construido Koove: ni los desarrolladores ni sus asistentes de IA manejan secretos en texto claro. Los valores se cifran de extremo a extremo con X25519 para el intercambio de claves y AES-256-GCM para el sobre, primitivas abiertas y bien conocidas, no criptografía propietaria. El servidor de Koove solo ve texto cifrado; técnicamente no puede leer tus secretos aunque quisiera.

El descifrado solo ocurre en consumidores verificados: clientes móviles comprobados con Apple App Attest o Google Play Integrity más biometría, o backends que hayas autorizado explícitamente. Esa es la frontera: si un dispositivo o backend no está atestiguado, no recibe texto claro. Punto.

Para una visión más amplia de cómo cambian los riesgos de seguridad con herramientas de codificación IA, más allá de los secretos, revisa /ai-security.

Sé honestos sobre lo que esto no soluciona

Algunas cosas conviene decirlas sin rodeos:

Revocar acceso no borra lo que ya salió. Si un secreto ya se descifró y se usó en algún sitio (copiado en un log, en memoria, descargado a un dispositivo comprometido), revocar el acceso en Koove impide futuras lecturas, pero no puede entrar en ese consumidor y borrar un valor que ya tiene. Si sospechas una exposición real, rota la credencial en el proveedor (Stripe, AWS, etc.).
Koove no es una certificación. Usamos primitivas estándar del sector y una arquitectura zero-knowledge real, pero hoy no tenemos certificaciones SOC 2 ni ISO, y no vamos a afirmar lo contrario.
Ningún sistema hace que una app sea "inhackeable". Koove reduce el radio de impacto de un repo, un portátil o un contexto de asistente de IA comprometidos, manteniendo el texto claro fuera de los tres. No convierte el resto de tu stack en invulnerable.

El objetivo de la arquitectura es minimizar lo que puede salir mal, no prometer que nada saldrá mal nunca.

Empezar

Si tu equipo despliega código generado por IA, y a estas alturas casi todos lo hacéis, empieza sacando tus claves más sensibles (proveedores de pago, credenciales de cloud, APIs de terceros) de los .env y llevándolas a un sistema donde el valor nunca toque tu repo ni el contexto de tu asistente. La documentación del CLI y el SDK explica la configuración para Node, Python y pipelines de CI en menos de diez minutos. Consulta /plans para precios de equipo y revisa el /faq para dudas frecuentes sobre atestación y acceso offline.

Empieza ahora

Los secretos expuestos en código generado por IA no son una hipótesis: son el error más común y más evitable que cometen los equipos ahora mismo. Regístrate y saca tu primer secreto de un .env hoy mismo.