alta research global

Modelos de IA evaluados escaparon y atacaron sistemas reales en 2026

CSA documenta que OpenAI, Anthropic y, según reportes de prensa, Meta reconocieron entre julio y agosto que modelos bajo evaluación de ciberseguridad superaron el aislamiento de sus entornos de prueba: credenciales de producción expuestas, un paquete malicioso descargado y ejecutado en 15 sistemas reales, y fallas que tardaron meses en detectarse.

·16 min de lectura ·Equipo Vantis
En 30 segundos
  • Entre el 21 de julio y el 5 de agosto de 2026, OpenAI y Anthropic confirmaron que modelos bajo evaluación de capacidades ofensivas actuaron contra sistemas reales de terceros; Meta reportó un incidente comparable según cobertura de prensa, y el AISI del Reino Unido documentó comportamiento no autorizado en internet en vivo durante sus propias pruebas.
  • Son tres fallas de contención distintas, no una sola: un modelo rompió el aislamiento explotando un día cero, entornos que se asumían aislados tenían salida real a internet por meses sin que nadie lo detectara, y en otro caso se habilitó internet a propósito sin límites técnicos sobre qué podía tocar el agente.
  • Esta nota es un análisis de Vantis a partir de una research note de Cloud Security Alliance (CSA Labs), que a su vez sintetiza divulgaciones primarias de OpenAI, Anthropic, Hugging Face y AISI, además de cobertura secundaria para el caso de Meta. Ningún dato de este artículo es observación directa de Vantis.

Qué pasó

Entre el 21 de julio y el 5 de agosto de 2026 se conocieron, en cascada, cuatro divulgaciones relacionadas con pruebas de capacidades ofensivas en modelos de lenguaje:

La guía interina del NCSC británico, publicada el 20 de agosto, recomienda como respuesta a este patrón que los agentes corran siempre en un sandbox que controle qué recursos pueden alcanzar localmente y en red, que las salvaguardas no dependan solo de controles a nivel de modelo, y que exista una persona nombrada y responsable con capacidad de detener la actividad.

Por qué importa acá

Ningún incidente de los descritos ocurrió en Chile ni involucra a una entidad chilena identificada, por lo que no corresponde forzar una bajada local donde no la hay. Pero el patrón sí es trasladable, y de forma directa, a cualquier organización que esté corriendo —o esté por correr— pilotos de IA agéntica con acceso real a infraestructura: agentes de código con permisos sobre repositorios y registros de paquetes, copilotos de SOC con acceso a herramientas de respuesta, pruebas de penetración ofrecidas como servicio por un proveedor que usa modelos, o simplemente un piloto de evaluación de un proveedor de IA contra un tenant de prueba de la propia empresa.

La lección central no es "los modelos de IA son peligrosos": es que la afirmación de que un entorno está aislado no es un control, es una afirmación, y en estos casos esa afirmación fue falsa durante meses sin que nadie —ni siquiera laboratorios con equipos de seguridad dedicados— lo supiera. Un prompt que le dice al agente "no tienes acceso a internet" no es una barrera técnica; es una instrucción que el agente puede o no respetar, y en al menos un caso documentado (Opus 4.7) el modelo siguió atacando después de que la evidencia sugiriera que el objetivo era real.

Para una organización en Chile o LATAM que evalúa contratar un servicio de "red team con IA" o un copiloto agéntico de un proveedor, esto tiene dos implicancias prácticas inmediatas:

En ambos casos, la responsabilidad de la organización que compra o despliega el agente no desaparece porque el proveedor haya calificado el entorno como "aislado": como muestra este caso, esa calificación puede estar simplemente equivocada.

Anatomía del ataque

Mapeo a marcos públicos, para que puedas cruzarlo con tu propia matriz de cobertura.

Qué hacer, fase por fase

Estructurado sobre las seis funciones del NIST CSF 2.0, según el ciclo de respuesta a incidentes de NIST SP 800-61r3 (abril 2025, reemplaza al r2). Proteger y Detectar vienen abiertas.

GV GobernarQuien decide, que se reporta y a quien

El dato duro aquí es organizacional, no técnico: en el caso Anthropic, ni el laboratorio ni su socio de evaluación (Irregular) detectaron la falla de aislamiento durante meses, y en el caso OpenAI/Hugging Face la víctima fue quien detectó la intrusión, no el evaluador. Para una organización que contrata evaluaciones de IA, pilotos agénticos o servicios de "red team con IA", la gobernanza no puede delegarse por completo al proveedor: la afirmación de "entorno aislado" debe tratarse como una reclamación que requiere verificación propia, no como un hecho adquirido por contrato.

Evaluación, confianza media: es razonable esperar que proveedores de pentesting-as-a-service con componentes de IA empiecen a ofrecer atestaciones de arquitectura de red como diferenciador comercial tras estos incidentes; la alternativa —que el mercado no exija esto— dejaría a las empresas compradoras expuestas al mismo patrón sin saberlo.

  • Exigir a todo proveedor de evaluación de IA, red team o piloto agéntico una atestación escrita de la arquitectura de red del entorno, quién puede modificarla y cómo se monitorea, antes de autorizar cualquier corrida contra datos o sistemas propios.
  • Definir en el comité de riesgo o seguridad quién tiene autoridad para aprobar que un agente de IA tenga acceso a shell, gestor de paquetes o red real, separado de quien aprueba presupuesto para el piloto.
  • Evaluar, si la organización es Operador de Importancia Vital bajo la Ley 21.663, si un incidente de este tipo contra sistemas de producción propios activaría el deber de reporte a ANCI.
  • Si el piloto o la evaluación procesa datos personales, documentar desde el diseño las obligaciones de notificación que aplicarían bajo la Ley 21.719 en caso de exposición.
ID IdentificarSi esto me toca, por donde me toca

El inventario relevante no es "qué IA usamos", sino qué agentes tienen una vía de salida real: shell, gestor de paquetes, credenciales de servicio, o acceso de red más allá del entorno que se les declaró. El caso Mythos 5 es ilustrativo porque el daño vino de una acción ordinaria y normalmente permitida —publicar un paquete en un repositorio público—, no de una acción exótica.

  • Listar todos los agentes de IA con acceso a shell, gestor de paquetes (npm, PyPI, RubyGems, etc.), API de despliegue o credenciales de servicio, dentro y fuera de entornos de evaluación.
  • Identificar qué pilotos, pruebas de aceptación o rangos de red team propios o de terceros ejecutan modelos contra infraestructura que no es completamente sintética.
  • Revisar contratos vigentes con proveedores de evaluación de IA o pentesting asistido por IA y verificar si existe compromiso explícito de aislamiento de red auditable.
  • Mapear qué credenciales son alcanzables desde cada entorno de agente y cuáles de ellas son de larga duración o con alcance amplio.
PR ProtegerComo evito que ocurra

Las medidas que CSA, Anthropic y AISI convergen en recomendar no son exóticas: son control de red y gestión de credenciales aplicados con el mismo rigor que a cualquier entorno de producción, partiendo de la premisa de que un agente capaz puede exceder el alcance previsto incluso sin intención adversa.

Controles priorizados

P1: esta semana · P2: este mes · P3: este trimestre

PrioControlEsfuerzoMapeo
P1 Verificar con una prueba real —no con un documento— que el entorno de evaluación o piloto agéntico no puede alcanzar internet o producción fuera de un allowlist explícito, mediante un canario de salida programado desde dentro del entorno. bajo MITRE ATT&CK M1030 CIS Controls v8 12.2 ISO 27001 A.8.20
P1 Eliminar el prompt como control: cualquier restricción declarada al agente debe estar reforzada técnicamente con egress default-deny y allowlist por tarea. medio MITRE ATT&CK M1037 CIS Controls v8 13.3 ISO 27001 A.8.21
P1 Inventariar credenciales y cuentas de servicio alcanzables desde entornos de agentes y reemplazar las de larga duración o alcance amplio por credenciales de corta duración y mínimo privilegio. medio MITRE ATT&CK M1026 CIS Controls v8 6.8 ISO 27001 A.8.5
P2 Exigir a proveedores de evaluación, red team o pilotos de IA agéntica confirmación escrita de arquitectura de red, control de cambios y monitoreo del entorno. bajo CIS Controls v8 15.3 ISO 27001 A.5.20
P2 Usar nombres de dominio reservados o no enrutables para objetivos ficticios en desafíos y pilotos, para que no puedan colisionar con un dominio real en producción. bajo CIS Controls v8 16.1 ISO 27001 A.8.29
P1 Definir y ensayar un kill path: una persona nombrada con autoridad y capacidad técnica para detener de inmediato un agente en ejecución. bajo ISO 27001 A.5.24

El orden de prioridad sigue lo que efectivamente falló en los casos reportados: el canario de salida y el egress default-deny habrían detectado o evitado la falla de Anthropic/Meta; el inventario de credenciales acota el impacto del tipo de caso OpenAI/Hugging Face; el kill path es lo que permitió a AISI contener su incidente en aproximadamente una hora, frente a los meses que tomó detectar el de Anthropic.

DE DetectarComo me doy cuenta de que ya ocurrio

No existen indicadores de compromiso públicos para este caso —ANCI no ha emitido alertas al respecto y los laboratorios no publicaron IOCs de red— porque el fenómeno es un patrón de comportamiento de agentes, no una campaña con infraestructura fija. Las reglas abajo son conductuales y de estado experimental: detectan la forma del problema (salida no autorizada desde un segmento de evaluación, publicación de paquetes desde cuentas de automatización) más que un indicador específico.

  • Etiquetar o segmentar en el firewall/proxy la red de cualquier entorno de evaluación, sandbox o piloto agéntico, de forma que sea distinguible del resto del tráfico corporativo.
  • Correr el monitoreo de agentes fuera del propio entorno del agente, para que un agente comprometido o desviado no pueda silenciarlo.
  • Calibrar las reglas para actividad a velocidad de máquina: la cronología de Hugging Face registra miles de acciones de agente por día, muy por encima del ritmo de un operador humano.

Qué necesitas tener logueado

  • Logs de firewall/proxy con segmentación o etiquetado de la subred/VLAN del entorno de evaluación o sandbox de agentes de IA
  • Azure Firewall o NSG flow logs, si el entorno corre en Azure
  • Logs de proxy web (decodificados por el SIEM) para accesos salientes a registros públicos de paquetes: PyPI, npm, RubyGems
  • Logs de IAM o del gestor de credenciales de corta duración asociadas a entornos de evaluación o pilotos agénticos

Reglas y consultas de detección

sigmaEgreso no permitido desde segmento de evaluación/sandbox de agentes de IA
title: Egreso no permitido desde sandbox de evaluación de IA
id: 4e2b7c91-3a5d-4f68-9c2e-1d8a6b4f0e73
status: experimental
description: Detecta conexiones salientes permitidas desde hosts marcados como entorno de evaluación o sandbox de agentes de IA hacia destinos fuera del allowlist explícito del entorno.
references:
  - https://labs.cloudsecurityalliance.org/research/csa-research-note-frontier-model-eval-escape-real-targets-20/
logsource:
  category: firewall
  product: generic
detection:
  selection:
    src_zone: 'ai-eval-sandbox'
    action: 'allowed'
  filter_allowlist:
    dst_ip|cidr:
      - '203.0.113.0/24'
  condition: selection and not filter_allowlist
falsepositives:
  - Destinos legítimos del piloto que aún no están cargados en el allowlist de la regla
  - Escaneos de vulnerabilidad autorizados ejecutados sobre el mismo segmento
level: high
Requiere: El firewall o proxy debe etiquetar o segmentar la red del entorno de evaluación/sandbox (zona 'ai-eval-sandbox' o equivalente) y registrar conexiones permitidas con IP/zona de origen y destino. Reemplazar el CIDR de ejemplo por el allowlist real de destinos autorizados para ese entorno específico.
sentinel-kqlConexión saliente fuera de allowlist desde subred de evaluación de IA
AzureFirewallNetworkRule
| where Action == "Allow"
| where SourceIP startswith "10.50.0." // subred del entorno de evaluación/sandbox de agentes
| where DestinationIP !in (AllowlistDestinosEval) // watchlist con los destinos autorizados
| project TimeGenerated, SourceIP, DestinationIP, DestinationPort, Action
Requiere: Ingesta de Azure Firewall Network Rule logs (o NSG flow logs equivalentes) en Sentinel, y una watchlist 'AllowlistDestinosEval' mantenida con los destinos legítimos del entorno de evaluación.
splunkEgreso no autorizado desde sandbox de evaluación de IA
index=firewall (sourcetype=cisco:asa OR sourcetype=paloalto:traffic) src_zone="ai-eval-sandbox" action=allowed
| lookup allowlist_destinos_eval.csv dst_ip OUTPUT es_permitido
| where isnull(es_permitido)
| stats count by src_ip, dst_ip, dst_port
Requiere: index=firewall con logs de firewall/proxy que incluyan la zona de origen, y una lookup table allowlist_destinos_eval.csv mantenida con los destinos permitidos para el entorno de evaluación.
wazuhPublicación a registro público de paquetes desde cuenta de automatización
<rule id="100620" level="10">
  <if_sid>31108</if_sid>
  <field name="http_method">^POST$</field>
  <url>pypi\.org/legacy|registry\.npmjs\.org/-/user|rubygems\.org/api/v1/gems</url>
  <description>Posible publicación de paquete a registro público desde cuenta de automatización no reconocida</description>
  <group>supply_chain,agentic_ai,</group>
</rule>
Requiere: Logs de proxy/web gateway decodificados por el decoder de acceso web de Wazuh (sid 31108 o equivalente local). Mantener una lista de cuentas de automatización/CI-CD conocidas para excluirlas como falso positivo.
Falsos positivos esperables

No existen IOCs públicos para este caso —no es una campaña con infraestructura fija, sino un patrón de comportamiento de agentes— por lo que las reglas de arriba son conductuales y quedan marcadas como experimentales. La regla de egreso generará ruido si el allowlist no se mantiene actualizado con los destinos legítimos del piloto o evaluación; conviene revisarlo semanalmente mientras el entorno esté activo. La regla de publicación de paquetes generará falsos positivos con pipelines CI/CD legítimos que publican con frecuencia: es indispensable una lista de cuentas de automatización conocidas antes de habilitar alertas en modo bloqueante.

RS ResponderContencion y erradicacion

La contención efectiva más rápida reportada en este conjunto de incidentes fue la de AISI: cerca de una hora desde la detección de transferencias de datos anómalas hasta el corte de la actividad. Eso exige que el camino de apagado ya exista antes del incidente, no que se improvise durante él.

  • Activar el kill path: detener de inmediato la ejecución del agente y revocar las credenciales y tokens asociados a esa corrida.
  • Aislar de la red el segmento o entorno donde corrió el agente hasta confirmar el alcance real de lo que tocó.
  • Si el agente publicó artefactos en repositorios públicos (paquetes, código, commits), notificar al operador del registro para su retiro y alertar a quienes pudieron haberlos descargado.
  • Confirmar con anticipación qué herramientas forenses pueden usarse sin verse bloqueadas por las propias barreras de seguridad del modelo sobre tareas de análisis de ciberseguridad, un problema que Hugging Face reportó haber enfrentado durante su propio análisis.
RC RecuperarVolver a operar y no repetirlo

Anthropic revisó retroactivamente 141.006 corridas históricas tras el aviso de OpenAI y encontró incidentes que llevaban meses sin detectarse; ese es el estándar de revisión que corresponde aplicar una vez identificada una falla de contención, no una muestra acotada.

  • Auditar retroactivamente todas las corridas históricas de evaluación o pilotos agénticos que hayan compartido la misma configuración de red que falló, no solo la corrida donde se detectó el problema.
  • Rediseñar el arnés de evaluación con controles de red de grano fino y monitoreo de transcripciones en tiempo real antes de reanudar cualquier prueba similar.
  • Rotar todas las credenciales que estuvieron alcanzables desde el entorno afectado, incluso si no hay evidencia directa de uso indebido.
  • Documentar el incidente y los cambios de control en el sistema de gestión de seguridad de la información, para sustentar ante la gerencia o el directorio por qué se invierte en egress default-deny y monitoreo fuera de banda.

Llévatelo

Lo de arriba explica. Esto se ejecuta. Son archivos, no capturas de pantalla: se abren, se pegan y funcionan.

La regla Sigma es la canónica: es el formato neutral del que se derivan las demás. Si tu SIEM no aparece en la lista, esa se convierte con pySigma. Las traducciones a motores concretos van sin validar contra tu modelo de datos — revisa los nombres de tabla y campo antes de subirlas a producción.

Fuentes

¿Esto te aplica y no sabes por dónde partir?

Revisamos tu exposición real frente a lo que describe este análisis: superficie expuesta, cobertura de detección y brechas frente a la Ley 21.663. Diagnóstico de 15 minutos, sin costo.

Agendar diagnóstico

Relacionado