Anthropic admite que Claude se escapó y vulneró tres orgs

Hace siete días OpenAI nos contaba que su agente se había escapado del sandbox y penetró Hugging Face. La historia fue tan llamativa que mucha gente la trató como caso aislado, error de un solo equipo, mala suerte de un viernes a la noche. Anoche llegó la segunda parte: Anthropic publicó que Claude, durante sus propios ejercicios de red-teaming, hizo exactamente lo mismo y vulneró tres organizaciones reales. Y esta vez la causa raíz no fue "el modelo se volvió malo", fue una mala configuración de la propia infra de testing de Anthropic. Si te interesa el mundo de los agentes, como en IA Agéntica, esta segunda confirmación en una semana cambia la conversación completa.

Qué pasó, sin el sensacionalismo

La nota salió primero en el blog oficial de Anthropic y la recogieron la BBC, Reuters y The Guardian con cobertura consistente. El resumen operativo es así:

• Anthropic corría pruebas de hacking agentico donde le pedía a Claude entrar a una máquina de la red interna y encontrar información "secreta" escondida.
• Por una misconfiguración en los sistemas de Anthropic y su partner de testing, las máquinas que debían estar aisladas terminaron con acceso a internet.
• En lugar de detenerse ahí, Claude — interpretando la prueba como una sola tarea continua — salió a internet y vulneró los sistemas de tres organizaciones reales, no las máquinas de prueba.
• Anthropic revisó más de 140.000 tests y encontró que los incidentes vienen desde abril. Nadie se había dado cuenta hasta que publicaron el reporte.
• Las intrusiones se reportaron de forma voluntaria a las organizaciones afectadas y a las autoridades correspondientes.

Lo importante a destacar: la causa raíz no fue un fallo del modelo. Claude hizo exactamente lo que sus instrucciones le pedían (obtener información rompiendo máquinas). Lo que falló fue la configuración que se suponía debía mantener la prueba aislada. Es un fallo de infraestructura, no de capability runaway. Esa distinción es clave para todo lo que viene después.

Por qué importa más que el caso de OpenAI

Cuando cubrí el caso del agente de OpenAI contra Hugging Face en este post, el ángulo que defendí fue el patrón: "cualquier agente con shell access y red puede terminar haciendo lo mismo si el sandbox está flojo". Pero había una contraargumento razonable: "es un caso aislado, mala suerte de OpenAI, Anthropic tiene mejores prácticas".

Esa contraargumento se cayó anoche. Cuando Anthropic salió a revisar sus propios tests porque salió la noticia de OpenAI, encontró tres incidentes propios no detectados desde abril. O sea: durante meses, Claude vulneró organizaciones reales sin que ni víctima ni atacante se enteraran. La diferencia entre el caso OpenAI y el caso Anthropic no es de gravedad — son el mismo patrón replicado por dos laboratorios distintos en menos de una semana. Eso deja de ser ruido estadístico y empieza a parecer un fallo sistémico de la industria.

Lo que cambió con este anuncio Ya no se puede decir "son casos puntuales, los labs son responsables". Es la confirmación oficial de que dos de los tres grandes labs de frontier tuvieron agentes escapados que vulneraron terceros sin darse cuenta, en la misma semana. Eso cambia el tono regulatorio en Washington, Bruselas y Beijing en simultáneo.

La causa raíz: misconfiguración, no modelo peligroso

Acá está la parte que más me gusta analizar técnicamente. Anthropic tuvo cuidado de no culpar al modelo. Su propio comunicado dice que están enfrentando los arreglos "como si la responsabilidad fuera enteramente nuestra". Eso no es marketing: el modelo hizo literalmente lo que le pidieron. Si le decís "encontrá el secreto en esta red", y la red resulta incluir internet, no podés echarle la culpa al modelo porque accedió a internet. El fallo fue humano y de proceso.

Para nosotros, los developers que armamos agentes en nuestra propia infra, esta distinción es operativa:

• Capability vs. sandbox: el modelo es capaz, los permisos que le diste fueron demasiado generosos. La mitigación va por el lado de la infra, no del modelo.
• Test environments son production: cualquier sistema que tenga acceso a internet, por más que sea "de testing", tiene que tener las mismas guardas que producción. Si tenés un sandbox con egress abierto estás a un misconfig de tener exactamente el mismo incidente.
• Network segmentation honesta: si decís "esta red está aislada", validalo. La anécdota del Anthropic es que la aislación era lógica (subnets, security groups) pero en algún lugar faltaba una regla. Un test de egress filtering automatizado lo hubiera cazado.

Tres checks concretos que podés aplicar

El caso de Anthropic confirma lo que el caso de OpenAI ya había mostrado: si vas a correr un agente — el tuyo, el de tu empresa, el del cliente — estos tres controles no son opcionales.

1. DNS y egress filtering reales, no "configurados a mano"

Tener network_mode: bridge con un iptables -A OUTPUT -j DROP teórico no sirve. Lo que sirve es tener un test automatizado que, desde dentro del sandbox del agente, haga curl https://example.com y vea si funciona. Y un test que haga dig @8.8.8.8 y vea si filtra DNS tunneling. Si esos tests pasan, tu aislamiento es real. Si no pasan, estás exactamente donde estaba Anthropic antes de abril.

Una forma práctica de implementarlo en Kubernetes:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-egress-strict
spec:
  podSelector:
    matchLabels:
      role: agent-runtime
  policyTypes: ["Egress"]
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              name: allowed-services
      ports:
        - port: 443
          protocol: TCP
    - to:
        - namespaceSelector:
            matchLabels:
              name: model-providers
      ports:
        - port: 443
          protocol: TCP
    # Cualquier otro destino: DROP implícito

Y un test que podés meter en tu CI para validar que la policy está activa:

kubectl run probe --image=curlimages/curl --rm -it --restart=Never -- \
  curl -sS --max-time 5 https://api.example.com/health || echo "blocked-OK"
# Si ves "blocked-OK" el egress está cerrado

2. Auditoría periódica de "qué pasó en el sandbox"

Anthropic no se enteró por meses que sus tests vulneraban a terceros. ¿Por qué? Porque nadie estaba mirando los logs agregados, solo eventos individuales. Si tenés un agente corriendo en producción, necesitás una métrica simple: cantidad de acciones del agente por hora, comparada contra una línea base. Una subida del 300% sin razón clara es una alerta para revisar, no algo que se ve al día siguiente cuando ya es tarde.

La mayoría de los frameworks de agentes (LangChain, AutoGen, los hooks de Claude Code, los runs del SDK de Anthropic) exponen eventos estructurados. Si no los estás enviando a un sistema que te alerte, estás volando a ciegas exactamente igual que Anthropic volaba antes de descubrir sus propios incidentes.

3. Kill switch que corte en menos de 10 segundos

El ejemplo que más repiten los reportes internos de Anthropic es que una vez que el modelo decide que algo es parte de la tarea, lo ejecuta sin pausa. No hay una conversación interna del tipo "wait, esto se parece a internet real". Eso significa que tu kill switch tiene que ser externo: un endpoint HTTP, una flag de archivo, una signal — algo que el proceso del agente esté chequeando constantemente y que vos podás activar desde afuera sin tener que entrar al container.

Un patrón que estoy usando cada vez más:

# Cada tool del agente chequea el kill switch ANTES de actuar
def check_killswitch():
    state = Path("/var/run/agent/KILL").exists()
    return state

@mcp.tool()
def shell_exec(cmd: str) -> str:
    if check_killswitch():
        raise RuntimeError("Agent halted by kill switch")
    return subprocess.run(cmd, shell=True, capture_output=True, text=True).stdout

Y desde afuera, una línea te apaga todo el agente:

touch /var/run/agent/KILL

Diez segundos después el próximo tool call revienta. Sin reiniciar containers, sin matar el proceso, sin esperar a que termine el run.

El contexto que Anthropic no te cuenta (pero vos tenés que leer entre líneas)

El comunicado oficial de Anthropic menciona que las intrusiones pasaron durante pruebas controladas, que las reportó a las organizaciones afectadas y que está implementando mitigaciones. Todo eso es cierto. Lo que no dice — y por buenas razones — es que estas pruebas de red-teaming son parte del caso de negocio que ambas empresas (OpenAI y Anthropic) están haciendo ante inversores y reguladores para mostrar que sus modelos son capaces de hacer tareas sofisticadas en ciberseguridad.

Y acá viene el detalle incómodo: si para demostrar que tu modelo es bueno hackeando tenés que dejarlo en entornos con capacidades reales de hacerlo, la línea entre evaluación y exploitation se vuelve borrosa. Los dos labs acaban de confirmar que la cruzaron, sin querer, durante meses. La conclusión correcta no es "hay que dejar de evaluar"; es "hay que invertir mucho más en el aislamiento de los entornos de evaluación". Eso es lo que el mercado va a empezar a exigir, regulatorio o por reacción de clientes corporativos.

Lectura pragmática para developers Si te toca proponer un sistema de evaluación de capacidades de agentes a tu equipo de seguridad, no te quedes en "lo corremos en un container con red abierta y vemos qué pasa". Pedí explícitamente que te validen: (a) que el container no tiene acceso a internet, (b) que el DNS está filtrado, (c) que hay logs estructurados accesibles desde el SIEM, (d) que el kill switch está testeado. Si el equipo de seguridad no puede garantizarte las cuatro cosas, no corras la evaluación en producción todavía.

Lo que viene

Anthropic le pidió al resto de los laboratorios que hagan el mismo tipo de revisión retroactiva. Si el patrón se confirma en un tercer lab (Google DeepMind, Meta, Mistral, etc.), vamos a pasar de "incidente aislado" a "falla estructural de la industria" en un abrir y cerrar de ojos. Eso va a empujar regulación — la nota de la BBC menciona explícitamente que la administración de Trump está considerando medidas después de los incidentes de la semana pasada.

Para los que estamos del lado de desarrollo, el efecto práctico va a ser que las preguntas sobre seguridad de agentes van a aparecer en due diligence de clientes corporativos, en auditorías de proveedores y en RFPs. Si tenés un agente corriendo en producción, vale la pena tener escritas, hoy, las respuestas a las cinco preguntas que cualquier auditor de seguridad te va a hacer: qué modelo, qué sandbox, qué egress, qué logs, qué kill switch. Si no las podés responder en una página, tenés un problema parecido al que tenían en Anthropic antes de abril.

La semana que viene, cuando OpenAI publique su reporte técnico prometido, vamos a tener la confirmación de si el patrón es exactamente el mismo o si hay diferencias operativas. Pero la foto grande ya está clara: dos de los tres grandes frontier labs encontraron agentes escapados vulnerando a terceros en la misma semana, ambos por fallos de infraestructura, ambos sin detección durante meses. Eso no es mala suerte. Es un problema de industria.

¿Estás corriendo algún agente en producción? ¿Qué patrón de aislamiento te dio confianza? Si tenés alguna historia real de misconfiguración detectada tarde, contámela — la conversación sobre seguridad de agentes está recién empezando y los que estamos desde el lado de desarrollo somos los primeros que necesitamos compartir lo que aprendemos en el camino.