--- title: "El código huérfano se convierte en un nuevo riesgo para los agentes de IA" description: "Los agentes de inteligencia artificial están introduciendo un cambio importante en la seguridad de la cadena de suministro de software: la documentación ha dejado de ser necesariamente información pas..." url: https://revistacloud.com/codigo-huerfano-se-convierte-en-un-nuevo-riesgo-para-los-agentes-de-ia/ date: 2026-09-03 modified: 2026-09-03 author: "Antonio" image: https://revistacloud.com/wp-content/uploads/2026/09/orphaned-code-automated-trust-real-risk-ai-agentes.jpg categories: ["Inteligencia artificial", "Noticias", "Seguridad"] tags: ["código", "dominios", "Inteligencia Artificial", "riesgo"] type: post lang: es --- # El código huérfano se convierte en un nuevo riesgo para los agentes de IA Los agentes de inteligencia artificial están introduciendo un cambio importante en la seguridad de la cadena de suministro de software: **la documentación ha dejado de ser necesariamente información pasiva**. Una investigación sobre miles de archivos `llms.txt` encontró referencias a paquetes y dominios que ya no tenían propietario. Tras registrar algunos de ellos, los investigadores comprobaron que agentes asociados a Claude, OpenAI Codex y Hermes terminaron instalando sus paquetes de prueba dentro de entornos corporativos, incluidas compañías Fortune 500. **Las claves del riesgo del código huérfano para los agentes de IA en 30 segundos** - El análisis abarcó **6.214 dominios** de Fortune 500, grandes tecnológicas y contratistas de defensa. - En 120 sitios se localizaron referencias hacia uno o más paquetes o dominios que estaban disponibles para ser registrados. - Los investigadores reclamaron algunos nombres y publicaron código de prueba diseñado únicamente para confirmar su ejecución. - Llegaron señales desde varias empresas y algunas instalaciones pudieron relacionarse con **Claude, Codex y Hermes**. - El problema amplía la seguridad de la cadena de suministro: un agente puede transformar documentación obsoleta en una acción real. No fue necesario comprometer la web de una empresa, enviar correos de phishing o explotar una vulnerabilidad *zero-day*. Tampoco se introdujo código en un repositorio legítimo. Los investigadores aprovecharon algo mucho más sencillo: **referencias antiguas que seguían siendo consideradas válidas cuando el recurso original había desaparecido**. El caso resulta especialmente relevante ahora que los agentes de programación empiezan a recibir permisos para utilizar terminales, instalar dependencias, modificar repositorios, ejecutar pruebas y operar con herramientas de desarrollo. Un enlace roto ya no siempre termina en un error 404. En determinados flujos automatizados puede convertirse en una oportunidad para introducir código. ## De llms.txt al terminal: dónde cambia el modelo de seguridad `llms.txt` es una convención emergente destinada a ofrecer a los modelos de lenguaje una representación sencilla y estructurada del contenido de una web. La comparación habitual es `robots.txt`, aunque técnicamente cumplen funciones diferentes. Mientras `robots.txt` establece indicaciones para los rastreadores, `llms.txt` pretende ayudar a modelos y agentes a encontrar y comprender documentación relevante. El formato por sí mismo no instala nada. El riesgo aparece cuando la información que contiene o referencia termina siendo utilizada por **un agente que sí dispone de herramientas para actuar**. Una documentación técnica puede indicar, por ejemplo, que para utilizar determinada biblioteca es necesario instalar un paquete. El agente consulta las instrucciones, determina que necesita esa dependencia y ejecuta el gestor de paquetes correspondiente. Ese flujo funciona mientras todos los componentes de la cadena sigan bajo control legítimo. Pero Internet acumula años de residuos técnicos: proyectos discontinuados, repositorios eliminados, paquetes retirados, dominios caducados y documentación que nadie actualizó después. Los investigadores analizaron **6.214 dominios activos** pertenecientes a organizaciones de gran tamaño. Según los datos publicados, localizaron 8.265 archivos `llms.txt` y `llms-full.txt` y encontraron 120 sitios que apuntaban hacia uno o más recursos sin propietario. La situación recuerda a problemas conocidos de la cadena de suministro, pero introduce una diferencia importante. Antes normalmente había una persona entre la documentación y la ejecución. Ahora puede haber un agente. ## Un paquete desaparece, pero su confianza permanece Para comprobar las consecuencias los investigadores registraron algunos de los nombres que habían quedado disponibles. No publicaron malware destinado a comprometer las empresas. Utilizaron paquetes de prueba preparados para enviar una señal a su infraestructura cuando fueran ejecutados. Después esperaron. El mecanismo resulta especialmente interesante desde la perspectiva de seguridad porque los investigadores no tenían que buscar activamente sistemas vulnerables. **Las referencias ya estaban publicadas por las propias organizaciones o en documentación considerada legítima.** Cuando los agentes procesaron esa información y ejecutaron las instalaciones comenzaron a llegar las señales. El análisis de las cadenas de procesos permitió relacionar algunas ejecuciones con agentes de programación, entre ellos Claude, OpenAI Codex y Hermes de Nous Research. Esto requiere una precisión importante. El experimento no demuestra que esos agentes instalen siempre y de manera autónoma cualquier paquete mencionado en `llms.txt`. La ejecución depende de cómo esté configurado cada agente, las instrucciones recibidas, las herramientas disponibles y los permisos concedidos por el usuario o la organización. La cuestión de seguridad está precisamente ahí. **Cuanta más autonomía recibe un agente, mayor importancia adquiere comprobar de dónde procede cada instrucción que convierte en una acción.** ## El viejo problema de los dominios caducados llega a los agentes [David Carrero Fernández-Baillo](https://carrero.es/), cofundador de [Stackscale](https://www.stackscale.com) (Grupo Aire), encuentra un paralelismo interesante con un fenómeno conocido desde hace años en Internet: la confianza residual de los dominios caducados. Carrero explica que ha registrado dominios expirados en alguna ocasión para proyectos legítimos relacionados con SEO. Un dominio con años de historia puede conservar enlaces desde otras páginas y parte de la autoridad adquirida mientras pertenecía a su anterior propietario. El nuevo propietario hereda, en cierta medida, una reputación que no construyó. La investigación sobre los agentes muestra una versión bastante más delicada del mismo principio. Si una empresa recomendó durante años un dominio, paquete o repositorio y posteriormente ese recurso desaparece, **la referencia puede seguir conservando la confianza del propietario anterior aunque el control haya cambiado**. Con una web tradicional las consecuencias pueden limitarse a enviar visitantes hacia un dominio que ya pertenece a otra persona. Con documentación técnica procesada por agentes el nuevo propietario podría heredar algo diferente: una posición dentro de una cadena que eventualmente termina en la ejecución de software. Como apunta Carrero, el salto conceptual es considerable: se pasa de heredar la autoridad SEO de los enlaces a poder **heredar una puerta de entrada que la documentación dejó abierta**. ## No es una vulnerabilidad de llms.txt Centrar toda la discusión en `llms.txt` podría conducir a una conclusión equivocada. Eliminar esos archivos no resolvería el problema. Un agente puede obtener instrucciones desde un README, documentación oficial, un repositorio, una página de soporte, un tutorial o cualquier otra fuente que considere suficientemente fiable. El problema reside en **confundir autoridad documental con autoridad para ejecutar**. Los equipos de seguridad llevan años protegiendo los repositorios de código y los pipelines de integración y despliegue continuo (CI/CD). Se analizan dependencias, imágenes de contenedores, credenciales y artefactos. La documentación normalmente recibe otro tratamiento porque históricamente su capacidad para modificar sistemas era indirecta. Los agentes están cambiando esa separación. Si un documento puede provocar que un agente ejecute un comando, instale una dependencia o modifique una configuración, ese documento empieza a formar parte de la superficie de ataque. Eso obliga a replantearse también la seguridad del contenido publicado por las propias compañías. Una empresa debería poder responder a preguntas que hasta hace poco parecían secundarias: ¿todos los paquetes recomendados en su documentación siguen existiendo?, ¿los dominios enlazados continúan bajo el mismo propietario?, ¿los repositorios mencionados siguen siendo legítimos?, ¿qué ocurre con la documentación de productos discontinuados? El mantenimiento documental empieza a adquirir características propias de la gestión de dependencias. ## La cadena de suministro necesita una capa específica para agentes La respuesta técnica tampoco debería consistir simplemente en añadir otra advertencia al modelo. Las organizaciones que permiten a agentes ejecutar código necesitan controles fuera del propio modelo. El principio más sencillo consiste en **no permitir que una fuente documental sea suficiente para establecer la confianza de una dependencia**. La procedencia del paquete debería comprobarse independientemente. En función del entorno pueden verificarse registro, propietario, versión, antigüedad, firma, hash, repositorio de origen y otros datos disponibles. Los agentes tampoco deberían disponer automáticamente de los mismos privilegios que un desarrollador. Un entorno aislado o desechable permite que el agente pruebe una dependencia sin introducir inmediatamente el código dentro de sistemas con acceso a información corporativa. La separación resulta especialmente importante cuando el agente dispone de credenciales para servicios cloud, repositorios privados, gestores de secretos, pipelines de CI/CD o infraestructura de producción. La aprobación humana sigue teniendo sentido para determinadas operaciones. Pero tampoco conviene utilizarla como única defensa. Una persona que recibe decenas de solicitudes de confirmación terminará aprobándolas mecánicamente, especialmente si la interfaz únicamente pregunta algo parecido a “¿permitir instalación?”. El control debería aportar contexto: qué paquete se instalará, quién lo mantiene, de dónde procede la recomendación y por qué el agente considera necesario utilizarlo. ## El problema cultural detrás del fallo técnico Carrero señala además un aspecto menos visible de la investigación: **120 sitios de los 6.214 analizados mantenían referencias hacia recursos que ya no estaban correctamente controlados**. Eso no responde a una vulnerabilidad sofisticada. Es el resultado de prácticas conocidas desde hace décadas: documentación que envejece, proyectos abandonados, dominios que nadie renueva y referencias copiadas durante años sin comprobar su estado. El *copy-paste* siempre ha formado parte de los riesgos del desarrollo de software. La diferencia es la escala. Un desarrollador puede copiar un comando, ejecutarlo, encontrarse un error y detenerse. Un agente puede consultar decenas de páginas, resolver dependencias y ejecutar instrucciones en segundos. Automatizar una tarea también automatiza sus malas prácticas. Por eso el problema tiene una dimensión cultural además de técnica. La llegada de los agentes exige abandonar una suposición muy arraigada: que aquello publicado bajo el dominio de un proveedor puede considerarse automáticamente cierto y actual. La documentación es una fuente de información. **No debería funcionar como una firma digital.** ## De los enlaces rotos a una nueva superficie de ataque La investigación también ofrece una pista sobre cómo podría evolucionar la seguridad ofensiva. Internet contiene millones de referencias abandonadas. Muchas pertenecen a proyectos sin ninguna importancia, pero otras permanecen dentro de documentación empresarial, scripts antiguos, repositorios, tutoriales y configuraciones. Hasta ahora encontrar uno de estos recursos solía tener poco valor. Los agentes pueden cambiar esa ecuación. Un atacante podría buscar sistemáticamente referencias hacia paquetes, dominios o repositorios abandonados que aparezcan dentro de documentación utilizada por herramientas automatizadas. El objetivo ya no sería convencer a una persona para que instalase algo. Sería encontrar una **cadena de confianza abandonada que todavía siga siendo consumida por máquinas**. El experimento con `llms.txt` muestra que esa posibilidad ya no pertenece únicamente al terreno teórico. Las empresas están desplegando agentes capaces de programar, utilizar terminales y administrar servicios con una velocidad considerable. Ahora necesitan asegurarse de que la confianza que esos sistemas depositan en Internet no avance a la misma velocidad. Porque el código huérfano lleva años existiendo. Lo que ha cambiado es que ahora hay agentes dispuestos a encontrarlo, interpretarlo y, bajo determinadas condiciones, ejecutarlo. ## Preguntas frecuentes ### ¿Es llms.txt una vulnerabilidad de seguridad? No por sí mismo. `llms.txt` es una convención para facilitar información a modelos y agentes. El riesgo aparece cuando un agente convierte las instrucciones encontradas en acciones sin verificar independientemente los recursos implicados. ### ¿Qué es un paquete huérfano? En este contexto es un nombre de paquete, dominio u otro recurso mencionado por documentación existente pero que ya no está controlado por su propietario original. Si otra persona puede reclamarlo, las referencias antiguas pueden terminar apuntando hacia el nuevo propietario. ### ¿Claude, Codex y Hermes ejecutaron código de los investigadores? Los investigadores relacionaron determinadas instalaciones con cadenas de procesos asociadas a Claude, OpenAI Codex y Hermes. El experimento no implica que todos estos agentes actúen siempre así: depende de su configuración, permisos y entorno. ### ¿Cómo debería protegerse una empresa que utiliza agentes de IA? Debería aplicar privilegios mínimos, aislar las ejecuciones, verificar las dependencias mediante mecanismos independientes y revisar periódicamente los paquetes, dominios y repositorios recomendados por su documentación. Las acciones sensibles no deberían depender únicamente de que un agente considere fiable una página web. Fuente: [Open Security](https://www.opensecurity.es/agentes-de-ia-instalaron-codigo-huerfano-dentro-de-empresas-fortune-500/)