Una investigación sobre el uso de archivos llms.txt ha descubierto un nuevo riesgo para la cadena de suministro de software: agentes de programación como Claude, OpenAI Codex y Hermes llegaron a instalar paquetes controlados por investigadores dentro de redes corporativas después de encontrarlos recomendados en documentación pública. No hubo phishing ni explotación de una vulnerabilidad tradicional. El experimento aprovechó algo mucho más cotidiano: documentación desactualizada que apuntaba hacia paquetes o dominios que ya no tenían propietario.
Las claves del nuevo riesgo de los agentes de IA en 20 segundos
- Los investigadores analizaron 6.214 dominios de grandes empresas, tecnológicas y contratistas de defensa.
- Encontraron más de un centenar de sitios con referencias hacia paquetes o dominios sin propietario.
- Registraron algunos nombres y publicaron código inofensivo que únicamente notificaba su ejecución.
- El primer aviso procedente de una Fortune 500 llegó, según los investigadores, en menos de cuatro minutos.
- Claude, Codex y Hermes aparecieron en cadenas de procesos asociadas a algunas instalaciones.
El experimento resulta inquietante precisamente porque no necesitó encontrar una vulnerabilidad desconocida en los agentes.
El problema apareció en la relación entre documentación, confianza y capacidad de ejecución.
Durante años un error en una página de documentación podía provocar que un desarrollador copiase un comando incorrecto, recibiese un error y tuviera que investigar qué estaba pasando. Con un agente de IA que dispone de acceso al terminal, esa misma información puede convertirse en una acción ejecutada automáticamente.
Ahí cambia el riesgo.
Qué es llms.txt y por qué puede terminar ejecutándose código
llms.txt es una convención relativamente reciente destinada a proporcionar a los modelos de lenguaje información estructurada y fácilmente procesable sobre una web.
Suele compararse con robots.txt, aunque la analogía tiene límites importantes.
robots.txt proporciona instrucciones a los rastreadores sobre cómo recorrer una web. llms.txt intenta facilitar a los modelos y agentes información sobre el contenido, documentación y estructura de un sitio.
El problema aparece cuando esa documentación incluye instrucciones operativas.
Por ejemplo, una documentación técnica puede indicar qué paquete instalar mediante npm o PyPI para utilizar una biblioteca.
Mientras el nombre exista y pertenezca al desarrollador legítimo, no ocurre nada extraño. Pero los proyectos cambian, los repositorios desaparecen, los dominios caducan y algunos paquetes dejan de mantenerse.
Una referencia puede sobrevivir mucho más tiempo que el software al que apuntaba.
Los investigadores analizaron miles de estos documentos pertenecientes a 6.214 dominios activos, entre ellos organizaciones Fortune 500, grandes tecnológicas y contratistas del sector de defensa. Encontraron numerosos comandos que remitían a paquetes inexistentes o dominios que podían registrarse.
Hay una pequeña discrepancia entre las cifras publicadas sobre el estudio que conviene conservar.
La información publicada por Ars Technica habla de 8.265 archivos llms.txt y llms-full.txt, con 120 sitios que contenían referencias problemáticas. El relato publicado por el propio investigador Alon Hertz habla de 8.565 archivos y más de 237 artefactos sin propietario. Las fuentes disponibles no explican completamente si corresponden a diferentes fases o criterios del análisis.
La conclusión relevante no depende de esa diferencia: había referencias ejecutables hacia recursos que nadie controlaba.
Registraron los nombres y esperaron
Los investigadores hicieron entonces algo conceptualmente muy sencillo.
Registraron algunos de esos nombres disponibles.
En lugar de publicar malware, crearon paquetes de prueba con un beacon o señal de retorno. Cuando alguien instalaba y ejecutaba el paquete, este se comunicaba con la infraestructura de los investigadores para demostrar que había llegado hasta allí.
No necesitaban entrar en ninguna red corporativa.
Esperaron a que alguien siguiera las instrucciones que las propias empresas habían publicado.
Y ese alguien resultó ser, en algunos casos, un agente de IA.
Según Alon Hertz, el primer callback procedente de una compañía Fortune 500 llegó en menos de cuatro minutos. Posteriormente llegaron más señales desde otras empresas y startups.
Los investigadores registraron además la cadena de procesos que había originado determinadas instalaciones.
Eso permitió relacionar algunas ejecuciones con agentes de programación, entre ellos Claude, OpenAI Codex y Hermes de Nous Research.
Esto tampoco significa que cualquier instalación de esos productos ejecute automáticamente cualquier cosa encontrada en un llms.txt.
El resultado depende de la configuración del agente, los permisos concedidos, el entorno donde trabaja y las herramientas a las que tiene acceso.
Y esa distinción resulta fundamental.
El peligro no es que un modelo pueda leer documentación maliciosa. Es que un agente con permisos suficientes pueda convertir esa documentación en acciones sin introducir una comprobación independiente entre ambas cosas.
Del package hijacking a la era de los agentes
El problema de apropiarse de nombres de paquetes abandonados no nació con la inteligencia artificial.
La seguridad de la cadena de suministro lleva años enfrentándose a técnicas como dependency confusion, typosquatting y secuestro de paquetes abandonados.
También existe un fenómeno parecido con los dominios.
Un dominio puede haber pertenecido durante años a una empresa, acumular enlaces y aparecer en miles de páginas. Si caduca y otra persona lo registra, hereda una parte de esa confianza residual.
David Carrero Fernández-Baillo, cofundador de Stackscale (Grupo Aire), establece precisamente un paralelismo con una práctica conocida en SEO.
Carrero explica que él mismo ha registrado en alguna ocasión dominios caducados para proyectos legítimos buscando aprovechar los enlaces y la autoridad que habían acumulado anteriormente. El dominio cambia de propietario, pero una parte de la confianza que Internet había depositado en él permanece.
Con los agentes de IA aparece una versión mucho más delicada de ese fenómeno.
Un paquete abandonado puede continuar mencionado en documentación que parece oficial. Un dominio puede seguir figurando en una guía de instalación años después de cambiar de propietario.
El nuevo dueño no hereda únicamente enlaces.
Puede heredar una posición dentro de una cadena de confianza.
Carrero lo resume como el salto desde “heredar autoridad de enlaces” hasta, potencialmente, heredar una puerta de entrada a una gran empresa cuando un agente interpreta esa referencia antigua como una instrucción válida.
La comparación ayuda a comprender por qué el problema no puede reducirse a llms.txt.
El problema real es confiar en la documentación como si fuera código firmado
Un archivo llms.txt puede corregirse. También pueden revisarse periódicamente los nombres de paquetes que aparecen en él.
Eso resolvería una parte del problema, pero no la cuestión de fondo.
Los agentes están modificando una frontera que durante décadas parecía bastante clara.
Documentación y código eran cosas diferentes.
Un README podía recomendar instalar algo, pero normalmente existía una persona entre la instrucción y el terminal.
Con los agentes esa persona puede desaparecer de determinados pasos.
El modelo consulta documentación, encuentra una instrucción, decide que necesita una dependencia y dispone de herramientas para ejecutar el comando.
La documentación pasa así de ser información a convertirse indirectamente en entrada operativa.
Como apunta Carrero, el componente cultural resulta especialmente importante. Que más de un centenar de sitios analizados mantuvieran referencias hacia recursos que ya no estaban bajo control de sus propietarios no describe una sofisticada vulnerabilidad criptográfica.
Describe problemas conocidos: documentación abandonada, dependencias que nadie revisa, copiar y pegar instrucciones antiguas y asumir que aquello que aparece bajo un dominio conocido sigue siendo correcto.
La diferencia es que ahora ese comportamiento puede automatizarse.
El copy-paste incorrecto de siempre puede ejecutarse a velocidad de máquina.
Qué deberían cambiar las empresas que utilizan agentes
La respuesta tampoco debería consistir simplemente en prohibir llms.txt.
La investigación demuestra un problema más amplio: ninguna documentación externa debería adquirir automáticamente autoridad para instalar software dentro de un entorno corporativo.
Los agentes de programación necesitan límites comparables a los que ya se aplican a otros sistemas automatizados.
Un agente no debería poder convertir una recomendación encontrada en Internet en una dependencia confiable únicamente porque procede aparentemente de la documentación del proveedor.
Antes de ejecutar deberían existir controles sobre procedencia del paquete, propietario, registro utilizado, versión, firma o hash cuando corresponda y permisos solicitados.
También debería limitarse dónde puede ejecutar código el agente.
Los entornos aislados, contenedores, máquinas virtuales desechables y políticas de permisos mínimos reducen las consecuencias si una dependencia resulta comprometida.
Y determinados cambios deberían seguir requiriendo autorización humana.
La cuestión es especialmente importante cuando los agentes trabajan con credenciales cloud, repositorios privados, sistemas de CI/CD o entornos corporativos.
Un agente con acceso a un shell no es simplemente un chatbot más inteligente.
Es software con capacidad para actuar.
La documentación entra en la superficie de ataque
La investigación deja otra consecuencia que probablemente obligará a cambiar algunos procedimientos internos de seguridad.
Las empresas auditan código, dependencias, imágenes de contenedores, repositorios y pipelines. La documentación pública rara vez recibe el mismo tratamiento.
Eso tenía cierta lógica cuando únicamente era documentación.
Con agentes capaces de convertir instrucciones escritas en operaciones, esa separación resulta menos clara.
Un llms.txt, README o tutorial que indique instalar un paquete inexistente puede terminar funcionando como un enlace dentro de la cadena de suministro.
La organización debería saber qué nombres de paquetes recomienda públicamente, comprobar que siguen bajo control legítimo y eliminar referencias antiguas cuando desaparecen proyectos.
También debería revisar dominios, repositorios y servicios externos enlazados desde documentación destinada específicamente a agentes.
El experimento de Hertz resulta especialmente ilustrativo porque los investigadores no necesitaron engañar a las empresas para que confiaran en ellos.
La confianza ya estaba allí.
Estaba almacenada en documentación antigua.
Los investigadores simplemente ocuparon el espacio que había quedado vacío y esperaron.
La llegada de los agentes hace que ese viejo problema tenga consecuencias diferentes. Internet está lleno de documentación desactualizada, dominios abandonados, repositorios eliminados y paquetes que dejaron de existir hace años.
Hasta ahora gran parte de esos residuos digitales terminaban provocando enlaces rotos.
Cuando un agente dispone de permisos para ejecutar comandos, algunos pueden convertirse en algo bastante más peligroso.
Preguntas frecuentes
¿Qué es el archivo llms.txt?
llms.txt es una convención emergente que permite publicar información de una web en un formato pensado para que resulte sencillo de consumir por modelos y agentes de IA. No debe confundirse con un mecanismo de seguridad ni implica que todo lo incluido en el archivo sea automáticamente confiable.
¿Claude, Codex y Hermes instalaron realmente los paquetes?
Los investigadores registraron cadenas de procesos que relacionaban determinadas instalaciones de sus paquetes de prueba con Claude, OpenAI Codex y Nous Research Hermes. Esto no implica que cualquier configuración de estos agentes ejecute automáticamente instrucciones de llms.txt.
¿Los investigadores instalaron malware en empresas Fortune 500?
No. Según el informe publicado, utilizaron paquetes de prueba diseñados para enviar una señal que demostrase su ejecución. No estaban destinados a robar información ni mantener persistencia en los sistemas.
¿Cómo pueden protegerse las empresas?
La principal medida es evitar que documentación externa pueda desencadenar instalaciones sin controles adicionales. Las organizaciones también deberían revisar sus propios llms.txt, verificar los paquetes y dominios que recomiendan, limitar los permisos de los agentes y ejecutar código no verificado dentro de entornos aislados.
Fuente: ArsTehcnica
