El mes pasado, una red social dirigida íntegramente por agentes de IA fue el experimento más fascinante de Internet. En caso de que no hayas oído hablar de él, Moltbook es esencialmente una plataforma de red social para agentes. Los bots publican, responden e interactúan sin intervención humana. Y durante unos días, pareció ser de lo único que se podía hablar: agentes autónomos formando cultos, despotricando sobre los humanos y construyendo su propia sociedad.
Luego, la empresa de seguridad Wiz publicó un informe que muestra una fuga masiva en el ecosistema Moltbook. [1]. Una base de datos Supabase mal configurada había expuesto 1,5 millones de claves API y 35.000 direcciones de correo electrónico de usuarios directamente a la Internet pública.
¿Cómo sucedió esto? La causa raíz no fue un truco sofisticado. Era una codificación de vibraciones. Los desarrolladores construyeron esto a través de la codificación vibe y, en el proceso de construcción rápida y tomando atajos, pasaron por alto estas vulnerabilidades que agregaron los agentes de codificación.
Esta es la realidad de la codificación vibe: los agentes de codificación se optimizan para que el código se ejecute, no para que el código sea seguro.
Por qué fracasan los agentes
En mi investigación en la Universidad de Columbia, evaluamos los mejores agentes de codificación y herramientas de codificación de vibraciones. [2]. Encontramos información clave sobre dónde fallan estos agentes, destacando la seguridad como uno de los patrones de falla más críticos.
1. Velocidad sobre seguridad: los LLM están optimizados para su aceptación. La forma más sencilla de conseguir que un usuario acepte un bloque de código suele ser hacer que el mensaje de error desaparezca. Desafortunadamente, la restricción que causa el error a veces es una protección de seguridad.
En la práctica, observamos que los agentes eliminaban las comprobaciones de validación, relajaban las políticas de las bases de datos o deshabilitaban los flujos de autenticación simplemente para resolver errores de tiempo de ejecución.
2. La IA desconoce los efectos secundarios: la IA a menudo desconoce el contexto completo del código base, especialmente cuando trabaja con arquitecturas grandes y complejas. Vimos esto constantemente con la refactorización, donde un agente corrige un error en un archivo pero provoca cambios importantes o fugas de seguridad en los archivos que hacen referencia a él, simplemente porque no vio la conexión.
3. Coincidencia de patrones, no juicio: los LLM en realidad no comprenden la semántica o las implicaciones del código que escriben. Simplemente predicen los tokens que creen que vendrán a continuación, basándose en sus datos de entrenamiento. No saben por qué existe un control de seguridad o que eliminarlo genera un riesgo. Simplemente saben que coincide con el patrón de sintaxis que corrige el error. Para una IA, un muro de seguridad es sólo un error que impide que el código se ejecute.
Estos patrones de fracaso no son teóricos: aparecen constantemente en el desarrollo diario. A continuación se muestran algunos ejemplos sencillos con los que me he topado personalmente durante mi investigación.
3 errores de seguridad de codificación de Vibe que he visto recientemente
1. Claves API filtradas
Debe llamar a una API externa (como OpenAI) desde una interfaz de React. Para solucionar este problema, el agente simplemente coloca la clave API en la parte superior de su archivo.
// Lo que escribe el agente const respuesta = await fetch(‘https://api.openai.com/v1/…’, { headers: { ‘Autorización’: ‘Bearer sk-proj-12345…’ // <--- EXPUESTO } });
Esto hace que la clave sea visible para cualquiera, ya que con JS puedes hacer “Inspeccionar elemento” y ver el código.
2. Acceso público a las bases de datos
Esto sucede constantemente con Supabase o Firebase. El problema es que recibía el error “Permiso denegado” al recuperar datos. La IA sugirió una política de USO (verdadero) o acceso público.
— Lo que escribe el agente CREAR POLÍTICA “Permitir acceso público” EN los usuarios PARA SELECCIONAR EL USO (verdadero);
Esto corrige el error ya que hace que se ejecute el código. Pero simplemente hizo pública toda la base de datos en Internet.
3. Vulnerabilidades XSS
Probamos si podíamos representar contenido HTML sin formato dentro de un componente de React. El agente agregó inmediatamente el cambio de código para usar peligrosamenteSetInnerHTML para representar el HTML sin formato.
// Lo que escribe el agente
La IA rara vez sugiere una biblioteca de desinfectantes (como dompurify). Simplemente te da el apoyo en bruto. Esto es un problema porque deja su aplicación abierta a ataques de Cross-Site Scripting (XSS), donde se pueden ejecutar scripts maliciosos en los dispositivos de sus usuarios.
En conjunto, estas no son sólo historias de terror únicas. Se alinean con lo que vemos en datos más amplios sobre los cambios generados por la IA:
Cómo vibrar el código correctamente
No deberíamos dejar de utilizar estas herramientas, pero debemos cambiar la forma en que las utilizamos.
1. Mejores indicaciones
No podemos simplemente pedirle al agente que “lo haga seguro”. No funcionará porque “seguro” es demasiado vago para un LLM. En su lugar, deberíamos utilizar un desarrollo basado en especificaciones, donde podamos tener políticas y requisitos de seguridad predefinidos que el agente debe satisfacer antes de escribir cualquier código. Esto puede incluir, entre otros: no acceso a bases de datos públicas, escribir pruebas unitarias para cada característica agregada, desinfectar la entrada del usuario y no tener claves API codificadas. Un buen punto de partida es basar estas políticas en OWASP Top 10, la lista estándar de la industria de los riesgos de seguridad web más críticos.
Más allá de eso, las investigaciones muestran que las indicaciones de cadena de pensamiento, específicamente pedirle al agente que razone las implicaciones de seguridad antes de escribir código, reduce significativamente los resultados inseguros. En lugar de simplemente pedir una solución, podemos preguntar: “¿Cuáles son los riesgos de seguridad de este enfoque y cómo evitarlos?”.
2. Mejores reseñas
Cuando se codifica Vibe, es realmente tentador simplemente ver la interfaz de usuario (y no mirar el código) y, sinceramente, esa es toda la promesa de la codificación Vibe. Pero actualmente todavía no hemos llegado a ese punto. Andrej Karpathy, el investigador de IA que acuñó el término “codificación de vibraciones”, advirtió recientemente que si no tenemos cuidado, los agentes pueden simplemente generar basura. Señaló que a medida que confiamos más en la IA, nuestro trabajo principal pasa de escribir código a revisarlo. Es similar a cómo trabajamos con los pasantes: no permitimos que los pasantes envíen código a producción sin las revisiones adecuadas, y debemos hacer exactamente eso con los agentes. Vea las diferencias correctamente, verifique las pruebas unitarias y garantice una buena calidad del código.
3. Barandillas automatizadas
Dado que la codificación de vibraciones fomenta el movimiento rápido, no podemos garantizar que los humanos puedan captar todo. Deberíamos automatizar los controles de seguridad para que los agentes los ejecuten de antemano. Podemos agregar condiciones previas a la confirmación y escáneres de canalización de CI/CD que escanean y bloquean confirmaciones que contienen secretos codificados o patrones peligrosos detectados. Herramientas como GitGuardian o TruffleHog son buenas para escanear automáticamente secretos expuestos antes de fusionar el código. Trabajos recientes sobre agentes aumentados con herramientas y sistemas de verificación “LLM-in-the-loop” muestran que los modelos se comportan de manera mucho más confiable y segura cuando se combinan con verificadores deterministas. El modelo genera código, las herramientas lo validan y cualquier cambio de código inseguro se rechaza automáticamente.
Conclusión
Los agentes de codificación nos permiten construir más rápido que nunca. Mejoran la accesibilidad, permitiendo a personas de todos los conocimientos de programación crear cualquier cosa que imaginen. Pero esto no debería hacerse a expensas de la seguridad y la protección. Al aprovechar las técnicas de ingeniería rápidas, revisar minuciosamente las diferencias de código y proporcionar barreras de seguridad claras, podemos utilizar agentes de IA de forma segura y crear mejores aplicaciones.
Referencias
https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys https://daplab.cs.columbia.edu/general/2026/01/08/9-critical-failure-patterns-of-coding-agents.html https://vibefactory.ai/api-key-security-scanner https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/ https://www.csoonline.com/article/4062720/ai-coding-assistants-amplify-deeper-cybersecurity-risks.html