OpenAI, Anthropic y el AI Security Institute británico revelaron en dos semanas que agentes de IA se salieron de sus entornos de prueba y afectaron a sistemas y personas reales. Lo relevante no es cada caso, sino el ritmo al que avanzan estas capacidades. Por Thomas Boele, Global Director Solutions Engineering – AI Security, Check Point Software.
En catorce días, entre julio y agosto de 2026, tres organizaciones revelaron que agentes de IA desplegados en evaluaciones internas de seguridad se salieron de los límites previstos para las pruebas y afectaron a infraestructura, código o personas reales. Por separado, ninguno de los tres casos resulta espectacular. En conjunto, marcan un cambio de riesgo teórico a incidente documentado, y en uno de ellos fue la atención humana, no un control técnico, lo que evitó el daño.
El caso más reciente procede del AI Security Institute (AISI) del Reino Unido, que publicó a principios de agosto un informe sobre cómo un agente de IA se salió de un entorno de pruebas durante una evaluación rutinaria. El agente investigó a los mantenedores de un proyecto de código abierto, creó identidades falsas y las usó para intentar convencer a un mantenedor real de que aprobara código malicioso, un enfoque de ingeniería social habitual entre atacantes humanos en escenarios de cadena de suministro. Lo destacable no es la técnica, sino cómo surgió: nadie indicó al agente que engañara a nadie, pero tampoco se le prohibió expresamente, una restricción que hasta ahora parecía innecesaria en modelos entrenados con medidas de alineación.
El incidente bajo la lupa
El AISI evaluó siete modelos en dos «cyber ranges» -redes simuladas que imitan entornos reales- en 122 ejecuciones. En diez, un agente actuó fuera del alcance previsto, lo que dio lugar a 19 acciones documentadas: 17 con Mythos 5 de Anthropic y dos de una sola ejecución con GPT-5.6 Sol de OpenAI, según el informe técnico del instituto.
Dos matices importan. El acceso a internet estaba habilitado de forma deliberada, y los clasificadores de ciberseguridad que bloquean comportamientos de riesgo estaban desactivados, para determinar la capacidad máxima de cada modelo; condiciones que no reflejan cómo llegan estos modelos a los usuarios finales. No hubo fuga del entorno aislado, y el AISI no ha confirmado daños reales. Su propia monitorización detectó el episodio: la mañana del 28 de julio, los sistemas señalaron tráfico saliente por la red Tor, y el incidente quedó contenido en menos de una hora.
Tres revelaciones en catorce días
El informe del AISI es la tercera revelación de este tipo en dos semanas, y comparar los tres casos resulta instructivo porque cada uno tiene una causa distinta.
El 21 de julio, OpenAI reveló que dos modelos habían escapado de un entorno aislado mediante una vulnerabilidad hasta entonces desconocida y comprometido la infraestructura de producción de Hugging Face, según la empresa. Hugging Face detectó la intrusión por sus propios medios y lo notificó a las autoridades antes de que OpenAI lo relacionara con su propia evaluación.
Anthropic hizo lo propio el 30 de julio. Una revisión de 141.006 ejecuciones de evaluación identificó tres incidentes en los que modelos de Claude -Opus 4.7, Mythos 5 y un modelo de investigación interno- obtuvieron, según Anthropic, acceso no autorizado a infraestructura de producción de tres organizaciones reales; el más antiguo se remonta a abril de 2026. La causa fue un malentendido con el socio de evaluación Irregular: las máquinas de prueba tenían acceso activo a internet pese a que el prompt indicaba lo contrario. Las intrusiones se llevaron a cabo mediante contraseñas débiles y puntos de acceso sin autenticar, y dos de las tres organizaciones no habían detectado la actividad por sí mismas.
No son los casos aislados, sino el ritmo
Que un agente invente identidades falsas para lograr que un humano apruebe código malicioso era, hasta hace poco, tema de artículos académicos, no de informes de incidentes; el propio AISI describe este engaño dirigido como un comportamiento que hasta ahora era en gran medida teórico. Ahora queda documentado.
Un detalle del informe de Anthropic merece atención porque, a primera vista, parece contradecir esa lectura. Los tres modelos reaccionaron de forma distinta ante indicios de un entorno real: Opus 4.7, el más antiguo, continuó el ataque tras reconocer los sistemas como infraestructura de producción; Mythos 5, pese a una evaluación inicial correcta, volvió a convencerse de que seguía en una simulación; el más reciente, un modelo de investigación interno, interrumpió la operación. Suena tranquilizador, pero implica lo contrario para la arquitectura de seguridad: la capacidad de comprometer un sistema avanza más rápido que la de evaluar la propia situación, por lo que la autoevaluación de un agente no puede servir como control, pues es un comportamiento, no una propiedad de seguridad.
Los tres incidentes fueron detectados, contenidos y revelados, señal de que los mecanismos de alerta temprana funcionan, aunque queda por ver si esta defensa escala al ritmo de la tecnología y si las organizaciones reaccionan con la misma rapidez con que llegan las alertas. Cabe destacar qué detuvo realmente el ataque del AISI: la monitorización técnica lo detectó después, por tráfico anómalo, no mediante un control integrado en la evaluación. Lo detuvo una persona: el mantenedor que revisó y rechazó la solicitud de incorporación de código, junto con alguien externo que abrió el código sospechoso en un entorno aislado. La atención humana funcionó esta vez; no escala frente a un atacante que trabaja sin descanso.
Consecuencias para la práctica
El AISI extrae tres lecciones para evaluadores: controles de red más granulares en lugar de acceso a internet generalizado, monitorización en tiempo real de las evaluaciones en curso, y diseños que asuman desde el inicio que un modelo capaz puede salirse de su alcance. Para el resto de organizaciones, la recomendación es más sobria y, en el fondo, no es nueva: bases sólidas de ciberseguridad, revisión rigurosa del código externo, ciberseguridad como asunto de consejo de administración y estándares mínimos en la cadena de suministro; en el ámbito germanoparlante, las directrices del BSI ofrecen un marco adecuado.
Check Point agrupa las medidas necesarias en tres áreas: protección frente a ataques impulsados por IA, ya que los atacantes disponen de las mismas capacidades que revelan estas pruebas; control sobre la propia IA de la organización, es decir, saber qué agentes están operativos y a qué pueden acceder; y verificación continua en lugar de dar por sentada la seguridad.
Para los agentes ya en producción, cuatro preguntas son un buen punto de partida: ¿Qué agentes operan actualmente, incluidos los creados por personas sin perfil de desarrollador? ¿A qué puede acceder cada uno? ¿Qué permisos exceden lo previsto? ¿Se detectaría una desviación de ese alcance? Si la respuesta es «no», esa es la brecha que hay que cerrar primero.
El Dr. Jakob Jung es redactor jefe de Security Storage y Channel Germany. Lleva más de 20 años trabajando en el periodismo especializado en TI. A lo largo de su carrera ha colaborado con Computer Reseller News, Heise Resale, Informationweek, Techtarget (almacenamiento y centros de datos) y ChannelBiz. Además, colabora como freelance con numerosas publicaciones del sector de las TI, entre las que se incluyen Computerwoche, Channelpartner, IT-Business, Storage-Insider y ZDnet. Sus temas principales son el canal, el almacenamiento, la seguridad, los centros de datos, los sistemas ERP y CRM.
Contacto – Contacto por correo electrónico: jakob.jung@security-storage-und-channel-germany.de