El vibe coding entrega la app y, con ella, la filtración

En enero, una red social con IA llamada Moltbook se lanzó con cierto revuelo. Su fundador dijo en voz alta la parte que casi nadie admite: que "no escribió ni una sola línea de código," había construido todo con herramientas de IA. Tres días después, unos investigadores de Wiz encontraron toda la base de datos de producción colgando abierta en internet: 1,5 millones de tokens de autenticación de API, 35.000 direcciones de correo y los mensajes privados de los usuarios, legibles por cualquiera que mirara.

La causa es casi demasiado evidente. El código generado por IA puso la clave de la base de datos directo en el JavaScript del navegador y nunca activó la seguridad a nivel de fila, el único ajuste que convierte esa clave de una llave maestra en una etiqueta inofensiva. Con él activado, exponer la clave es seguro. Sin él, esa clave es la puerta principal, trabada y abierta de par en par. El agente escribió código que funcionaba en la demo y estaba totalmente expuesto en producción, y nadie revisó la diferencia.

Moltbook no es una casualidad. Es la forma predecible de un problema mucho más grande, y si estás entregando código escrito por IA, vale la pena entender por qué sigue pasando.

El número que nadie quiere en la diapositiva

La investigación aquí es notablemente consistente, y es mala. Las pruebas de Veracode encontraron que cerca del 45% del código generado por IA introduce una vulnerabilidad conocida del OWASP, y, lo más condenatorio, que la tasa de aprobación en seguridad se ha mantenido plana en aproximadamente el 55% a lo largo de dos años de mejoras de modelos supuestamente revolucionarias. Los modelos se volvieron más listos escribiendo código. No se volvieron más seguros.

A partir de ahí, se acumula. Un análisis independiente encontró que el código producido por IA carga una tasa de vulnerabilidad 2,74 veces mayor que el código escrito por humanos, no logra defenderse contra cross-site scripting el 86% de las veces y es vulnerable a inyección de logs en el 88% de las muestras. Y está apareciendo en el mundo real: solo en marzo, el Vibe Security Radar de Georgia Tech registró 35 nuevos CVE causados directamente por código generado por IA, frente a seis en enero. La curva de filtraciones se está doblando en la dirección equivocada, rápido.

Por qué el modelo escribe código inseguro por defecto

Esto no es que el modelo sea tonto. Es el modelo haciendo exactamente lo que se le pidió.

Le dices a un agente «constrúyeme un formulario de registro» y lo hace: hace que el formulario funcione. La seguridad no está en la petición, así que no está en el resultado. El modelo optimiza para lo que puedes ver en la demo: el camino feliz, donde el usuario correcto hace lo correcto. No tiene instinto para el camino infeliz, porque el camino infeliz es invisible. Nadie que mira la demo intenta leer los datos de otro usuario, inyectar un script o martillar el endpoint. El atacante hace eso después, cuando no estás mirando.

Esa es toda la trampa. La parte del software en la que el vibe coding es peor es exactamente la parte que no aparece en una demo, y la seguridad es todo camino infeliz. El mismo error de autenticación con la lógica invertida apareció en más de 170 apps en producción: la IA escribió un control de acceso que bloqueaba a los usuarios autenticados y le daba acceso total a los visitantes anónimos. Funcionaba bien en la demo, porque el fundador que la probaba estaba autenticado. El agujero solo se abre para quien no lo está.

La seguridad es la revisión que no puedes vibear

He escrito que el código barato es caro: que el costo del código de IA no desaparece, se mueve aguas abajo hacia quien lo mantiene. La seguridad es la versión más afilada de esa factura, porque no la pagas tú. La pagan tus usuarios, en sus datos filtrados, y llega toda de golpe.

Nada de esto significa que no uses IA para construir. Yo construyo con agentes todos los días. Significa que el paso de generación y el paso de verificación son trabajos distintos, y la IA colapsó solo el primero. Algunos puntos innegociables, aprendidos por la vía fácil viendo a otros aprenderlos por la vía dura:

• Asume que cada secreto que el agente colocó está en el lugar equivocado hasta que lo hayas revisado. La clave de Moltbook en el JavaScript del cliente es la falla más común de todas. Busca claves con grep; muévelas al servidor.
• Activa las protecciones aburridas que la plataforma ya te da. Moltbook murió porque la seguridad a nivel de fila estaba apagada. La protección existía; el agente simplemente no la habilitó. Los valores por defecto son tus amigos: actívalos.
• Prueba el camino infeliz a propósito. Cierra sesión e intenta leer datos. Envía la entrada equivocada. Sé el atacante durante diez minutos, porque el modelo nunca lo será.
• Pasa un escáner de verdad antes de entregar. Una pasada de análisis estático atrapa todo ese aburrido 45%: los secretos hardcodeados, la validación faltante, la inyección clásica, que el agente escribió alegremente.

El encuadre honesto

El vibe coding realmente hizo que construir una app fuera casi gratis. Lo que no hizo gratis es lograr que esa app sea segura para meterle los datos de otras personas, y la brecha entre esas dos cosas nunca ha sido más ancha. La demo es el 80% fácil. La filtración vive en el 20% que ninguna demo te muestra.

Así que entrega rápido, claro. Pero antes de que usuarios reales la toquen, gasta la hora poco glamorosa de ser tu propio atacante. El fundador de Moltbook se saltó esa hora y salió en los titulares por la peor razón que existe. La hora es barata. La filtración no.