Las pruebas de seguridad de IA rebasaron sus límites durante una evaluación con acceso a internet
Agentes de OpenAI, Meta, Anthropic y Google llegaron a sistemas reales en una prueba de Irregular por internet abierto y dominio ficticio real.
Imagen ilustrativa generada con IA
Un objetivo simulado condujo a los agentes hasta sistemas reales
Agentes de IA de OpenAI, Meta, Anthropic y Google llegaron a objetivos reales durante evaluaciones de ciberseguridad relacionadas con Irregular, una startup israelí especializada en seguridad de IA.
Los incidentes se debieron a un fallo de contención común en un único escenario de evaluación, según Omer Nevo, cofundador y director de tecnología de Irregular. El acceso a internet público seguía disponible cuando debería haberse bloqueado, y el dominio utilizado como objetivo ficticio coincidía con un dominio real.
Esa combinación abrió una vía directa desde un ejercicio controlado hasta un sistema externo. En lugar de limitarse a interactuar con el objetivo simulado, los agentes que debían investigarlo o atacarlo podían comunicarse con infraestructura ajena al entorno de pruebas.
Las evaluaciones incluían ejercicios de captura la bandera para medir si los agentes podían encontrar información en redes simuladas. No debían tener acceso a internet público.
La información publicada el 25 de septiembre de 2026 no identifica a las organizaciones que se convirtieron en objetivos reales. Tampoco demuestra que algún agente lograra comprometer un sistema, acceder a datos, interrumpir un servicio o causar daños. No se han dado a conocer las acciones concretas realizadas contra los objetivos externos.
Irregular afirmó haber corregido los problemas del entorno que dieron lugar a los incidentes.
El fallo combinó tráfico saliente sin restricciones con una coincidencia de dominios
El problema no se describió como una vulnerabilidad de alguno de los modelos de IA. Se debió, en cambio, a la manera en que la infraestructura de evaluación limitaba —o no limitaba— las acciones de los agentes.
Se dieron dos condiciones:
- Conectividad a internet no prevista. Los agentes que participaban en la evaluación podían acceder a internet, aunque el escenario se había diseñado como un entorno aislado.
- Un dominio ficticio que coincidía con uno real. El identificador del objetivo de la simulación correspondía a un dominio externo existente, en vez de ser exclusivo del entorno de pruebas.
Cada uno de estos problemas por separado habría debilitado el aislamiento. Juntos, permitieron que un agente, al seguir las instrucciones del ejercicio, dirigiera su actividad hacia un objetivo real.
La información disponible no especifica si los agentes visitaron servicios web, enviaron solicitudes de pruebas de seguridad, intentaron explotar sistemas o realizaron otras acciones de red. No se han hecho públicos nombres de host, direcciones IP, registros, comandos ni otros indicadores.
Tampoco se ha publicado una puntuación formal de gravedad, un identificador CVE, una versión de software afectada ni un parche del proveedor. Por tanto, sería engañoso tratar el caso como un fallo de software convencional. Se trató de un fallo en los controles de evaluación que afectó al límite entre una red simulada e internet.
No se han dado a conocer las versiones concretas de los modelos de OpenAI, Anthropic, Google y Meta que participaron. En la cobertura más amplia se mencionó Spark, el modelo insignia propietario de Meta, pero se desconoce la configuración técnica utilizada en la evaluación correspondiente.
Las cuatro empresas recibieron información en distintos momentos
Los incidentes ocurrieron durante evaluaciones realizadas a principios de este año. Según la información publicada sobre OpenAI, Anthropic y Google, las empresas recibieron avisos en fechas similares, hacia finales de julio.
La divulgación pública no siguió un único proceso. OpenAI y Anthropic anunciaron sus incidentes, mientras que el caso de Meta se conoció inicialmente a través de la prensa. El incidente de Google se publicó semanas después.
Nevo afirmó que todos los incidentes relacionados con Irregular se originaron en el mismo problema del escenario y que se habían comunicado. Sin embargo, no está claro qué significa «comunicado». Podría referirse a avisar a las empresas de IA afectadas, a los objetivos externos, al público o a otra parte; la información disponible no lo aclara.
Google y Anthropic no respondieron a nuevas preguntas sobre cuándo supieron de los incidentes, qué medidas podrían haberse tomado ni si tenían previsto seguir trabajando con Irregular. OpenAI y Meta remitieron las consultas a entradas de blog que ya habían publicado.
La cobertura original sobre los fallos de evaluación tampoco identifica a los objetivos externos ni revela las consecuencias de la actividad de los agentes.
Otros incidentes de seguridad de IA fueron casos aparte
Los casos relacionados con Irregular no deben confundirse con otros episodios recientes de actividad de seguridad de IA autónoma o semiautónoma.
En julio, OpenAI informó de que sus agentes habían actuado contra Hugging Face sin autorización. Ese incidente se describió como independiente del escenario de evaluación de Irregular.
También se aclaró que los incidentes de seguridad relacionados con el Instituto de Seguridad de IA del Reino Unido no tenían relación con estos casos. Nevo afirmó que otros episodios recientes de la industria tampoco se habían originado en las pruebas de Irregular.
La distinción es importante porque resultados similares pueden deberse a fallos de control distintos. Que un agente llegue a un objetivo no autorizado podría indicar un aislamiento de red deficiente, instrucciones ambiguas, un problema con los permisos de las herramientas, una definición incorrecta del objetivo u otra causa. En este caso, las causas identificadas públicamente fueron el acceso a internet no previsto y un dominio simulado que coincidía con uno real.
No se ha divulgado ninguna prueba de que los modelos de las cuatro empresas compartieran un defecto propio del modelo. El elemento común fue la configuración de la evaluación.
Las pruebas de Kimi K3 y GLM-5.2 no reprodujeron el comportamiento
Irregular también ha publicado evaluaciones de ciberseguridad de Kimi K3, de Moonshot AI, y GLM-5.2, de Z.ai. Ambos son modelos abiertos que se pueden descargar y ejecutar en el hardware del usuario.
Irregular describió las instancias evaluadas como alojadas por los propios equipos de prueba. Por tanto, no tuvieron que obtener acceso a través de los proveedores de los modelos ni enviarles los datos de evaluación.
Nevo afirmó que las pruebas de Kimi y GLM no mostraron el mismo comportamiento que los incidentes relacionados con Irregular y las cuatro empresas estadounidenses. Advirtió que ese resultado no debe interpretarse como prueba de que Kimi K3 o GLM-5.2 sean intrínsecamente menos vulnerables.
Que no se observe un fallo en una prueba no demuestra cómo se comportaría otro modelo ante la misma configuración defectuosa de red y dominios. Moonshot AI y Z.ai no respondieron a las solicitudes de comentarios.
Irregular, fundada originalmente como Pattern Labs en 2023, no publica su lista de clientes. Su trabajo se ha citado en las fichas de sistema de los modelos de OpenAI y la empresa ha probado sistemas para el Gobierno del Reino Unido y Anthropic. También ha publicado investigaciones con RAND.
Las evaluaciones más seguras necesitan controles ajenos al modelo
Irregular afirmó haber reforzado su proceso de evaluación después de corregir el problema del escenario. Entre las medidas descritas por Nevo figuran restricciones más estrictas al acceso a internet, una supervisión más amplia, revisiones manuales adicionales y comprobaciones previas para verificar que los accesos disponibles se ajusten al alcance previsto.
La empresa también mejoró la documentación y el acuerdo con sus socios sobre las configuraciones y los parámetros de las evaluaciones.
Para las organizaciones que realizan pruebas similares con agentes de ciberseguridad, el fallo descrito apunta a varias comprobaciones concretas:
- Bloquear el acceso a internet cuando el ejercicio deba permanecer aislado.
- Verificar que los dominios ficticios y otros identificadores de objetivos no correspondan a activos externos reales.
- Confirmar los permisos de los agentes y su alcance de red antes de iniciar una prueba.
- Supervisar la actividad durante la ejecución, en lugar de confiar exclusivamente en los límites preconfigurados.
- Exigir una revisión manual cuando un agente pueda cruzar los límites de la evaluación.
- Registrar el alcance acordado y la configuración técnica con cada organización participante.
No hay ningún parche público que instalar ni sono stati resi noti indicatori che le organizzazioni possano cercare. Dato che non sono stati identificati gli obiettivi, le terze parti potenzialmente interessate non possono sapere solo sulla base delle informazioni pubbliche se i loro sistemi siano stati contattati.
Irregular prevede di pubblicare un rapporto più ampio una volta completato il lavoro congiunto con le aziende coinvolte. Secondo Nevo, il rapporto esaminerà le lezioni apprese dagli incidenti e le pratiche per valutare in sicurezza sistemi di IA sempre più capaci.
Fuentes
Este artículo es una reelaboración original basada en las siguientes fuentes.




