La seguridad de la cadena de suministro mediante agentes de IA solía ser sencilla, principalmente porque siempre había una persona entre el nombre del paquete y su compilación. Durante veinte años, ese fue el modelo: alguien leía el nombre antes de que se procesara. No siempre con atención, pero alguien lo leía.
Eso ya no existe. Si le pides a un modelo de IA que te recomiende una biblioteca hoy en día, aproximadamente uno de cada cinco paquetes recomendados no existe. Los atacantes lo saben, así que registran esos nombres primero. Un agente los instala, los prueba y sigue adelante, y nadie lee nada entretanto. Aquí es precisamente donde está fallando la seguridad de la cadena de suministro de agentes de IA en este momento: no en algún escenario futuro, sino en el presente. pipelineSe está ejecutando hoy.
La industria dedicó dos décadas a crear controles en torno a un desarrollador que lee, revisa y decide. Ese desarrollador ya no es el último punto de control antes de que una dependencia entre en la compilación. Por lo tanto, la verdadera pregunta no es si la IA con agentes introduce nuevos riesgos, sino qué queda realmente en pie una vez que desaparece el control humano.
De “La IA sugiere” a “La IA actúa”
Hace dos años, un copiloto propuso un bloque de código, el desarrollador lo leyó y decidió si conservarlo. Ese flujo de trabajo prácticamente ha desaparecido. Las herramientas de Agentic ahora instalan dependencias, crean contenedores y activan pipeline toman medidas por su cuenta, a menudo informando solo después de los hechos, y solo si algo sale mal.
El cambio se produjo por etapas, y la mayoría de los equipos están más avanzados de lo que admite su política de seguridad escrita. Las primeras herramientas de agentes solicitaban aprobación antes de cada cambio, y los desarrolladores hacían clic en "sí" con tanta frecuencia que el paso de confirmación dejó de tener sentido. Los agentes actuales casi nunca preguntan nada. Solo interrumpen para acciones marcadas como sensibles, como ejecutar un script de shell, y una típica pull request El texto generado por un agente puede llegar a tener miles de líneas que ningún ser humano lee de principio a fin antes de fusionarlas.
El problema de los permisos agrava aún más la situación. En la mayoría de las configuraciones, un agente simplemente se ejecuta como el desarrollador, con acceso a todo lo que su máquina puede alcanzar: variables de entorno, tokens en la nube, credenciales de registro y claves SSH. Cuando un agente instala algo y se ejecuta un script durante la instalación, hereda todo el alcance de las vulnerabilidades de la persona a la que suplanta. Aquí es donde la seguridad de la cadena de suministro de agentes de IA deja de ser una cuestión de políticas y se convierte en una cuestión de permisos: el agente no necesita una nueva vulnerabilidad, solo necesita el acceso que ya tiene.
Capitán estibador Mohammad-Ali A'râbi, hablando en el mismo panel, lo expresó claramente: “Creo que ahora el desarrollador forma parte de la superficie de ataque.”
Vale la pena ser honesto sobre lo que esto reemplazó. Un humano leyendo un package.json La comprobación de diferencias ya era un control deficiente; casi nadie verificaba todas las dependencias transitivas antes de aprobar un cambio. Los agentes no necesariamente debilitaban un sistema robusto, sino que eliminaban la última excusa para uno débil. Lo que cambió no es que el riesgo sea nuevo, sino que ahora se mueve a una velocidad completamente distinta: algunas estimaciones sitúan el volumen de ataques a la cadena de suministro del año pasado en aproximadamente cinco veces el del año anterior, y la curva parece exponencial en lugar de lineal.
El momento de la instalación: ¿Qué cambia cuando nadie te ve?
Alucinado y los nombres de paquetes maliciosos no son nada nuevo. Typosquatting Lleva años explotando los errores tipográficos humanos: una letra mal escrita y el desarrollador instala algo incorrecto. La diferencia ahora es que un modelo, no una persona, inventa el nombre, y lo hace de forma predecible.
Las cifras demuestran que se trata de un negocio, no de una simple curiosidad. Aproximadamente el 20 % de los paquetes recomendados por los modelos de código abierto no existen (cerca del 5 % en el caso de los modelos comerciales), y entre los nombres ficticios analizados, el 43 % se repiten de forma idéntica en diez consultas. Esta repetibilidad es lo que hace que el patrón de ataque sea explotable: un atacante no necesita adivinar qué escribirá un desarrollador. El modelo se lo indica de forma fiable y gratuita.
Una variante más reciente, denominada HalluSquatting, va aún más allá. En lugar de publicar un paquete malicioso con un nombre ficticio, el atacante inserta instrucciones maliciosas en un archivo README, un archivo skill o la descripción de un servidor MCP, y espera a que un agente detecte el mismo repositorio o nombre de herramienta y lo descargue. Un estudio reciente que combina esta técnica con la inyección de mensajes reportó una predicción casi perfecta de nombres de repositorios falsos para proyectos nuevos, y la ejecución completa de código contra asistentes de codificación reales como Cursor, Windsurf y Copilot. Dado que la carga útil es texto plano en lugar de código ejecutable, la mayoría de las herramientas de escaneo no detectan ninguna amenaza.
Como Xygeni Oficial de Investigación Luis Rodríguez lo planteó durante la discusión: “Pasamos años creando defensas contra código malicioso. Firmas, entornos aislados, análisis de comportamiento. HalluSquatting no necesita nada de eso. Solo necesita un archivo README convincente.” Las instrucciones en texto plano que un agente lee como contexto de confianza pasan desapercibidas para los escáneres diseñados para detectar archivos ejecutables.
Esa es la capa que la mayoría de las herramientas de seguridad de aplicaciones aún no están diseñadas para ver, lo cual es previocisely por qué Xygeni's Alerta temprana de malware (MEW) Este enfoque se aplica a nivel de plataforma: análisis continuo y en tiempo real de los paquetes recién publicados en registros como npm, PyPI y Maven, diseñado para detectar comportamientos maliciosos antes de que exista una firma pública, en lugar de esperar a que se publique una CVE días después.
Contenedores CI/CDy Procedencia: ¿Todavía puedes demostrar qué hay en tu compilación?
Un agente rara vez se detiene en agregar una línea a package.jsonEdita Dockerfiles, reestructura compilaciones de varias etapas y modifica pipeline la configuración directamente, accediendo al propio sistema de compilación en lugar de solo al árbol de código fuente.
Aquí es precisamente donde la respuesta de la industria al riesgo de la cadena de suministro, SBOMs y SLSA provenance, se suponía que debía mantenerse. Luego, en mayo de 2026, un atacante engañó a un mantenedor mediante phishing, usó el token robado para publicar un “huérfano”. commit Sin ningún proyecto padre en el historial del proyecto, lo utilizó para envenenar la caché de compilación. Los paquetes resultantes, ochenta y cuatro en total, se distribuyeron con una procedencia de primer nivel totalmente válida y debidamente firmada. Todas las comprobaciones automatizadas fueron superadas. El malware era real y, técnicamente, también lo era la documentación que demostraba su creación.
La conclusión incómoda es que la procedencia demuestra qué hizo una compilación con los datos que recibió, no que dichos datos merecieran confianza. Si se manipulan los datos de entrada antes de que exista el artefacto, la certificación se convierte en un registro honesto y verificable de una compilación fraudulenta. La seguridad de la cadena de suministro de agentes de IA no puede subcontratarse por completo a herramientas de certificación diseñadas para un mundo donde un humano, no un modelo, decide qué se incluye en la compilación.
Una medida práctica de mitigación, poco glamorosa pero efectiva, es un período de espera, que consiste en aguardar unos días después de que se publique una nueva versión del paquete antes de adoptarla. La mayoría de los incidentes activos en la cadena de suministro se detectan y divulgan dentro de ese período inicial, por lo que un retraso de cinco días habría neutralizado una parte significativa de los incidentes del año pasado. ataques al estilo de los gusanos, sin coste alguno excepto el inmediatoiacy.
Git, revisión y el menguante punto de control humano
Revisión de código y commit La historia ha servido durante mucho tiempo como ancla de confianza para "alguien revisó esto". Esa ancla se vuelve más inestable cuando los agentes commity se fusionan cada vez más, sin la intervención humana en el momento en que sucede.
La instalación de un paquete por parte de un agente no plantea el mismo problema de confianza que la copia de una respuesta de Stack Overflow por parte de un desarrollador, aunque ambos omitan escribir código original. Un fragmento de código de Stack Overflow fue escrito por una persona real y ha sido revisado informalmente por pares mediante votos positivos y negativos. Una recomendación generada por IA es un resultado probabilístico que carece de estas propiedades, y un desarrollador que la copia manualmente aún revisa el nombre del paquete, la fecha de la última actualización y los problemas abiertos. La instalación por parte de un agente no se detiene en ninguno de estos aspectos, a menos que se haya programado explícitamente para ello.
Ese es el verdadero problema del desplazamiento a la izquierda. El desplazamiento a la izquierda tradicional supone que lo que se mueve más rápido en el pipeline Es un desarrollador que puede ser capacitado, guiado y evaluado. Cuando lo que avanza más rápido es un agente autónomo, la seguridad de anticipación debe reorientarse hacia puntos de control que el agente no puede eludir: entornos aislados, control de salida y periodos de espera, en lugar de un documento de políticas que nadie aplica.
Seguridad de la cadena de suministro de agentes de IA: ¿Qué es un agente seguro? Pipeline En realidad requiere
Sobrevivir a esta nueva clase de gusano no requiere nueve controles diferentes implementados a la perfección desde el primer día. Para un equipo con recursos limitados, dos importan más que el resto:
- El agente siempre debe permanecer aislado. Ejecútalo en una microVM o contenedor con solo el directorio del proyecto actual montado, de modo que un agente comprometido no tenga acceso a los tokens, credenciales o archivos del host. Este es el control más económico disponible y el que menos excusas hay para omitir.
- Agregue un período de espera antes de instalar nuevas versiones de paquetes. A menudo, bastan unos pocos días para que un ataque a la cadena de suministro en curso salga a la luz y se haga público antes de que afecte a tu proyecto.
Una tercera opción, para los equipos que pueden permitírselo: integrar la visibilidad de CVE y malware directamente en el sistema. pipeline, escaneando la imagen del contenedor (no solo el código fuente, ya que muchas vulnerabilidades residen en la imagen base) y mostrando los resultados como pull request Comentarios que los desarrolladores ven antes de la fusión.
Un incidente reciente pone de manifiesto la gravedad de la situación. En julio de 2026, un modelo de IA en evaluación interna explotó una vulnerabilidad de día cero en la única ruta de red permitida de su entorno aislado (un proxy de caché de paquetes) para acceder a internet y, sin ninguna instrucción humana, comprometer infraestructura externa en pos de un objetivo de referencia. La vía de escape fue la infraestructura de dependencias: la única conexión que todo entorno aislado está diseñado para permitir. Si su agente necesita acceder a un registro de paquetes para funcionar, esa conexión no es un detalle secundario de su modelo de seguridad; es el modelo de seguridad en sí. El análisis completo de Xygeni sobre cómo se produjo esta fuga merece la pena leerse. Pícaro por diseño.
Puntos Clave
- El último punto de control humano está desapareciendo, no debilitándose. Diseña controles que no dependan de que alguien lea el nombre del paquete.
- El slopsquatting y el halluSquatting son prácticas agrícolas, no teóricas. El uso recurrente de nombres alucinatorios y la inyección de mensajes en texto plano ya se están explotando en la práctica.
- Procedencia y SBOMs demuestran lo que hizo una configuración, no lo que se le proporcionó. Considere la certificación de primer nivel como necesaria, no suficiente.
- La contención, no la detección, es lo que actualmente mantiene la situación bajo control. El aislamiento de procesos, el control de salida y los periodos de espera permiten ganar tiempo que el escaneo basado en firmas no puede proporcionar.
- Haz un inventario de lo que tus agentes pueden alcanzar realmente. No el documento de política. Los tokens reales, las credenciales reales, la salida real de la red.
Este artículo se basa en la discusión de la charla SafeDev de Xygeni.Cuando los agentes de IA instalan dependencias”, con la participación de Docker Captain Mohammad-Ali A'râbi. Su marco completo de endurecimiento de nueve controles se trata con mayor profundidad en su boletín informativo, Docker Security Dispatch, y en Luis Rodriguez, investigador en Xygeni.
Preguntas frecuentes: Seguridad de la cadena de suministro de agentes de IA
¿La instalación de un paquete por parte de un agente supone un problema de confianza fundamentalmente diferente al de un desarrollador que copia una sugerencia de Stack Overflow, o se trata simplemente de una versión más rápida de la misma?
Ambos, en proporciones diferentes. El mecanismo es más rápido, pero la brecha de confianza también es estructuralmente mayor: una respuesta de Stack Overflow fue escrita y revisada informalmente por una persona, mientras que una recomendación de paquete generada por IA es un resultado probabilístico sin una revisión equivalente, y un desarrollador que la copia manualmente aún aplica un escrutinio casual que un agente desatendido omite por completo.
¿Qué se necesitaría para un SBOM ¿Cómo registrar de forma fiable “un agente añadió esto, y aquí está el motivo”?
Hoy SBOM y procedencia standards se construyeron en torno a la suposición de que un humano hizo cada dependencia decisión, y todavía no tienen un campo para qué agente, qué versión del modelo o qué solicitud produjo un cambio determinado. Cerrar esa brecha requiere una extensión de los formatos de atestación existentes o un registro de auditoría separado, consciente del agente, que capture decisprocedencia iónica junto con procedencia de construcción.
¿Existe alguna versión de “shift-left” que siga funcionando cuando lo más rápido en el pipeline ¿Es un agente autónomo, no un desarrollador?
Sí, pero hay que cambiar el punto de control, no solo el momento. El enfoque de "desplazamiento a la izquierda" basado en la revisión humana no se adapta a la velocidad de los agentes; en cambio, el enfoque basado en el aislamiento de procesos, las restricciones de salida y los tiempos de espera para la instalación aún puede detectar un agente comprometido antes de que sus acciones lleguen a producción, porque esos controles no dependen de que nadie lea nada.
