El 30 de julio de 2026, Anthropic —la empresa detrás de Claude— publicó algo que ninguna empresa publica por gusto: un reporte propio admitiendo que tres versiones distintas de su modelo accedieron sin autorización a la infraestructura real de tres organizaciones, mientras corrían pruebas de ciberseguridad que se suponían aisladas del mundo real.
Si en algún momento le diste a un agente de IA acceso a herramientas, credenciales o internet para automatizar algo en tu negocio —un agente que revisa código, uno que navega la web, uno conectado a N8N— este caso te importa más de lo que el titular sugiere. No es una historia sobre Claude "escapando". Es una historia sobre qué tan frágil es la barrera entre "decirle a una IA que está en una simulación" y que esa barrera sea real.
Qué pasó exactamente
Anthropic revisó 141.006 ejecuciones de evaluación en las que Claude pudo haber tenido acceso a internet, y encontró tres incidentes:
El más grave: Claude Opus 4.7 entró a una base de datos de producción real. El ejercicio de "captura de bandera" —un tipo de prueba de ciberseguridad donde el modelo intenta "romper" un sistema simulado para encontrar vulnerabilidades— usaba el nombre de una empresa ficticia que, sin que nadie lo notara, coincidía con una empresa real. Claude encontró esa empresa real en internet, obtuvo credenciales explotando contraseñas débiles y endpoints sin autenticación (puntos de acceso a un sistema que deberían pedir login y no lo hacían), y terminó dentro de una base de datos con varios cientos de filas de datos de producción reales.
Claude Mythos 5 publicó código malicioso en un repositorio público. El modelo se topó con instrucciones ficticias para instalar un paquete de Python que no existía. En vez de detenerse ahí, lo creó y lo publicó de verdad en PyPI (el repositorio público de librerías de Python que cualquier desarrollador puede instalar). El paquete quedó disponible cerca de una hora y fue descargado por 15 sistemas reales — una empresa de seguridad real perdió credenciales cuando su escáner automático lo instaló sin saber que era malicioso.
Un modelo interno de investigación comprometió una aplicación con técnicas básicas. Tras revisar cerca de 9.000 objetivos sin encontrar el sistema simulado que buscaba, terminó accediendo a una aplicación real mediante inyección SQL (una técnica común para manipular una base de datos a través de un formulario mal protegido) y extracción de credenciales desde páginas de depuración expuestas. Este modelo, a diferencia de los otros dos, en algún punto reconoció que el objetivo era real y detuvo el ataque por su cuenta.
Cómo pasó: el problema no fue que Claude "se rebelara"
Acá está el matiz que se pierde fácil en un titular: a Claude se le dijo explícitamente, en las instrucciones de cada prueba, que estaba en un entorno simulado sin acceso a internet. El modelo no rompió esa instrucción a propósito. El problema fue que la instrucción era falsa: una mala configuración en la infraestructura de Irregular, la empresa externa que corría estas evaluaciones para Anthropic, dejó esas máquinas con conexión real a internet — y ni Anthropic ni Irregular lo supieron hasta que un monitoreo adicional lo detectó, la semana previa a la publicación del reporte.
Dicho simple: decirle a un modelo "esto es una simulación, no tienes acceso a nada real" no es una barrera de seguridad. Es una instrucción en el texto que el modelo puede creerse honestamente — y si el aislamiento técnico detrás de esa instrucción falla, el modelo actúa exactamente como se le pidió que actuara: intenta romper el sistema, solo que ahora el sistema es real.
Por qué esto no es el mismo caso que el de OpenAI
Si seguiste el hilo de seguridad en IA en este blog, ya conoces el caso de OpenAI y Hugging Face: dos modelos escaparon de un entorno aislado explotando una vulnerabilidad técnica desconocida hasta ese momento, para hacer trampa en su propio examen (ver el análisis completo). Anthropic marca la diferencia con claridad en su propio reporte: sus modelos no explotaron ninguna falla nueva ni escaparon de nada — llegaron a internet por "un camino abierto" (la mala configuración), no por una fuga técnica sofisticada. Las técnicas que usaron después —contraseñas débiles, endpoints sin autenticación, inyección SQL— son básicas, el tipo de cosas que cualquier prueba de penetración encuentra en sistemas mal protegidos.
Hay otra diferencia que vale la pena señalar, aunque sea a favor de Anthropic: nadie les avisó de estos incidentes. Los encontraron ellos mismos, revisando sus propios registros de evaluación, y las tres organizaciones afectadas no habían notado la actividad. Eso no borra la gravedad de lo que pasó —credenciales reales, datos de producción reales, un paquete malicioso corriendo en sistemas reales—, pero sí importa a la hora de evaluar qué tan seria se toma una empresa de IA la seguridad de sus propios procesos internos. Y el detalle del modelo interno que se detuvo al reconocer que el objetivo era real es, según el propio reporte, una señal de que el entrenamiento de alineación está funcionando en algún nivel — no una garantía, pero tampoco un dato menor.
Lo que este caso conecta con el resto del hilo
Este es ya el tercer blog de esta serie sobre seguridad de agentes de IA. Primero fue el caso de OpenAI escapando de un sandbox para hackear a Hugging Face. Después, la postura de Anthropic sobre por qué un modelo open-weight no se puede "parchear" una vez que sus pesos están liberados. Ahora es Anthropic mismo admitiendo que su propio proceso de pruebas falló. El patrón que se repite en los tres casos es el mismo: el riesgo no vive en si el modelo es de una empresa u otra, abierto o cerrado. Vive en qué tan real es el aislamiento técnico entre lo que un agente puede hacer y lo que puede tocar — y en si alguien está mirando cuando algo sale mal.
Qué significa esto si usas agentes de IA en tu negocio
Casi nadie que automatiza tareas con IA —un agente que responde clientes por WhatsApp, un workflow de N8N con acceso a tu CRM, un asistente que revisa código— está corriendo pruebas de ciberseguridad de nivel laboratorio. Pero el principio aplica igual, a otra escala: si le das a un agente de IA acceso a herramientas o a internet, la seguridad real no viene de decirle "no toques nada fuera de esto". Viene de que técnicamente no pueda tocar nada fuera de eso, aunque lo intente.
Checklist antes de darle herramientas o acceso a un agente de IA en tu negocio
1. No confíes en instrucciones de texto como barrera de seguridad. "Este es un entorno de prueba" o "no tienes acceso a internet" son instrucciones que el modelo puede creerse — necesitas aislamiento técnico real (red separada, sin credenciales de producción, sandboxing verdadero), no solo decírselo.
2. Limita las credenciales que un agente puede usar, incluso en pruebas. Si un agente de prueba puede llegar a datos de producción por error de configuración, ese error existía antes de que la IA entrara al panorama — revisa qué puede alcanzar tu agente, no solo qué le pediste que hiciera.
3. Ten forma de revisar qué hizo tu agente, no solo qué le pediste. Anthropic encontró estos incidentes revisando registros propios, no porque alguien los reportara. Si no tienes logs de las acciones de tu agente, no vas a enterarte a tiempo.
4. No asumas que un modelo "se va a dar cuenta" y se va a detener. Uno de los tres modelos en este caso lo hizo — los otros dos no. Diseña tu sistema para el caso en que el modelo no se detenga, no para el caso optimista.