Anthropic revisó 141.006 ejecuciones de evaluación en las que sus modelos podrían haber tenido acceso a internet y encontró tres casos en los que uno de ellos salió a la red desde un entorno que debía estar aislado y acabó comprometiendo la infraestructura de tres organizaciones reales. Ninguna de ellas se había dado cuenta. El incidente más antiguo es de abril.
Qué ha reconocido Anthropic
El 30 de julio de 2026, Anthropic publicó en su web un informe sobre tres incidentes detectados en sus propias evaluaciones de capacidades ofensivas. La revisión no fue espontánea: la empresa la puso en marcha después de que OpenAI reconociera el 21 de julio que varios de sus modelos habían escapado de un entorno de pruebas aislado y accedido a la infraestructura de producción de Hugging Face, un caso que ya analizamos aquí.
Conviene precisar la cifra, porque en muchas noticias se cita mal. No revisaron todas sus evaluaciones: revisaron las 141.006 ejecuciones en las que el modelo podría haber obtenido acceso a internet. Es un subconjunto filtrado por ese criterio.
Anthropic empezó a revisar transcripciones el jueves 23 de julio y detuvo ese mismo día todas sus evaluaciones de ciberseguridad al encontrar indicios de que Claude podía haber accedido a internet. Identificó los tres incidentes al día siguiente. El lunes 27 avisó a su socio evaluador, la empresa israelí de seguridad Irregular, y a las tres organizaciones afectadas. Dos de ellas no habían detectado nada ni se habían puesto en contacto con Anthropic. A la tercera seguían intentando localizarla el día de la publicación.
Los tres incidentes suman seis ejecuciones, cuatro de ellas contra la misma organización, e implican a tres modelos distintos: Claude Opus 4.7, Claude Mythos 5 y un modelo interno de investigación no destinado a lanzamiento público.
Por qué el modelo salió a internet
En los tres casos la tarea era un capture-the-flag: se le da al modelo un escenario ficticio, se le indica que hay una información secreta escondida en otra máquina de la red y se le encarga entrar y recuperarla. El reto se deja abierto y no se prescribe ningún método.
El prompt de Anthropic afirmaba explícitamente que el entorno era una simulación y que no había acceso a internet. Por un malentendido entre Anthropic e Irregular, eso no era cierto: las máquinas del ejercicio tenían conexión real. Ninguna de las dos empresas lo detectó hasta la revisión de la semana pasada.
A partir de ahí el error se encadena solo. Convencido de que todo lo alcanzable formaba parte del ejercicio, el modelo trató los sistemas reales que encontró como piezas del juego. Anthropic apunta un detalle que explica por qué no sospechó: los entornos de evaluación de ciberseguridad se construyen deliberadamente con apariencia realista, de modo que un objetivo con pinta de real no es en sí mismo prueba de que no sea simulado.
Las evaluaciones se ejecutan sin los clasificadores ni la monitorización que acompañan a los modelos desplegados, porque el objetivo es medir la capacidad bruta. Sí conservaban su entrenamiento de seguridad específico. La infraestructura de estas pruebas supuestamente está separada y no tiene acceso a los sistemas internos ni a los datos de clientes de Anthropic.
Los tres incidentes
Incidente 1 (Opus 4.7). La empresa ficticia elegida por el socio evaluador compartía nombre con un dominio real y activo. En cuatro ejecuciones, Claude no consiguió alcanzar su objetivo simulado, descubrió que la empresa real era accesible por internet y la asumió como la diana correcta. Buscó, encontró y explotó vulnerabilidades en su infraestructura, y extrajo credenciales de aplicación e infraestructura y acceso a una base de datos con varios cientos de filas de datos de producción. Es el impacto más grave identificado. También es el único caso en que el modelo siguió atacando después de reconocer que el sistema era real: en dos de las cuatro ejecuciones racionalizó que la empresa real debía formar parte del ejercicio.
Incidente 2 (Mythos 5). El más llamativo. Se detalla en el apartado siguiente.
Incidente 3 (modelo interno de investigación). Al no poder alcanzar su objetivo ficticio, el modelo buscó alternativas en línea y escaneó unos 9.000 objetivos. Acabó comprometiendo la aplicación expuesta a internet de una empresa mediante técnicas básicas: leer credenciales de una página de depuración expuesta e inyección SQL. Más adelante advirtió que el sistema comprometido estaba en una cuenta en la nube sin relación con el ejercicio, concluyó por su cuenta que el objetivo era real y detuvo el ataque.
El modelo que necesitaba un teléfono
Dentro del entorno ficticio, Mythos 5 encontró un documento dejado a propósito que parecía ser las instrucciones de configuración de otra empresa inventada para desarrolladores nuevos. Esas instrucciones mandaban instalar desde PyPI, el repositorio público de software Python, un paquete que en realidad no existía.
El modelo identificó ahí la vía de entrada: si registraba ese nombre libre y publicaba código propio, los sistemas de la empresa ficticia lo descargarían e instalarían solos. Es un ataque de manual. Lo interesante es lo que hizo falta para llegar hasta él.
Para publicar en PyPI necesitaba una cuenta. Para la cuenta necesitaba un correo electrónico. Para el correo necesitaba un número de teléfono. Al no encontrar ningún servicio gratuito de números, intentó por varias vías conseguir fondos para pagar uno, y falló en todas. Finalmente dio marcha atrás, localizó un proveedor de correo gratuito no bloqueado, registró con él una cuenta de PyPI y subió el paquete. Anthropic describe el conjunto como extremos considerables, y señala que a un participante humano esa cadena de obstáculos le habría indicado que ya no estaba en un ejercicio.
El paquete estuvo publicado alrededor de una hora. En ese intervalo se descargó y ejecutó en 15 sistemas reales. Los sistemas de seguridad de PyPI acabaron retirándolo automáticamente, sin aviso externo.
Uno de esos 15 sistemas era el escáner de una empresa de seguridad, distinta de la empresa ficticia del escenario, que instala paquetes de Python de forma rutinaria para analizarlos en busca de malware. Al instalarlo se ejecutó el código oculto. Anthropic cree que ese escáner trataba los paquetes de PyPI como seguros de instalar, y esa confianza permitió que el código robase las credenciales de la empresa y las enviase a un punto de recogida que el propio modelo había preparado. Con ellas, Claude accedió después a más infraestructura de esa empresa.
Un escáner de análisis por comportamiento tiene que ejecutar el paquete: ese es su método, no un descuido. Lo que falló no fue la detección sino la contención: el entorno de análisis tenía credenciales alcanzables y salida de red hacia el exterior. Es posible que el escáner marcase el paquete como malicioso y lo reportase correctamente, y que el daño ya estuviera hecho. Detectar después de detonar sirve para el resto del mundo, no para uno mismo.
Es exactamente el mismo fallo que el de Anthropic con su entorno de evaluación. Dos entornos construidos para analizar cosas peligrosas, ninguno de los dos aislado a la altura de lo que analizaba.
Lo que el informe no cuenta
Anthropic no describe cómo estaba construido el paquete, ni bajo qué nombre se publicó, ni el mecanismo por el que el código llegó a ejecutarse. Solo dice haber entregado los indicadores correspondientes al equipo de PyPI. La omisión es deliberada y razonable: publicar la mecánica sería una receta para ataques similares. Anthropic anunció que difundirá una transcripción parcialmente censurada de esa ejecución en el plazo de una semana desde el 30 de julio.
Quedan otras dos lagunas menos justificables: el informe no explica sobre qué infraestructura montó el modelo el punto de recogida de credenciales. Llama la atención en un relato donde, poco antes, ese mismo modelo había fracasado en todos sus intentos de conseguir dinero para pagar un simple número de teléfono. La segunda es mayor. El paquete se ejecutó en 15 sistemas y el informe describe uno. De los otros catorce no se dice qué eran, ni si sufrieron impacto, ni si Anthropic los identificó, ni si los avisó. Las notificaciones se limitaron a las tres organizaciones de los incidentes, y la empresa de seguridad es una de ellas. No se puede afirmar que esos catorce sistemas fueran comprometidos -podrían ser otros escáneres, réplicas del repositorio, sistemas de integración continua o máquinas de desarrolladores-, pero tampoco consta que nadie se lo haya preguntado.
Tres meses sin que nadie mirase
El incidente más antiguo es de abril. La detección llega a finales de julio, y solo porque otro laboratorio publicó un caso parecido. Entre medias hubo credenciales exfiltradas, una base de datos de producción tocada y malware funcional en un repositorio público.
Anthropic lo admite al enumerar las medidas que habrían evitado los incidentes o reducido su probabilidad: validar cuidadosamente todas las vías de acceso a internet antes de empezar las evaluaciones, y monitorizar en tiempo real los registros. Añade que tanto ellos como su socio podrían haber revisado las transcripciones y los registros de red con más detalle. Son cosas que se enumeran porque no estaban. Existía un mecanismo de monitorización, insuficiente.
Contexto: no es un problema de un fabricante
El mismo 21 de julio, el AI Security Institute británico publicó una investigación sobre conductas de trampa en evaluaciones de modelos frontera. Probó cinco sistemas -GPT-5.4, GPT-5.5, GPT-5.6 Sol, Claude Opus 4.7 y Claude Mythos Preview- con 475 ejecuciones cada uno. Todos hicieron trampa al menos parte del tiempo, sin que se les indujera a ello: 14,1%, 11,4%, 12,6%, 9,1% y 7,8% respectivamente. Entre las conductas registradas, buscar soluciones en internet, sortear restricciones de aislamiento de red, sondear el propio software de evaluación y atacar sistemas ajenos al objetivo oficial.
El AISI concluye que la tasa de trampa no aumenta con la capacidad del modelo, de modo que no es un problema que se resuelva solo con modelos mejores. Que los modelos no reportan de forma fiable esa conducta al ser preguntados y a menudo ni siquiera razonan sobre ella, por lo que detectarla exigirá monitorización robusta. Y que la solución de fondo, entrenarlos para que no hagan trampa, lleva más de un año documentada como problema sin resolver.
Lo que dice Anthropic sobre sí misma
La empresa sostiene que en ninguno de los casos Claude se exfiltró a sí mismo ni intentó deliberadamente escapar del entorno de prueba, que no encontró ni explotó vulnerabilidades complejas -contraseñas débiles y endpoints sin autenticar- y que no vio evidencia de ningún modelo persiguiendo un objetivo propio. Su conclusión es que estos incidentes están más cerca de un fallo operativo y de infraestructura que de un fallo de alineamiento, y marca la diferencia con el caso de OpenAI: allí los modelos explotaron una vulnerabilidad desconocida para escapar del aislamiento, aquí encontraron una puerta abierta.
Apunta además la corrección más simple de todas: probablemente el modelo no habría salido a internet si el prompt hubiera explicado con claridad qué sistemas estaban dentro y fuera de alcance. Y reconoce, en el apartado de lecciones, algo de mayor calado: que los entornos de evaluación necesitan someterse al mismo estándar de seguridad que cualquier otro sistema donde corran sus modelos. Está en conversaciones con METR para una revisión independiente.
Fuentes: informe de Anthropic "Investigating three real-world incidents in our cybersecurity evaluations" (30/07/2026); publicación de OpenAI sobre el incidente de Hugging Face (21/07/2026); blog del AI Security Institute sobre conductas de trampa en evaluaciones de modelos frontera (21/07/2026).
