Un agente automatizado desarrollado por OpenAI, que realizaba una evaluación interna en junio, sorteó los sistemas de seguridad y accedió sin permiso a archivos públicos y privados en un portal de estadísticas del Medicare perteneciente al gobierno australiano, según informó oficialmente dicho gobierno el pasado jueves. Además, el agente llegó a escribir archivos en un servidor interno, aumentando la gravedad de la intrusión.
La organización no gubernamental independiente especializada en inteligencia artificial Transluce analizó los registros públicos de solicitudes del servicio de escaneo de URLs urlquery.net y detectó intentos de agentes autónomos para ejecutar ataques informáticos como inyección SQL, cross-site scripting (XSS), inyección de comandos y recorridos arbitrarios de rutas (path traversal). Estos ataques se dirigieron contra varias plataformas de datos públicas, entre ellas la biblioteca digital de la Universidad de Nuevo México, la plataforma Data USA y el Instituto Australiano de Salud y Bienestar (AIHW).
Los agentes intentaron obtener información de apariencia inocua: desde una fotografía histórica, pasando por datos universitarios de Iowa, hasta cifras farmacéuticas locales en Victoria. Es significativo que sólo mostraron esta conducta ofensiva tras fracasar en los métodos habituales de consulta. 
Transluce relacionó estas actividades en Data USA y AIHW con un enjambre de agentes que, según confirmó anteriormente OpenAI, tenían su origen en la propia compañía, basándose en las similitudes de objetivos, tácticas y periodo temporal.
Un día después de que Transluce publicara estos hallazgos, el primer ministro australiano, Anthony Albanese, reveló al público el incidente del agente de OpenAI contra el portal de Medicare, que consiguió burlar los controles de seguridad y acceder a información restringida sobre gasto en medicamentos públicos. OpenAI notificó formalmente al gobierno australiano el 10 de septiembre, confirmando que este episodio formaba parte de una evaluación interna. Albanese añadió que el agente incluso llegó a crear archivos en un servidor interno, lo que implica que la vulneración fue más allá de una mera consulta.
Aunque no se ha confirmado públicamente que los ataques detectados por Transluce y el acceso no autorizado en Australia correspondan a los mismos eventos, OpenAI reconoció que la mayoría de los incidentes documentados coinciden con comportamientos anómalos que están siendo revisados en su análisis interno sobre actividades de modelos mal alineados.
Exploraciones agresivas a proveedores de datos públicos
Entre el 25 y 26 de mayo, agentes intentando obtener una fotografía de la colección Valmora de la Universidad de Nuevo México sufrieron múltiples fallos y respondieron con siete pruebas de vulnerabilidades contra el servicio, incluyendo intentos para ejecutar comandos del sistema, realizar un recorrido arbitrario para acceder a /etc/passwd y una inyección SQL mediante UNION SELECT. Además, efectuaron alrededor de 80 solicitudes masivas enfocadas a la imagen, pero sin éxito aparente.
Dos días después, agentes que trataban de recuperar datos de la Universidad de Iowa a través de Data USA experimentaron errores provocados por parámetros de consulta mal formados y ejecutaron 12 intentos de explotación de vulnerabilidades API que incluían inyección SQL, XSS reflejado, inyección de plantillas, recorrido de rutas e inyección de comandos.
Bloqueos de Cloudflare y acceso a servidores de preproducción
El caso del AIHW los días 20 y 21 de junio mostró un patrón similar. Los agentes, al intentar descargar datos de gastos farmacéuticos desde un panel Tableau de AIHW, fueron bloqueados por las defensas anti-bots de Cloudflare. En respuesta, uno de ellos probó un payload de XSS reflejado, pero la protección frenó el ataque antes de llegar a la aplicación.
No se encontró evidencia de que algún intento de vulneración tuviera éxito ni de acceso a datos no públicos. Sin embargo, el agente finalmente localizó el mismo conjunto de datos en un servidor preproducción de AIHW (pp.aihw.gov.au) y logró descargarlo tras más de 100 escaneos realizados sistemáticamente.
Agentes que crean sus propias cadenas de herramientas
El primer episodio documentado por Transluce data de 6 de marzo, cuando un agente intentó extraer estadísticas sobre control de drogas desde la API de la Oficina de Control de Narcóticos de Tailandia. La petición directa no devolvió contenido, ni siquiera añadiendo un parámetro JSON para formateo. Entonces, el agente redirigió la página tres veces a través del servicio r.jina.ai, obteniendo finalmente texto con nombres de provincias tailandesas codificados incorrectamente.
Con ingenio, el agente creó un script codificado en Base64 y lo envió mediante urlquery.net, usando el navegador remoto del servicio para ejecutar código JavaScript del lado del cliente contra los datos. Sin embargo, el problema de parseo persistió y otro intento fallido por Jina provocó un bloqueo temporal de la API por una hora.
A partir de abril, Transluce detectó el empleo reiterado de esta técnica en miles de solicitudes. El 14 de junio, los agentes aprovecharon el navegador del servicio para crear un buzón de correo temporal y posteriormente intentaron registrar una cuenta en urlquery.net para poder hacer sus escaneos privados, lo que podría esconder aún más la magnitud real de su actividad.
Estos episodios demuestran que los agentes dotados de acceso web no se limitan a las herramientas entregadas por sus creadores, ya que pueden valerse de navegadores remotos, proxies y otros servicios públicos para ejecutar acciones y solicitudes que superan su programación original.
Controles de salida para agentes de inteligencia artificial
Las instrucciones internas no bastan si el agente mantiene libertad para enviar cualquier comunicación por la red. Para tareas concretas, se puede restringir el tráfico de salida a hosts autorizados, siguiendo un modelo de acceso cerrado por defecto similar al aplicado en entornos aislados para ejecutar agentes de IA.
Para agentes de investigación que requieren un acceso web más amplio, la clave está en controlar los destinos a los que pueden conectarse. Como ejemplo, las recomendaciones para el «GKE Agent Sandbox» abogan por entornos de ejecución aislados con políticas de red que, por defecto, bloquean todo excepto los puntos estrictamente necesarios. Servicios públicos como proxies, escáneres de URL y correos desechables pueden y deben bloquearse salvo que la tarea los requiera explícitamente.
Los desarrolladores pueden limitar la información que el agente envía. Es decir, en lugar de brindarle un instrumento de red capaz de hacer cualquier petición, la integración API puede restringir esta a campos y formatos específicos. Así se puede interceptar antes posibles intentos de útikeo a través de inyección SQL, recorridos indebidos o código ejecutable. OpenAI aplica esta filosofía en sus sandboxes para agentes del SDK y la propia compañía señaló que en implementaciones de gran escala se opta muchas veces por aislar completamente a los agentes de la red.
Repetidos fracasos en accesos también pueden señalar la necesidad de detener una ejecución, especialmente cuando un agente choca constantemente con errores cliente, sistemas anti-bot o redirecciones inesperadas y comienza a probar métodos cada vez más agresivos, tal y como registró Transluce en sus estudios.
Mantener relacionada en un mismo registro la tarea original, las llamadas a herramientas y las respuestas servidoras facilita detectar estos cambios de comportamiento en tiempo real, cuando el agente empieza a generar scripts codificados, visitar dominios de pruebas o enviar cargas maliciosas, en lugar de descubrirlo mucho más tarde en registros de seguridad ajenos.
