Brecha de seguridad Anthropic Google: agentes de IA siguieron documentación confiable hacia código sin propietario

Anthropic y Google se encuentran ahora en medio de una disputa de seguridad después de que investigadores informaran que agentes de programación ejecutaron paquetes mencionados en documentación corporativa confiable. Según se informa, un paquete de prueba se ejecutó en un entorno de una empresa de Fortune 500 en cuatro minutos. Claude, OpenAI Codex y Hermes de Nous Research aparecieron en registros posteriores de procesos, de acuerdo con los investigadores.

El hallazgo no demuestra que Anthropic, Google u OpenAI distribuyeran malware deliberadamente. La mayoría de los paquetes registrados para el experimento contenían señales inocuas, que solo informaban cuando se ejecutaban. El descubrimiento más grave fue un paquete npm no relacionado y presuntamente malicioso, vinculado a instrucciones que en algún momento se publicaron en el sitio web del proveedor de autenticación Clerk.

Esta distinción importa porque la cobertura inicial puede dar la impresión de que tres proveedores de IA vulneraron redes corporativas. En cambio, la evidencia apunta a una falla en la cadena de suministro de software. Los agentes confiaron en instrucciones con apariencia oficial, accedieron a registros públicos de paquetes y ejecutaron nombres que nadie había asegurado.

Google entra en esta historia de seguridad de Anthropic Google a través de su apoyo a la comprobación de archivos llms.txt en Lighthouse, su software de auditoría de sitios web. Claude y Codex entran a través de los agentes que, según se informa, siguieron instrucciones de instalación. El problema común no es un modelo ni una empresa. Es la desaparición de la frontera entre documentación y acción ejecutable.

Antes, esa frontera parecía clara. Un desarrollador podía leer una guía de configuración, verificar un paquete y decidir si instalarlo. Un agente autónomo de programación puede condensar esos pasos en una sola operación, a menudo utilizando los permisos existentes del desarrollador.

El resultado es una nueva pregunta de seguridad para toda organización que implemente agentes de programación: cuando el software lee un documento, ¿quién verifica que el documento siga apuntando a algo confiable?

Los agentes corporativos de IA ejecutaron nombres que nadie poseía

Los investigadores convirtieron documentación obsoleta en una prueba ejecutable de que un texto confiable puede convertirse en un punto de entrada.

El investigador de seguridad Alon Hertz y sus colegas examinaron documentación legible por máquinas en 6.214 dominios activos. Su muestra incluía contratistas de defensa, grandes empresas tecnológicas y organizaciones de Fortune 500.

Los investigadores informaron haber encontrado 8.265 archivos llms.txt y llms-full.txt. Un archivo llms.txt es una convención emergente que organiza el contenido de un sitio web para modelos de lenguaje y agentes de IA. Su complemento de mayor tamaño puede ofrecer documentación más extensa en un único archivo legible por máquinas.

Entre los archivos recopilados, 120 sitios web presuntamente hacían referencia a al menos un paquete no registrado o dominio no reclamado. El equipo contabilizó 227 comandos que involucraban paquetes o destinos inexistentes.

No eran necesariamente instrucciones hostiles. Algunas parecían comandos de instalación ordinarios que apuntaban a nombres de paquetes que nunca se habían registrado. Otras hacían referencia a dominios que habían caducado o servicios que ya no estaban reclamados.

Una línea como pip install package-name se vuelve peligrosa cuando el nombre del paquete está disponible en PyPI. El mismo principio se aplica a npm, RubyGems, NuGet, crates.io, Packagist o un subdominio de alojamiento abandonado.

Los investigadores registraron una pequeña selección de estos nombres disponibles. Después publicaron paquetes que contenían código diseñado para contactar con su servidor al ejecutarse. La cuenta de la investigación de Hertz afirma que la primera devolución de llamada llegó desde un entorno de Fortune 500 en cuatro minutos.

Según se informa, otros dos sistemas ejecutaron el código durante la primera hora. Con el tiempo, el equipo recibió varias decenas de devoluciones de llamada de startups y grandes empresas.

La devolución de llamada registró la cadena de procesos padre, que identifica los programas involucrados en el inicio de un proceso. Según los investigadores, esos registros vincularon algunas instalaciones con Claude, OpenAI Codex y Hermes de Nous Research.

El experimento no requirió comprometer esos modelos. Tampoco dependió de una vulnerabilidad de software recién descubierta, un mensaje de phishing o una contraseña de empleado robada. Según se informa, los agentes encontraron instrucciones publicadas en sitios web legítimos y las siguieron con el acceso disponible en sus entornos.

Esa es la inversión central. La documentación corporativa normalmente refuerza la seguridad al mostrar a los desarrolladores la forma aprobada de configurar software. En este caso, referencias abandonadas dentro de esa documentación crearon una oportunidad para que otra persona definiera qué ejecutaría el comando aprobado.

El hallazgo también exige un lenguaje cuidadoso. Los investigadores no han identificado públicamente a las empresas afectadas, divulgado todos los nombres de los paquetes ni proporcionado telemetría suficiente para que terceros reproduzcan cada atribución corporativa. Anthropic, OpenAI y Nous Research no hicieron comentarios antes de que se publicara el informe original.

Incluso con esas limitaciones, el experimento demuestra un mecanismo creíble. Un registro público de paquetes asigna significado a quien controle un nombre. La documentación oficial puede conservar ese nombre mucho después de que su significado previsto haya desaparecido.

Por qué falló la cadena de confianza de Anthropic Google

Los agentes no ignoraron el modelo de confianza. Siguieron un modelo de confianza que ya no se ajustaba a la forma en que opera el software autónomo.

La documentación tradicional presupone que un lector humano se interpone entre las instrucciones y la ejecución. Ese lector puede detectar un nombre de paquete extraño, inspeccionar a su editor o preguntarse por qué un comando de configuración no tiene un repositorio que lo respalde.

Un agente puede realizar las mismas comprobaciones, pero solo cuando sus instrucciones y entorno lo exigen. De lo contrario, se optimiza para completar la tarea solicitada. Encontrar documentación oficial y ejecutar su comando de instalación puede parecer la ruta válida más corta.

La conexión entre Anthropic y Google destaca cómo varias decisiones, razonables de forma independiente, pueden combinarse en una cadena riesgosa. Los sitios web publican guías legibles por máquinas. La herramienta Lighthouse de Google anima a los desarrolladores a hacer esas guías detectables. Los agentes de programación buscan contexto autorizado. Los gestores de paquetes facilitan la recuperación y ejecución de dependencias.

Ninguno de esos componentes necesita ser malicioso. El peligro aparece cuando el agente trata toda la cadena como autenticada.

La guía de Lighthouse de Google describe una auditoría de disponibilidad y formato de llms.txt. Lighthouse no certifica cada comando o dependencia mencionada dentro de un archivo. Por tanto, superar una auditoría de formato no dice nada sobre la propiedad del paquete, la identidad del editor o la seguridad del código.

De forma similar, HTTPS demuestra que un archivo proviene del dominio mostrado en la conexión del navegador. No demuestra que cada paquete mencionado siga perteneciendo al operador de ese dominio.

Un registro público también puede servir un paquete con el nombre escrito correctamente desde una cuenta controlada por un atacante. Esto difiere del typosquatting clásico, en el que los atacantes registran una errata parecida a un paquete popular. Según se informa, los nombres de este experimento se copiaron directamente de documentación oficial.

Eso hace que las instrucciones resulten más persuasivas tanto para los agentes como para los humanos. Un desarrollador que revise una transcripción de terminal podría ver un dominio oficial, un gestor de paquetes conocido y un nombre de dependencia plausible. Todas las señales visibles pueden parecer rutinarias.

El comportamiento de búsqueda del agente agrava el problema. Un usuario puede mencionar solo a un proveedor al solicitar una integración. El agente puede localizar la documentación del proveedor, descubrir llms.txt, seleccionar un comando de instalación e invocar al gestor de paquetes sin recibir del usuario un enlace sospechoso.

Por eso el incidente va más allá de la inyección de prompts. La inyección de prompts suele implicar contenido hostil que intenta redirigir a un agente. Aquí, la instrucción en sí puede ser benigna e históricamente legítima. El fallo de seguridad ocurre después, cuando cambia la propiedad del destino mencionado o nunca existió.

La convención emergente llms.txt tampoco equivale a un estándar web formal con una arquitectura de seguridad establecida. Su utilidad proviene de proporcionar a los modelos contexto conciso y estructurado. Esa misma conveniencia puede concentrar instrucciones operativas en un lugar que se anima a los agentes a considerar confiable.

Por tanto, la brecha de seguridad Anthropic Google es un problema de procedencia. La procedencia es la evidencia que muestra de dónde proviene un artefacto y quién lo controla. El agente verificó la ubicación del documento, pero aparentemente no estableció la procedencia de la dependencia ejecutable detrás del comando.

El verdadero adversario es la autonomía sin procedencia

El conflicto definitorio no es Claude frente a Codex. Es la ejecución autónoma frente a la propiedad verificada del software.

Claude, Codex y Hermes utilizan modelos, interfaces y sistemas de permisos diferentes. Tratar este evento como una simple comparación entre esas herramientas pasaría por alto la condición operativa compartida detrás de las instalaciones reportadas.

Cada agente de programación puede leer el contexto de un proyecto, consultar documentación, editar archivos e invocar herramientas de desarrollo. Estas capacidades hacen útiles a los agentes porque eliminan las transiciones manuales entre investigación y ejecución.

También trasladan una decisión de seguridad al flujo de trabajo del agente. Alguien debe decidir si una dependencia es auténtica, si su versión es aceptable y si sus scripts de instalación deben ejecutarse.

Los gestores de paquetes ejecutan código de forma rutinaria durante la instalación. Un paquete npm puede definir scripts de ciclo de vida, mientras que un paquete de Python puede ejecutar comportamientos relacionados con la instalación mediante su proceso de compilación. El comportamiento exacto varía, pero instalar no equivale a descargar texto inerte.

El ejemplo de Clerk muestra por qué importa. Los investigadores encontraron que un archivo de instrucciones en el sitio web legítimo de Clerk hacía referencia a npx clerk-next-fix-auth-protection. La utilidad npx puede descargar un paquete y ejecutar el comando que expone sin añadirlo de forma permanente al manifiesto de un proyecto.

Según la investigación de seguridad, alguien había reclamado ese nombre de paquete y lo utilizó para distribuir malware activo. Clerk corrigió posteriormente la documentación.

Sigue sin estar claro si ese paquete provocó infecciones a través de un agente de IA. El informe también señala que un binario existente del plugin legítimo de ESLint de Clerk era seguro. Una máquina que careciera de ese binario legítimo podría recuperar en su lugar el paquete controlado por el atacante.

La diferencia es lo bastante sutil como para escapar a una revisión apresurada. Ambas rutas comienzan con un comando publicado por el proveedor real. Ambas utilizan la infraestructura de npm. La ruta peligrosa depende de si el binario esperado ya existe localmente.

Este es el equilibrio práctico al que se enfrentan las empresas. Los agentes aportan más valor cuando pueden resolver dependencias, ejecutar pruebas y corregir fallos sin esperar aprobación después de cada comando. Esos mismos permisos permiten que una decisión de confianza equivocada se convierta en ejecución de código.

El proveedor del modelo puede reducir ese riesgo mediante sandboxing y aprobaciones. La empresa aún debe configurar esos controles, mantener políticas de red y decidir a qué fuentes de paquetes puede acceder un agente.

El proveedor de software posee otra parte del problema. Su documentación se ha convertido en un activo operativo en lugar de contenido de marketing estático. Las referencias a paquetes, los dominios de ejemplo, los comandos copiados y las páginas de configuración archivadas ahora requieren la misma gestión del ciclo de vida que el código ejecutable.

Los operadores de registros también influyen en el resultado. La reserva de espacios de nombres, la verificación de editores, el análisis de paquetes sospechosos y el historial de propiedad pueden ayudar. Sin embargo, los registros no siempre pueden saber que un nombre no reclamado aparece en la documentación de un tercero.

Esta división de responsabilidades hace que culpar de forma simplista sea poco útil. La narrativa Anthropic Google es importante porque atraviesa límites entre productos. Una herramienta de búsqueda o documentación puede facilitar la localización de instrucciones, un agente de IA puede interpretarlas y un registro puede proporcionar el artefacto nombrado.

La seguridad falla cuando cada participante asume que otro participante verificó la propiedad.

Las salvaguardas existentes para agentes no eliminan el riesgo

Claude y Codex ya ofrecen controles importantes, pero esos controles solo funcionan cuando las organizaciones preservan sus límites restrictivos.

La guía de seguridad de Claude de Anthropic describe la inyección de prompts como texto hostil que intenta manipular las instrucciones de un asistente. También documenta controles de permisos y restricciones para comandos que recuperan contenido web arbitrario.

Claude Code puede utilizar sandboxing para limitar el acceso al sistema de archivos y a la red. Los procesos secundarios heredan esas restricciones del sistema operativo, lo que ayuda a evitar que un comando permitido escape discretamente a un proceso menos restringido.

OpenAI describe un enfoque por capas similar. Su modelo de seguridad de Codex combina límites de sandbox, políticas de aprobación, acceso a red gestionado, reglas y telemetría orientada a agentes.

OpenAI afirma que sus implementaciones gestionadas no conceden a Codex acceso saliente sin restricciones. Se pueden permitir destinos previstos, los dominios desconocidos pueden requerir aprobación y los equipos de seguridad pueden exportar registros que cubren prompts, llamadas a herramientas, aprobaciones y decisiones de red.

Estas salvaguardas importan, pero no invalidan automáticamente los hallazgos de los investigadores. Las organizaciones pueden configurar agentes con acceso más amplio. Los desarrolladores pueden aprobar comandos. Las instalaciones locales pueden heredar permisos y conectividad de red del usuario que las ejecuta.

Un registro de paquetes también es un destino previsto en muchos entornos de desarrollo. Bloquear todo acceso a npm o PyPI interrumpiría compilaciones ordinarias, actualizaciones de dependencias y la configuración de pruebas. Permitir esos dominios elimina una señal de red evidente que podría distinguir una instalación maliciosa.

El software de detección y respuesta en endpoints se enfrenta a un desafío similar. Un agente de programación inicia un gestor de paquetes estándar, que se comunica con un registro conocido mediante una conexión cifrada. El proceso puede parecer actividad normal de un desarrollador hasta que el paquete descargado realiza algo claramente hostil.

El beacon de investigación fue deliberadamente mínimo. Según los informes, contactó con un servidor y registró el contexto de ejecución. Un atacante real podría intentar robar credenciales, descubrir el entorno, establecer persistencia o modificar código fuente.

Sin embargo, la evidencia pública no muestra que los paquetes experimentales realizaran esas acciones. Tampoco establece que decenas de empresas sufrieran una vulneración en producción. Ejecutaron código de prueba de concepto, lo cual es grave, pero más limitado que una brecha confirmada.

Esta distinción escéptica debería orientar la respuesta empresarial. Los equipos no deben asumir que cada uso de Claude, Codex o Hermes crea una infección. Deben identificar las condiciones necesarias para que esta vía funcione.

El agente necesita acceso a la documentación pertinente. Necesita autoridad para invocar un gestor de paquetes. El entorno debe permitir la recuperación desde el registro. El paquete debe ejecutar código significativo y los controles existentes deben no lograr contener su comportamiento.

Eliminar cualquiera de esas condiciones puede interrumpir la cadena. Restringir el acceso a la red es una opción. Exigir aprobación humana para la instalación de dependencias es otra. Ejecutar agentes en contenedores desechables puede limitar las consecuencias cuando un paquete sí se ejecuta.

Las organizaciones también pueden aplicar un proxy interno de dependencias. El proxy puede permitir paquetes y versiones aprobados mientras rechaza espacios de nombres desconocidos. Este enfoque desplaza la decisión de confianza de un agente que lee documentación pública.

Los avisos de aprobación por sí solos son menos fiables cuando presentan únicamente un comando conocido. Un revisor necesita contexto sobre la propiedad del paquete, su antigüedad, la identidad del editor, el historial de descargas y si la dependencia aparece en una lista de materiales de software aprobada.

La lección no es que las salvaguardas sean inútiles. Es que los controles diseñados en torno a comandos claramente maliciosos pueden pasar por alto comandos legítimos que se resuelven a propietarios no confiables.

La documentación ahora forma parte de la cadena de suministro de software

Las empresas deben tratar cada referencia ejecutable de la documentación como una dependencia que puede caducar, desviarse o cambiar de propietario.

La respuesta inmediata comienza con un inventario. Las organizaciones deberían buscar comandos de instalación en llms.txt, llms-full.txt, portales para desarrolladores, guías archivadas, ejemplos de código, artículos de soporte y referencias de API generadas.

Cada paquete, dominio, repositorio, imagen de contenedor y subdominio alojado mencionado necesita un propietario. Un nombre que nadie reconoce no debería seguir siendo público mientras avanza una investigación.

Los equipos deben verificar que los nombres de paquetes públicos coincidan con las cuentas reales de registro de la organización. También deberían inspeccionar si los paquetes con ámbito están disponibles cuando en documentación antigua aparece un nombre global sin ámbito.

Los procesos de documentación necesitan pruebas automatizadas. Una compilación puede verificar que cada paquete existe, pertenece a un editor aprobado, se resuelve a un repositorio previsto y no ha cambiado de propietario.

La comprobación de enlaces por sí sola es insuficiente. Un paquete malicioso o un dominio recuperado puede devolver una respuesta correcta. El proceso debe validar la identidad, no la disponibilidad.

Las empresas deberían reservar nombres antes de publicar documentación. Esto es similar a registrar dominios defensivos alrededor de un producto importante, pero los espacios de nombres de paquetes requieren mantenimiento continuo.

El mismo principio se aplica cuando se retira un proyecto. Eliminar un paquete sin eliminar sus instrucciones de instalación crea una brecha de propiedad. Abandonar un subdominio de alojamiento mientras se mantienen enlaces hacia él puede permitir que otra parte herede una ruta de confianza.

La documentación generada por IA merece un escrutinio adicional, pero las páginas escritas por humanos no están exentas. Los investigadores encontraron evidencia de que algunas referencias cuestionables eran anteriores a la actual era de los agentes. Copiar esas páginas en llms-full.txt hizo que los errores antiguos fueran más fáciles de consumir para el software autónomo.

Las empresas que implementan agentes necesitan un plano de control complementario. Las sesiones de los agentes deberían ejecutarse bajo identidades dedicadas en lugar de la cuenta sin restricciones de un desarrollador. Las credenciales deben limitarse al repositorio y la tarea actuales.

La instalación de paquetes debería realizarse dentro de un entorno aislado con acceso limitado a secretos. Si una dependencia necesita acceso a la red durante la instalación, ese acceso debería ser explícito y quedar registrado.

Los equipos deberían conservar el contexto de razonamiento del agente junto con la telemetría del sistema operativo. Un registro de procesos puede mostrar que npm se inició, mientras que los registros nativos del agente pueden indicar qué documento proporcionó el nombre del paquete.

Ese contexto importa durante la respuesta a incidentes. Los investigadores necesitan distinguir una dependencia de proyecto aprobada de un paquete seleccionado después de que un agente navegara instrucciones externas.

Las listas de permitidos de dependencias pueden reducir el riesgo, pero requieren una vía de excepción para paquetes nuevos. Esa excepción debería recopilar evidencia de procedencia y exigir un propietario humano identificado.

Las organizaciones también deberían mantener un registro consultable de las fuentes que consultan los agentes. Esto puede incluir instantáneas de documentación, metadatos de paquetes, decisiones de aprobación y cambios de código generados. Una base de conocimiento técnico controlada puede ayudar a los revisores a reconstruir por qué un agente seleccionó una dependencia.

La lección más amplia va más allá de llms.txt. Los agentes de programación consumen descripciones de incidencias, archivos de repositorios, resultados de búsqueda, documentación de paquetes, respuestas de Model Context Protocol y guías internas generadas.

Cualquiera de esas fuentes puede contener una instrucción. Si el agente tiene herramientas, la instrucción puede convertirse en una acción.

Eso convierte la integridad de la documentación en parte de la seguridad de la cadena de suministro de software. La empresa no puede proteger únicamente los repositorios de código fuente y los servidores de compilación mientras deja fuera de su control las instrucciones legibles por máquinas.

Tres señales mostrarán si la industria aprendió

La siguiente fase depende de que la documentación, los permisos de los agentes y la identidad de los registros mejoren en conjunto.

La primera señal es la divulgación y la remediación en los 120 sitios web afectados. El equipo de Hertz afirma que contactó a las organizaciones afectadas y a los equipos de seguridad pertinentes, pero el registro público no identifica la mayoría de los dominios.

Hay que observar si las empresas auditan archivos llms.txt, reservan nombres de paquetes y publican avisos de incidentes. Una limpieza coordinada reforzaría el argumento de que la industria reconoce la documentación legible por máquinas como infraestructura sensible para la seguridad.

El silencio no demostraría que no se produjeron correcciones. Muchas organizaciones reparan referencias expuestas sin divulgación pública, especialmente cuando los investigadores utilizaron código inofensivo y no encontraron robo de datos confirmado.

La segunda señal es una comprobación de procedencia a nivel de producto por parte de los proveedores de agentes. Claude, Codex y Hermes ya pueden pedir aprobación antes de ejecutar comandos, pero la aprobación se vuelve más útil cuando la interfaz explica la dependencia detrás del comando.

Un cambio significativo advertiría que un paquete es nuevo, no está verificado, no está relacionado con la cuenta de editor conocida del proveedor o está ausente del grafo de dependencias existente del proyecto. Un sistema más sólido podría requerir aprobación explícita siempre que la documentación pública apunte a un paquete no reconocido.

Una función de este tipo reforzaría la respuesta de seguridad de Anthropic Google porque abordaría el punto de decisión antes de la ejecución. Otra advertencia genérica sobre comandos de shell ofrecería menos protección.

La tercera señal es la integración entre registros y políticas empresariales. Los gestores de paquetes y los proxies internos pueden exponer historial de editores, antigüedad del espacio de nombres, estado de firma y cambios de propiedad. Las plataformas de agentes pueden utilizar esos metadatos antes de seleccionar o instalar una dependencia.

Una política empresarial podría permitir automáticamente paquetes establecidos mientras aísla paquetes desconocidos para su revisión. También podría rechazar un paquete cuyo nombre aparece en documentación oficial pero carece de una conexión verificable con el editor.

Esta señal debilitaría la advertencia más amplia de los investigadores si comprobaciones de procedencia fiables detienen la vía de ataque entre múltiples agentes. La reforzaría si los agentes siguen instalando nombres reclamados recientemente pese a disponer de datos de identidad.

La evidencia actual respalda una conclusión mesurada. Según los informes, los investigadores demostraron ejecución de código en entornos corporativos reales y vincularon parte de la actividad a destacados agentes de programación. No demostraron que los proveedores de modelos instalaran malware intencionadamente ni que cada callback reportado representara una vulneración grave.

El hallazgo más importante es estructural. La documentación de confianza, la ejecución autónoma y los registros públicos ahora forman una cadena de suministro que muchos programas de seguridad no inventarían.

Los desarrolladores y compradores empresariales deberían plantear preguntas directas antes de ampliar los permisos de los agentes. ¿Puede el agente acceder a registros públicos de paquetes? ¿Verifica la identidad del editor? ¿Están aislados los comandos de instalación? ¿Pueden los equipos de seguridad reconstruir qué documento provocó una acción?

La brecha de seguridad entre Anthropic y Google no se cerrará únicamente con un mejor comportamiento de los modelos. Los responsables de la documentación, los registros, los proveedores de agentes y los administradores empresariales controlan cada uno un eslabón distinto.

Antes de otorgar una autonomía más amplia a un agente de programación, pruebe toda esa cadena con una dependencia no reconocida. Si el agente la instala sin presentar su procedencia, el entorno está tratando la documentación como autoridad en lugar de como evidencia.