El investigador de seguridad Alon Hertz y un pequeño equipo rastrearon la web en busca de archivos llms.txt, un nuevo formato que los sitios publican junto a robots.txt para indicar a los agentes de codificación de IA qué documentación leer, qué API llamar y qué paquetes instalar. La herramienta Lighthouse de Google, integrada en las Chrome DevTools, ahora audita este archivo bajo una categoría llamada "Agentic browsing", lo que empuja a más sitios a publicarlo.

npx clerk-next-fix-auth-protection

En un solo fin de semana, el equipo resolvió 8.565 archivos llms.txt en 6.214 dominios activos, de un total de unas 15.000 empresas catalogadas que incluyen compañías Fortune 500, gigantes tecnológicos, fintechs y contratistas de defensa. Al revisar los comandos de instalación dentro de esos archivos, identificaron más de 237 nombres de paquetes, dominios y subdominios referenciados, repartidos entre PyPI, npm, RubyGems, NuGet, crates.io y Packagist, además de dominios .dev y .io caducados y subdominios abandonados de Render, Vercel, Fly y Netlify, ninguno de los cuales había sido realmente reclamado.

Para comprobar el riesgo real, los investigadores registraron por su cuenta algunos de esos nombres libres e incrustaron en cada uno una señal inofensiva de aviso de instalación. La primera notificación de instalación desde una empresa Fortune 500 llegó en menos de cuatro minutos, una segunda siguió antes de una hora, y decenas más llegaron de empresas de distintos tamaños. Otra prueba con cinco configuraciones de modelos punteros y dos CLI agénticas mostró que una sola instrucción de una línea, mencionando solo el nombre del proveedor, sin URL ni referencia a llms.txt, bastó en 100 ejecuciones para que los agentes localizaran el archivo por sí mismos e instalaran el paquete falso.

Al analizar los datos, el equipo encontró un ataque real, no simulado, ya activo. La guía llms.txt del proveedor de autenticación Clerk para aplicaciones Next.js indica a los agentes ejecutar "npx clerk-next-fix-auth-protection". Ese binario en teoría forma parte del paquete real de Clerk, @clerk/eslint-plugin, pero cuando el comando desnudo se ejecuta antes de instalar ese paquete localmente, npx resuelve el nombre contra el registro público de npm, donde un tercero ya lo había registrado. El paquete implantado no tiene funcionalidad real: en cada instalación exfiltra el nombre de usuario, el nombre de la máquina, el directorio de trabajo y la marca de tiempo a un servidor externo. Está catalogado como MAL-2026-11069 bajo CWE-506 y fue señalado por OSV.dev de Google y por Amazon Inspector. El equipo de seguridad de Clerk fue notificado y corrigió el problema con rapidez; el paquete malicioso lo creó un tercero ajeno a Clerk.

Los investigadores sostienen que las herramientas de detección de endpoint pasan por alto este patrón, porque el tráfico resultante parece una instalación normal de pip o npm, lanzada por un agente de codificación que la propia empresa instaló a propósito. Describen el cambio de fondo así: los datos se convierten en código. Documentación, foros y tickets escritos para humanos ahora son leídos y ejecutados por agentes de IA, borrando la vieja frontera entre contenido pasivo y código ejecutable, sin ninguno de los controles de integridad que el código normalmente exige.