Seguridad en entornos corporativos acaba de sumar un capítulo preocupante — y tiene todo que ver con agentes de inteligencia artificial que probablemente ya usas en el trabajo. La noticia salió a la luz tras una investigación detallada y muestra cómo algo aparentemente inofensivo puede convertirse en una puerta de entrada silenciosa dentro de las redes de grandes compañías.
Investigadores de una startup israelí que opera en modo sigiloso descubrieron que agentes como Claude, Codex (de OpenAI) y Hermes (de Nous Research) instalaron código sin dueño dentro de redes de grandes empresas, incluyendo algunas de la lista Fortune 500. Y lo más impactante: varias de esas compañías llegaron a ejecutar código de prueba de concepto creado justamente para demostrar el riesgo.
Lo más sorprendente no fue lo que estos agentes hicieron — fue de dónde vino el disparador.
La brecha no estaba en un sistema oscuro ni en alguna vulnerabilidad exótica de infraestructura. Estaba escondida en archivos de documentación que casi nadie monitorea de cerca: los archivos llms.txt y llms-full.txt, un estándar emergente que los sitios web usan para comunicarse con agentes de IA — algo parecido al famoso robots.txt, pero orientado a máquinas inteligentes. Cuando estos archivos apuntaban a paquetes o dominios sin dueño registrado, los agentes simplemente seguían las instrucciones. Sin cuestionar. Sin alertar a nadie. Y fue exactamente eso lo que abrió la puerta. 🚨
Qué son los archivos llms.txt y por qué importan tanto
Si alguna vez trabajaste con SEO o desarrollo web, conoces bien el robots.txt — ese archivo simple que le dice a los motores de búsqueda qué pueden o no indexar. El llms.txt sigue una lógica parecida, pero con un propósito diferente y bastante más reciente: sirve como una guía estructurada y legible por máquinas para que los agentes de inteligencia artificial entiendan el contenido de un sitio y su estructura de alto nivel de forma más eficiente. La idea es buena, funcional y tiene sentido dentro del ecosistema moderno de IA — pero, como cualquier estándar nuevo, todavía arrastra fragilidades que necesitan tomarse en serio antes de convertirse en regla en todos los entornos.
Vale recordar que existen ejemplos de configuración correcta de estos archivos por ahí. Cloudflare, por ejemplo, mantiene sus archivos llms.txt y llms-full.txt bien estructurados como referencia. Herramientas como Google Lighthouse, orientadas a ayudar a desarrolladores web, también ya incorporaron auditorías específicas para este tipo de archivo, lo que muestra cuánto está ganando tracción el estándar. Muchos sitios, incluso, alojan las dos versiones al mismo tiempo, ofreciendo tanto un resumen corto como una versión completa de la documentación.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
El problema identificado por los investigadores israelíes es que estos archivos pueden contener referencias a paquetes externos, repositorios y dominios que, en algún momento, dejaron de tener un dueño activo. Cuando un agente de IA como Claude, Codex o Hermes lee esas instrucciones y decide seguirlas — que es exactamente el comportamiento para el cual fueron entrenados —, puede terminar buscando recursos que fueron registrados por personas malintencionadas. Y ahí el escenario cambia completamente. El agente no fue hackeado. Solo hizo lo que estaba programado para hacer, siguiendo instrucciones que parecían legítimas.
Este tipo de ataque tiene un nombre en el mundo de la seguridad: envenenamiento de dependencias, o dependency confusion. No es un concepto nuevo para quienes trabajan en seguridad de software, pero la novedad aquí es que fue adaptado para explotar la confianza automática que los agentes de IA depositan en fuentes de instrucción — y eso cambia la escala del problema de forma significativa. Antes, un desarrollador humano podría, en teoría, notar algo raro antes de instalar un paquete sospechoso. Un agente de IA, en cambio, actúa con velocidad y volumen mucho mayores, sin la misma capacidad de intuición o escepticismo que un ser humano tendría frente a algo fuera de lo normal.
Cómo los investigadores encontraron el problema
La metodología usada en la investigación es tan interesante como el resultado. Los investigadores realizaron un escaneo en 6.214 dominios activos pertenecientes a contratistas de defensa, empresas de la Fortune 500 y gigantes tecnológicos. En ese universo, encontraron 8.265 archivos llms.txt y llms-full.txt — un número mayor que el de sitios, justamente porque muchos alojaban las dos versiones.
De esos miles de archivos, 120 de ellos, cada uno en un sitio diferente, apuntaban a uno o más paquetes de código o nombres de dominio que no estaban registrados. Para probar qué sucede cuando un agente de IA procesa estos archivos, los investigadores registraron algunos de esos nombres abandonados y alojaron paquetes que hacían que cualquier máquina que los ejecutara contactara su servidor.
El resultado llegó rápido. En menos de una hora, los investigadores recibieron la primera respuesta de retorno proveniente de una empresa de la Fortune 500. Con el paso del tiempo, llegaron algunas decenas más de respuestas — algunas de otras compañías de la Fortune 500 y otras de startups. La señal enviada por esos paquetes también registraba la cadena de procesos que originaba cada instalación, revelando de forma clara que agentes de codificación como Claude, Codex y Hermes estaban involucrados. Hasta el cierre del reportaje original, Anthropic, OpenAI y Nous Research no respondieron a las solicitudes de comentario.
Cómo el código sin dueño entró en las redes corporativas
La sofisticación del ataque está justamente en la simplicidad del vector. Nadie necesitó invadir un servidor, explotar una falla de día cero ni diseñar un ataque de phishing elaborado. Bastó registrar dominios y paquetes que estaban referenciados en archivos llms.txt de sitios legítimos — recursos que, en algún momento, estuvieron activos y después fueron abandonados. Con esos activos bajo control, los investigadores simplemente esperaron a que un agente de IA bienintencionado, ejecutando tareas rutinarias dentro de una red corporativa, hiciera el resto del trabajo.
Dentro de las empresas afectadas — algunas con facturación multimillonaria y presencia global —, estos agentes de IA estaban siendo usados exactamente como las herramientas prometen: para automatizar tareas, consultar documentación, generar código e integrar sistemas. Codex, por ejemplo, es ampliamente usado por equipos de desarrollo para acelerar la escritura de código. Claude ha sido adoptado en flujos de trabajo que van desde análisis de documentos hasta soporte interno. Hermes, por su parte, aparece en pipelines más técnicos de procesamiento de lenguaje. Todos ellos, dentro del contexto investigado, fueron vectores involuntarios de un comportamiento que ningún equipo de seguridad estaba monitoreando porque nadie sabía que necesitaba monitorear eso.
Vale destacar que, en el caso probado por los investigadores, los paquetes solo enviaban una señal de vuelta para probar el concepto. Pero nada impediría que un atacante real sustituyera ese comportamiento inofensivo por código malicioso con capacidad de ejecutar comandos arbitrarios, recopilar información del entorno o escalar privilegios dentro de la red. Los investigadores incluso alertaron que al menos un sitio mal configurado estaba redirigiendo visitantes — humanos o IA — hacia malware activo. El nivel de daño en un escenario real variaría según los permisos que cada agente tuviera en el momento de la ejecución.
Y este es un punto crítico que muchos equipos de TI aún no han incorporado en sus políticas de seguridad: los agentes de IA necesitan ser tratados como entidades con permisos, igual que cualquier usuario humano o sistema automatizado. Darle a un agente acceso irrestricto a la red porque fue contratado para ser útil es el mismo error conceptual que darle a un becario la contraseña de root en su primer día.
El modelo de confianza está roto
Uno de los investigadores detrás del descubrimiento, Alon Hertz, resumió el problema de forma directa en una entrevista. Según él, el modelo de confianza está roto. Los agentes tratan la documentación de los proveedores como verdad absoluta y no la cuestionan — y los humanos que los supervisan tampoco. Destaca que el uso de IA agéntica está explotando y que estos agentes se están expandiendo por todas las capas: SaaS, nube, endpoint.
Esa declaración captura bien el núcleo de la cuestión. A medida que los agentes se multiplican, crece también la superficie de la cadena de suministro que puede ser explotada — y, como el propio Hertz señaló, las protecciones de hoy simplemente no cubren este nuevo territorio. Estamos hablando de un problema que no es solo técnico en su origen, sino también cultural y organizacional.
Herramientas que usamos a diario
Qué necesitan revisar las empresas ahora mismo
El descubrimiento encendió una alerta que va mucho más allá de este ataque específico. Revela una brecha estructural en la forma en que las empresas están integrando agentes de IA en sus entornos de trabajo. La mayoría de las políticas de seguridad corporativa todavía fueron escritas pensando en humanos y en sistemas tradicionales — firewalls, antivirus, control de acceso basado en identidad. Los agentes de IA autónomos son una categoría diferente, y las reglas para lidiar con ellos todavía se están escribiendo en tiempo real, mientras las empresas ya los usan en producción.
Desde el punto de vista práctico, algunas revisiones son urgentes. Primero, cualquier archivo del tipo llms.txt presente en repositorios o sitios corporativos necesita ser auditado. Las referencias a paquetes externos, dominios de terceros y recursos fuera del perímetro de la empresa deben verificarse en cuanto a titularidad activa y confiabilidad de la fuente. Segundo, los permisos de los agentes de IA necesitan revisarse con el mismo rigor aplicado a usuarios humanos — principio de mínimo privilegio, registros de actividad, alertas para comportamientos fuera de lo normal. Tercero, los equipos de seguridad necesitan empezar a monitorear lo que los agentes están buscando e instalando, no solo lo que hacen los humanos.
Además, vale la pena que los equipos de desarrollo y seguridad comiencen a tratar los archivos de instrucción para agentes de IA con el mismo cuidado que tratan los archivos de configuración críticos. Un llms.txt mal gestionado puede ser tan peligroso como un config.yml expuesto o un .env sin protección adecuada. La cultura de seguridad necesita evolucionar para incluir estos nuevos artefactos digitales — y cuanto antes suceda, menor será la ventana de exposición para ataques que, como este, explotan exactamente la falta de atención colectiva a algo nuevo. 🔐
La buena noticia es que la startup israelí responsable del descubrimiento comunicó los hallazgos de forma responsable, y la demostración sirvió para exponer un riesgo real antes de que fuera explotado con fines maliciosos a gran escala. Pero el episodio sirve como un recordatorio poderoso: la velocidad con la que la IA está siendo adoptada en el entorno corporativo todavía no tiene un equivalente en la velocidad con la que las prácticas de seguridad se están adaptando a ella. Y ese desfase es, por sí solo, una vulnerabilidad enorme que merece atención redoblada de todos los que trabajan con tecnología hoy.
