Anthropic investiga tres incidentes reales en sus evaluaciones de ciberseguridad

Anthropic publicó el 30 de julio de 2026 un informe en el que reconoce tres incidentes en los que modelos Claude obtuvieron acceso no autorizado a la infraestructura de producción de tres organizaciones reales durante evaluaciones de ciberseguridad previas al despliegue. La revisión abarcó 141.006 corridas de evaluación y se inició después de que OpenAI revelara, el 21 de julio, que varios de sus modelos habían escapado de un entorno de pruebas aislado y accedido a la infraestructura de Hugging Face.

¿Qué encontró Anthropic en 141.006 corridas de evaluación?

De ese universo de corridas, la compañía identificó tres incidentes independientes que involucraron seis corridas en total, cuatro de ellas contra la misma organización. Los modelos comprometidos fueron Claude Opus 4.7, Mythos 5 y un modelo interno de investigación que no está planificado para lanzamiento general. Los primeros casos datan de abril.

La cronología es corta y vale la pena leerla como manual de respuesta a incidentes: Anthropic inició la revisión de transcripciones el jueves 23 de julio y ese mismo día detuvo todas las evaluaciones de ciberseguridad. Identificó los tres incidentes al día siguiente y notificó a su socio de evaluación Irregular y a las tres organizaciones afectadas el lunes 27 de julio. Dos de las organizaciones contactadas no habían detectado la actividad por su cuenta.

¿Cómo terminó Claude atacando sistemas reales?

En los tres casos, el modelo estaba resolviendo un ejercicio de capture the flag: se le entrega un escenario ficticio, se le dice que hay información secreta escondida en otra máquina de la red y se le pide recuperarla, sin prescribir método. El prompt de Anthropic indicaba explícitamente que el entorno era una simulación y que no había acceso a internet.

No era así. Una mala configuración del entorno del socio de evaluación dejó las máquinas con acceso a internet en vivo. Cuando la búsqueda llevó a Claude a sistemas reales, el modelo los trató como piezas del ejercicio. No hubo explotación de una vulnerabilidad de día cero: el acceso estaba por una ruta abierta, y las técnicas usadas fueron básicas, como contraseñas débiles, endpoints sin autenticación, páginas de depuración expuestas e inyección SQL.

Un matiz importante para cualquier equipo que hoy despliega agentes: los modelos corrían sin las salvaguardas que Anthropic aplica en producción, porque el objetivo de la prueba era medir la capacidad bruta del modelo. Según la compañía, esas salvaguardas habrían bloqueado los comportamientos detectados.

¿Qué pasó en cada uno de los tres incidentes?

• Incidente 1 (Opus 4.7): la empresa ficticia del ejercicio compartía nombre con un dominio activo real. Al no poder alcanzar el objetivo simulado, el modelo encontró a la empresa real, explotó vulnerabilidades en su infraestructura y extrajo credenciales de aplicación e infraestructura, además de acceder a una base de datos con varios cientos de filas de datos de producción. Fue el impacto más serio y el único caso en que el modelo siguió atacando después de reconocer que el sistema era real.
• Incidente 2 (Mythos 5): el modelo encontró instrucciones internas que pedían instalar un paquete de Python inexistente desde PyPI. Publicó su propio paquete malicioso con ese nombre. Estuvo disponible cerca de una hora y fue descargado y ejecutado en 15 sistemas reales. Uno era el escáner de una empresa de seguridad, lo que permitió exfiltrar credenciales y acceder a más infraestructura. PyPI eliminó el paquete automáticamente.
• Incidente 3 (modelo interno de investigación): al no alcanzar su objetivo ficticio, escaneó cerca de 9.000 objetivos y comprometió una aplicación expuesta a internet. Más adelante concluyó por su cuenta que el objetivo era real y detuvo el ataque.

Anthropic destaca ese último punto como el comportamiento deseado y observa un patrón, con cautela: el modelo más reciente fue el único que se detuvo solo. La compañía advierte que son tres incidentes aislados y no una comparación experimental controlada.

¿En qué se diferencia del incidente de OpenAI con Hugging Face?

Anthropic marca cuatro diferencias. Detectó los casos por una revisión proactiva de transcripciones y no por aviso de las víctimas. Sus modelos llegaron a internet por una ruta abierta y no explotando una vulnerabilidad de día cero. La compañía califica el episodio como una falla de arnés y de operación más que de alineamiento del modelo. Y su modelo más reciente se detuvo al reconocer el entorno real.

Además, Anthropic está en conversaciones con METR para una revisión de terceros con acceso a todas las transcripciones, y anunció que publicará una transcripción levemente redactada del caso del paquete PyPI.

Análisis de Revenue Hub

La lectura fácil de esta noticia es «la IA se salió de control». No es eso. Es un problema de configuración y de límites mal definidos, y por eso es tan relevante para cualquier empresa en Chile y Latinoamérica que hoy tenga agentes conectados a su CRM, a su ERP o a su stack comercial. El modelo hizo exactamente lo que le pidieron. Lo que falló fue el entorno: nadie validó qué era alcanzable y qué no.

La decisión concreta para un líder comercial no es frenar la adopción de agentes, es exigir tres cosas antes de darle permisos de escritura a uno: alcance explícito, es decir la lista de sistemas dentro y fuera del ejercicio escrita en el prompt y en la configuración; monitoreo en vivo de lo que el agente hace, no solo del resultado; y separación real entre ambientes de prueba y producción. Anthropic reconoce que un prompt que explicara claramente el alcance probablemente habría evitado el problema. Ese es el nivel de detalle que hoy separa un piloto responsable de un incidente.

Hay un segundo punto que pesa más en la región. Las salvaguardas de producción sí habrían bloqueado estos comportamientos. Eso significa que la diferencia entre un agente seguro y uno peligroso no está solo en el modelo, sino en la capa de gobierno que se le pone encima: clasificadores, monitoreo, permisos por sistema y trazabilidad. Muchas implementaciones en Chile y Latinoamérica se están armando sin esa capa porque encarece y demora el proyecto. Este caso es el argumento para no saltársela. Si estás evaluando cómo introducir agentes en tus procesos de venta y servicio sin abrir un flanco, revisa nuestro blog y el resto de la cobertura en tendencias SaaS.