TL; DR
Lo que ENISE 2026 nos enseñó sobre la seguridad de los agentes de codificación de IA.
La IA ya escribe tu código. Decidir qué llega a producción sigue siendo tu responsabilidad.
- Una sola frase bastó: Una indicación oculta en el título de un problema de GitHub llevó a un agente de triaje de IA a iniciar una cadena que terminó en un Liberación no autorizada de Cline, un asistente de codificación con más de cinco millones de usuarios.
- No hubo participación de CVE: El ataque explotó cinco controles faltantes, una vulnerabilidad poco común, por lo que los escáneres tradicionales no detectaron nada.
- El cuello de botella se ha desplazado: La IA escribe código y encuentra vulnerabilidades rápidamente. Integrar el código de forma segura y validar qué hallazgos son reales es ahora la parte difícil.
- Los agentes de codificación forman parte de su cadena de suministro: Los atacantes se dirigen a todo aquello que escribe tu código: nombres de paquetes inventados, dependencias maliciosas, incluso los asistentes de IA en el portátil de un desarrollador.
El primer paso: Responda cuatro preguntas. ¿Qué agentes intervienen en su desarrollo, qué pueden aportar, qué... pipelines puede ejecutar, y qué hallazgos puede validar realmente.
En ENISE 2026 en León, nuestro CEO Jesús Cuadrado abrió su charla sobre seguridad de agentes de codificación de IA con una historia, no con una diapositiva de estadísticas. Esto es lo que contó a la sala y las cuatro preguntas que dejó. CISO con.
Una sola frase fue suficiente
A principios de este año, un investigador de seguridad demostró que se podía publicar una versión falsa de un asistente de codificación utilizado por millones de desarrolladores sin necesidad de exploits, vulnerabilidades de día cero ni contraseñas robadas. Bastaba con una frase en el título de una incidencia de GitHub.
La herramienta era Cline, un popular asistente de codificación de código abierto. Como muchos proyectos actuales, su equipo había automatizado parte de su trabajo con IA: un agente leía cada nuevo problema de GitHub, lo clasificaba y respondía. Para realizar su trabajo, ese agente tenía acceso a la terminal y se ejecutaba en problemas abiertos por cualquier persona en Internet. El investigador Adnan Khan denominó a la cadena de ataque "Clinejection", y Simon Willison ha... un resumen claro de cómo funcionaba.
La cadena se rompió en cinco puntos:
- El texto externo se convirtió en instrucciones. El título del problema aparecía directamente en el indicador del agente, por lo que una solicitud para instalar una herramienta parecía un comando.
- El agente tenía más poder del que necesitaba. Su función era priorizar los problemas, pero también podía ejecutar comandos, así que lo hizo.
- La clasificación y la liberación compartían una caché. La herramienta instalada envenenó la caché de CI, y el flujo de trabajo de lanzamiento heredó ese problema.
- Las versiones utilizaban un token de larga duración. Con la caché comprometida, el token de publicación de npm estaba al alcance.
- Nadie aprobó su publicación. No era necesario que un humano verificara una versión antes de su envío.
Semanas después, alguien lo explotó de verdad y publicó una versión no autorizada, cline@2.3.0. Permaneció en línea durante unas ocho horas y se instaló aproximadamente cuatro mil veces. Esta vez, el malware solo instaló otro agente de IA. Podría haber sido un programa para robar credenciales o un ransomware.
Fíjense en lo que no había: ni inyección SQL, ni vulnerabilidad CVE, ni nada que un escáner tradicional detectaría. Entonces, ¿quién decidió que esa versión podía publicarse?
Nadie.
Cinco controles que faltan y qué cierra cada uno.
Cada eslabón de la cadena Clinejection era un control que no existía. Ninguno de ellos requería un CVE para ser explotado.
| Eslabón de la cadena | Lo que faltaba | El control que lo cierra |
|---|---|---|
| 1. Título del número | El texto no confiable se envió directamente a la solicitud del agente. | Trate toda la información externa como no confiable y manténgala fuera de las instrucciones del agente. |
| 2. Agente de triaje | Un agente de triaje podría ejecutar cualquier comando. | Principio de mínimo privilegio: proporcionar a cada agente solo las herramientas necesarias para su tarea. |
| 3. Caché compartida | Los flujos de trabajo de clasificación y liberación utilizaban la misma clave de caché. | Aislar flujos de trabajo y revisar pipeline configuración como código |
| 4. Token de npm | Los lanzamientos dependían de un token de publicación de larga duración. | Credenciales de corta duración y alcance limitado para la publicación |
| 5. Lanzamiento | Sin aprobación ni verificación humana antes de su publicación. | Se requiere aprobación y procedencia firmada para cada lanzamiento. |
Escribir código ya no es el cuello de botella
Cline no es una excepción. Es una vista previa. Los agentes de codificación de IA ahora escriben, instalan y commit El código se genera a un ritmo para el que ningún proceso de revisión fue diseñado, e incluso los laboratorios de IA informan que integran cambios más rápido de lo que sus propias herramientas pueden gestionar.
El cuello de botella se ha desplazado. Escribir código es barato. Integrarlo de forma segura no lo es.
Encontrar vulnerabilidades es barato. Saber cuáles son reales no lo es.
La IA también es muy buena para encontrar vulnerabilidades. Lo que no puede hacer por sí sola es decirte cuáles son reales.
Los responsables del mantenimiento de curl, la biblioteca que se ejecuta en miles de millones de dispositivos, lo hicieron dolorosamente evidente. La mayoría de los informes de seguridad que recibían no eran vulnerabilidades reales, pero cada uno mantenía ocupados durante horas a los miembros de un pequeño equipo de voluntarios. En enero de 2026, curl finalizó su programa de recompensas por la detección de errores.citando la avalancha de informes de baja calidad generados por IA.
La misma capacidad, el descubrimiento impulsado por IA, puede generar cientos de hallazgos reales o una avalancha de información irrelevante. La diferencia radica en quién los valida y cuál es el costo.
Tu agente de codificación ahora forma parte de tu cadena de suministro.
Los atacantes han llegado a la conclusión lógica: si los agentes escriben el código, ¿por qué atacar el código? Hay que atacar a quien lo escribe.
- Ocupación ilegal de terrenos baldíos. Las investigaciones sobre código generado por IA han revelado que los modelos suelen recomendar paquetes inexistentes, repitiendo a menudo los mismos nombres inventados. Un atacante solo tiene que registrar uno y esperar.
- Los asistentes de IA se volvieron contra sus dueños. En el ataque s1ngularity contra la popular herramienta de compilación Nx, el malware buscaba asistentes de codificación de IA en el equipo del desarrollador y les pedía que encontraran Secretos: archivos .env, claves SSH y tokens en la nube. La propia IA de la víctima realizaba el trabajo del atacante.
La superficie de ataque ya no es solo tu código. Es todo lo que escribe código para ti. Muchos de estos riesgos ahora están mapeados en el Los 10 mejores candidatos para el Máster en Derecho de OWASP y en el Top 10 de OWASP para aplicaciones con agentes, que explicamos en nuestra guía sobre el tema. Los 10 principales problemas de IA agencial de OWASP.
Seguridad de los agentes de codificación de IA: cuatro preguntas cada CISO debería poder responder
Jesús convirtió todo esto en cuatro preguntas. Intenta responderlas para tu propia organización:
- ¿Qué agentes y modelos intervienen en nuestro desarrollo actual? No me refiero a los que aprobaste, sino a los que ya están ahí. Asistentes de IDE, bots de GitHub, agentes que alguien configuró para ahorrar tiempo.
- ¿Qué pueden aportar a nuestro software? Paquetes inventados, dependencias de cebo, extensiones de IDE, Servidores MCP, modelos descargados de cualquier lugar.
- ¿Qué puede hacer nuestro pipeline¿Se ejecutan y con qué permisos? En Cline, una caché compartida era suficiente para acceder al token de publicación.
- De todo lo que nos cuentan, ¿qué hallazgos podemos realmente validar?
La cuarta pregunta es más importante de lo que parece: no puedes fiarte del resumen que un agente haga de sus acciones. Necesitas pruebas independientes.
¿Cómo responde Xygeni a estas preguntas?
Mira lo que hay allí. Seguridad de IA de Xygeni Crea un inventario de los modelos, agentes, servidores MCP y herramientas de codificación de IA en sus repositorios, con los riesgos mapeados al OWASP Top 10 para aplicaciones LLM. No se puede controlar lo que se desconoce.
Detén lo que no debería entrar. Alerta temprana de malware Detecta paquetes maliciosos antes de que exista una firma, y está incluido en nuestro plan gratuito. xygeni Shield Bloquea los paquetes maliciosos en las estaciones de trabajo de los desarrolladores antes de que se instalen y aplica una antigüedad mínima para los paquetes, las extensiones de IDE y los complementos, cerrando así la ventana de oportunidad de la que se basan estos ataques.
Proteger el pipeline. Seguridad en CI/CD verifica los flujos de trabajo, los permisos y Secretos, y Build Security agrega firmado SLSA Las certificaciones, para que puedas demostrar que lo que publicaste es lo que creaste. Eso es precisamente lo que falló en Cline.
Valida con pruebas, no con opiniones. Aquí es donde la IA promete más y falla con mayor frecuencia. Un resultado que cambia cada vez que se ejecuta no puede servir como evidencia para un auditor ni como puerta de entrada en un pipelineEn Xygeni, la IA no decide. En las pruebas de penetración con IA, un experto en seguridad informática planifica el ataque como lo haría un pentester, pero un oráculo determinista decide si funcionó, basándose en una señal real y segura. Cada veredicto es explotable, no explotable o inconcluso, y cada uno incluye una prueba de concepto reproducible que puede mostrar a su auditor o a su junta directiva.
La IA propone. Un motor determinista decide. Tú te quedas con la evidencia.
El decisIon sigue siendo tuyo
Jesús cerró el tema donde lo empezó. Se lanzó una versión de Cline sin autorización, no por negligencia del equipo, sino porque nadie hizo las preguntas adecuadas a tiempo. En eso consiste la seguridad de los agentes de codificación de IA: en hacer esas preguntas antes de que un agente lance algo.
La IA ya escribe tu código. Decidir qué llega a producción sigue siendo tu responsabilidad.
Entonces, ¿cuál de las cuatro preguntas no puedes responder hoy?
Pasamos tres días en el stand 62 hablando con los equipos de seguridad y desarrollo sobre estas mismas cuestiones. Gracias a todos los que nos visitaron.
El equipo de Xygeni en ENISE 2026, de izquierda a derecha: Jesús Cuadrado, Marcos Martín, y Agustín Sánchez Fonseca.
¿Quieres ver cómo Xygeni responde a estas preguntas en tu entorno? Empieza gratis or RESERVAR UNA DEMOSTRACIÓN.
Preguntas Frecuentes
¿Qué es la seguridad de los agentes de codificación de IA?
La seguridad del agente de codificación de IA es la práctica de controlar lo que los asistentes y agentes de codificación de IA pueden ver, instalar, ejecutar y publicar en el ciclo de vida del desarrollo de software. Cubre los propios agentes, los componentes que traen, la pipelinecomo pueden desencadenar y la evidencia que necesitas para confiar en su resultado.
¿Qué fue el ataque Clinejection?
Clinejection fue una cadena de ataques contra el repositorio de Cline en la que una solicitud oculta en el título de una incidencia de GitHub engañó a un agente de triaje de IA para que ejecutara comandos. Mediante envenenamiento de caché, el atacante obtuvo un token de publicación de npm y lanzó una versión no autorizada de Cline que se instaló aproximadamente cuatro mil veces.
¿Qué es el slopsquatting?
El slopsquatting es un ataque a la cadena de suministro en el que un atacante registra nombres de paquetes que los modelos de IA tienden a inventar. Cuando un desarrollador o agente de codificación instala el paquete ficticio, en su lugar obtiene el código del atacante.
¿Puede la IA validar por sí sola los hallazgos de seguridad?
No es del todo fiable. La IA puede encontrar y explicar vulnerabilidades, pero su resultado puede variar entre ejecuciones, lo que la debilita como evidencia. Un enfoque más seguro consiste en dejar que la IA proponga soluciones y que un motor determinista decida, de modo que la misma entrada siempre produzca el mismo resultado verificable.
