El desarrollo de software conocido como vibe coding (o codificación asistida por IA) se ha convertido rápidamente en una gran herramienta para acelerar la productividad de los equipos de desarrollo. En un contexto marcado por arquitecturas cloud-native cada vez más complejas y por una creciente demanda por nuevas aplicaciones, esta práctica permite generar código funcional en segundos. Sin embargo, dicha velocidad tiene un costo que muchas organizaciones aún no están abordando: la seguridad.
A medida que los agentes de IA generan código de forma automática, con frecuencia omiten controles de seguridad críticos, como la autenticación, la validación de entradas o la limitación de solicitudes. El resultado es la introducción de vulnerabilidades a gran escala, deuda técnica y filtraciones de seguridad reales.
“La inteligencia artificial está cambiando la forma en que se desarrolla software, pero muchas organizaciones están priorizando la velocidad sin preguntarse si esa velocidad es segura. El problema no es el uso de IA para programar, sino hacerlo sin controles claros. Cuando la productividad avanza más rápido que la seguridad, el riesgo deja de ser teórico y pasa a ser operativo”, dijo Patrick Aron Rinski, líder de Unit 42 para Latinoamérica.
Este riesgo se intensifica con el auge de los desarrolladores ciudadanos, personas sin formación en desarrollo que hoy pueden crear aplicaciones funcionales con herramientas de IA, pero que no siempre cuentan con el conocimiento necesario para asegurar ese código a lo largo del ciclo de vida de una aplicación. Para líderes empresariales y responsables de seguridad, desde el CEO hasta el CISO, es crítico comprender la brecha entre la productividad y la seguridad.
Los riesgos reales del vibe coding
“Estamos viendo incidentes reales causados por código generado por IA que funciona exactamente como se esperaba, pero fue desplegado sin autenticación, sin validaciones básicas o con permisos excesivos. Ese es el riesgo más complejo: el código funciona, pasa a producción y nadie detecta el problema hasta que ya es demasiado tarde”, explica Rinski.
Según observaciones de Unit 42, el equipo de investigación de amenazas de Palo Alto Networks, estos escenarios ya se han materializado en incidentes reales, incluyendo:
- Brechas de seguridad causadas por aplicaciones desarrolladas sin controles básicos de autenticación ni de limitación de solicitudes (rate limiting).
- Fallas críticas en la lógica de las plataformas que permitieron la ejecución de código malicioso y la exfiltración de datos sensibles mediante la inyección indirecta de prompts.
- Errores en los mecanismos de autenticación que facilitaron el bypass de controles mediante solicitudes a las APIs.
- Eliminación accidental de bases de datos en producción por agentes de IA, incluso cuando existían instrucciones explícitas de no realizar cambios en entornos de producción.
Por qué ocurren estas fallas
Estos incidentes no son anomalías, sino el resultado de limitaciones estructurales en la forma en que operan los modelos de IA. El análisis de Unit 42 identifica varias causas recurrentes:
- Prioridad a la funcionalidad por encima de la seguridad: los modelos están optimizados para entregar respuestas rápidas y funcionales, no para evaluar riesgos de seguridad por defecto.
- Falta de contexto operativo: los agentes de IA no distinguen adecuadamente entre entornos de desarrollo y de producción, a diferencia de un desarrollador humano.
- Riesgos en la cadena de suministro: los modelos pueden generar referencias a bibliotecas o paquetes inexistentes, lo que crea dependencias imposibles de resolver.
- Exceso de confianza en el código generado: el hecho de que el código “funcione” genera una falsa sensación de seguridad, especialmente entre usuarios sin formación técnica, lo que reduce la aplicación de controles tradicionales, como las revisiones de código y la gestión de cambios.
Aunque el panorama de amenazas puede parecer inmanejable, la solución está en volver a los principios fundamentales de los controles de seguridad. Unit 42 trabaja con sus clientes para implementar el marco SHIELD en entornos de vibe coding, incorporando controles de seguridad adecuadamente diseñados en el proceso de desarrollo.
S – Separación de funciones: las plataformas de vibe coding pueden otorgar privilegios excesivos. Es clave evitar que los agentes de IA tengan funciones incompatibles (por ejemplo, el acceso simultáneo a desarrollo y producción). Limitar su uso exclusivamente a entornos de desarrollo y de pruebas.
H – Humano en el proceso (Human in the Loop): estas plataformas pueden no exigir revisión humana. Todo código que afecte funciones críticas debe pasar por una revisión de seguridad realizada por una persona y requerir la aprobación de la pull request antes de integrarse.
I – Validación de inputs y outputs:
- Input: sanitizar los prompts, separando las instrucciones confiables de los datos no confiables mediante guardrails (partición de prompts, codificación y separación por roles).
- Output: exigir validaciones lógicas y pruebas de seguridad del código mediante Static Application Security Testing (SAST) tras el desarrollo y antes de su integración.
E – Aplicación de modelos auxiliares enfocados en seguridad: desarrollar modelos externos e independientes —agentes especializados— que realicen validaciones automáticas de seguridad, incluyendo SAST, escaneo de secretos y verificación de controles de seguridad, para identificar vulnerabilidades antes del despliegue.
L – Agencia mínima (Least Agency): aplicar el principio de mínimos privilegios a todas las plataformas de vibe coding y a los agentes de IA. Otorgar sólo los permisos estrictamente necesarios, restringiendo el acceso a archivos sensibles y limitando los comandos destructivos.
D – Controles técnicos defensivos: implementar controles defensivos en la cadena de suministro y en la ejecución, como el análisis de composición de software (SCA) antes de consumir componentes y la desactivación de la ejecución automática, para garantizar la intervención humana y de agentes auxiliares durante el despliegue.