Una investigación de seguridad ha vinculado a Claude, OpenAI Codex y los agentes de programación Hermes de Nous Research con la instalación de paquetes de software no reclamados dentro de entornos corporativos. La actividad surgió cuando los investigadores probaron archivos de documentación que dirigían a los agentes hacia paquetes y dominios que ninguna organización poseía actualmente.

Los hallazgos importan porque los comandos parecían instrucciones normales de configuración para desarrolladores y, en varios casos, procedían de sitios web corporativos legítimos. Los investigadores dijeron que recibieron un callback de una empresa Fortune 500 en menos de una hora después de registrar algunos nombres de paquetes y dominios abandonados para una prueba de concepto. La evidencia no establece un compromiso generalizado, pero muestra cómo los agentes de IA con acceso a shell pueden convertir documentación obsoleta en un punto de entrada para la cadena de suministro de software.

Lo que encontraron los investigadores

Según Ars Technica AI, una startup de seguridad furtiva en Israel analizó 6.214 dominios activos asociados con contratistas de defensa, empresas Fortune 500 y grandes firmas tecnológicas. El equipo identificó 8.265 archivos que usaban las convenciones emergentes llms.txt y llms-full.txt, que los sitios web emplean para ofrecer descripciones y navegación legibles por máquina para sistemas de IA.

Entre esos archivos, 120 alojados en sitios distintos hacían referencia a uno o más nombres de paquetes no registrados o dominios no reclamados. En conjunto, los investigadores contaron 227 comandos para instalar paquetes o acceder a dominios que no tenían propietario en el momento del análisis. Muchas referencias involucraban ecosistemas de paquetes comunes, incluidos PyPI y npm.

Para probar el riesgo, los investigadores registraron varios de los nombres abandonados y alojaron paquetes diseñados para contactar con su servidor cuando se ejecutaran. El balizamiento resultante identificó procesos padre asociados con Claude, Codex y Hermes. Los investigadores también recibieron callbacks de unas pocas decenas de organizaciones, incluidas algunas empresas Fortune 500 y startups, después de procesar los paquetes de prueba.

La investigación no mostró que estas empresas estuvieran infectadas con malware. Mostró que sus entornos ejecutaron código de prueba de concepto o, de otro modo, alcanzaron la infraestructura de los investigadores. Anthropic, OpenAI y Nous Research no habían respondido a las solicitudes de comentario al momento de la publicación, según Ars Technica AI.

Un problema de documentación se convierte en un riesgo de ejecución

La exposición proviene de la forma en que los agentes de programación con IA combinan navegación, recuperación y ejecución de comandos. Un agente puede leer la documentación de un proveedor, tratar su contenido como autoritativo y luego ejecutar el comando de configuración en un entorno local o corporativo. Si el paquete referenciado nunca se registró, un atacante puede reclamar el nombre más tarde y publicar código malicioso bajo él.

Un patrón documentado usaba instrucciones pip install o npm install para paquetes que no existían. Otro hacía referencia a un dominio inexistente de un marco de pruebas. Por tanto, el problema de seguridad no se limita a un sitio web malicioso o a un prompt envenenado deliberadamente. Un autor de documentación pudo haber introducido hace años una dependencia incorrecta, obsoleta o alucinada, dejando la referencia disponible para que otra persona la reclame.

Los investigadores también describieron un caso relacionado con el sitio web de Clerk. Un archivo llms.txt incluía un comando npx asociado con un nombre de paquete que posteriormente fue reclamado y utilizado para distribuir malware activo. Debido a que npx puede recuperar y ejecutar el binario de un paquete sin añadirlo al manifiesto de dependencias de un proyecto, el comando creó una vía especialmente directa hacia la ejecución.

Clerk posteriormente corrigió el problema de documentación. La empresa dijo que los usuarios que ya habían instalado un paquete relacionado, @clerk/eslint-plugin, no estuvieron expuestos al paquete malicioso en las circunstancias que describió. Sigue sin estar claro si la confusión con Clerk causó infecciones reales.

Por qué las defensas convencionales pueden no detectar la señal

La investigación destaca una brecha entre el punto en que se toma una decisión insegura y el punto en que las herramientas de seguridad corporativa suelen buscar abusos. Un agente de programación que ejecute pip o npm contra un repositorio de paquetes conocido puede parecer actividad normal de desarrollo. Las herramientas de detección y respuesta en endpoints pueden ver a un asistente de IA aprobado lanzando un gestor de paquetes familiar a través de una conexión de red permitida.

El problema es la relación no verificada entre la documentación y la dependencia. Un agente puede confirmar que el archivo proviene de un dominio HTTPS oficial y que el comando usa un registro estándar, mientras falla al verificar la propiedad del paquete, la identidad del publicador, la procedencia o si la dependencia se espera en el proyecto. Esas comprobaciones no forman necesariamente parte del flujo de trabajo predeterminado del agente.

Esto está relacionado con la inyección de prompt, pero es más amplio en un aspecto importante. La inyección de prompt generalmente implica instrucciones plantadas deliberadamente para manipular un modelo. En el escenario descrito por los investigadores, la instrucción original puede ser genuina y benigna. El peligro aparece más tarde, cuando un paquete o dominio abandonado queda disponible para un atacante.

Qué significa para los creadores de IA y los equipos empresariales

Para los desarrolladores de agentes de IA, los hallazgos refuerzan el caso de tratar la documentación recuperada como entrada no confiable, en lugar de una extensión del comando del usuario. Los agentes que pueden ejecutar comandos de shell deberían separar la lectura de instrucciones de la autorización para ejecutarlas, exigir confirmación para nuevas dependencias y verificar la propiedad y procedencia de los paquetes antes de instalarlos. El sandboxing y el acceso restringido a la red pueden reducir las consecuencias cuando esas comprobaciones fallen.

Los equipos de producto que despliegan agentes de programación dentro de las empresas se enfrentan a una cuestión de gobernanza más inmediata: si un asistente debería tener acceso sin restricciones a repositorios internos, registros de paquetes, credenciales y sistemas cercanos a producción al mismo tiempo. Una política de despliegue útil puede permitir la generación y prueba de código en un entorno aislado mientras bloquea la instalación arbitraria de paquetes o exige una lista de dependencias aprobada.

Los equipos de seguridad deberían auditar archivos llms.txt y llms-full.txt en sus propios dominios, pero el riesgo no se limita a esos formatos. Los agentes también consumen archivos README, guías de SDK de proveedores, hilos de incidencias, ejemplos y documentación de terceros. Las organizaciones necesitarán verificación de dependencias y controles de procedencia en todo el recorrido de recuperación, incluidos socios de confianza y proyectos comunitarios.

La implicación de mercado es práctica más que especulativa. Los asistentes de programación con IA están recibiendo más autoridad para actuar, mientras que las defensas de la cadena de suministro de software siguen diseñadas en gran medida para desarrolladores humanos y sistemas de compilación convencionales. Cuanto más a menudo instalen herramientas los agentes de forma automática, más importante será registrar por qué se seleccionó una dependencia y qué fuente la autorizó.

Qué observar a continuación

La primera señal será si Anthropic, OpenAI o Nous Research divulgan cambios en la forma en que sus agentes manejan los comandos de instalación, los paquetes no registrados y las instrucciones recuperadas. Los investigadores de seguridad y los usuarios empresariales también deberían vigilar controles de registros de paquetes que señalen la reutilización de nombres abandonados y plataformas de agentes que añadan verificaciones de procedencia antes de la ejecución.

Una segunda señal es si las empresas auditan y corrigen su documentación legible por máquina. El análisis de los investigadores mostró que algunas entradas defectuosas databan de قبل de la era de la IA, lo que sugiere que la limpieza por sí sola puede no resolver el problema. Los equipos necesitarán supervisar la propiedad de los paquetes con el tiempo, no solo validar una dependencia cuando la documentación se publica por primera vez.

Por último, los equipos de respuesta a incidentes pueden buscar pruebas de que callbacks o reclamaciones de paquetes similares hayan ocurrido fuera de pruebas controladas. La cobertura actual demuestra exposición y al menos un caso de malware en vivo relacionado con una referencia de documentación, pero no cuantifica las infecciones confirmadas entre las organizaciones afectadas.

Perspectiva de Creati.ai

Este incidente es una advertencia sobre la autoridad, no solo sobre la precisión del modelo. Un agente de IA puede hacer una solicitud técnicamente correcta a un registro de paquetes y aun así estar actuando sobre una instrucción insegura. Esa distinción es fácil de pasar por alto cuando el comando se originó en un dominio oficial del proveedor.

Para las empresas, la respuesta sensata no es abandonar los asistentes de programación, sino restringir lo que pueden ejecutar y exigir procedencia verificable de las dependencias. Hasta que los agentes puedan distinguir de forma fiable el material de referencia de la autorización, cada instalación automatizada debe tratarse como una acción sensible para la seguridad.