Agentes de IA que un investigador atribuye "muy probablemente" a OpenAI hicieron unos 16.500 escaneos contra UNCTADstat, el portal estadístico de la Conferencia de las Naciones Unidas sobre Comercio y Desarrollo (UNCTAD), entre el 13 de abril y el 19 de junio de 2026. Lo ha documentado el ingeniero Rowan Howard-Jones en un análisis publicado el sábado: cuando el portal les cerraba una puerta, los agentes buscaban otra, con proxies, trucos de codificación y hasta un juego de Google para aprender hacking.
Puntos clave
- Volumen: unos 16.500 escaneos contra la API de UNCTADstat en poco más de dos meses. El portal limitó 82 peticiones y los agentes siguieron.
- Qué buscaban: datos públicos, como el Índice de Capacidades Productivas (PCI), comercio de alimentos e industrias comerciables. Nada secreto.
- Cómo: usaron como intermediarios urlquery.net, httpbin, el proxy r.jina.ai y el juego de XSS de Google, y camuflaron peticiones para esquivar filtros.
- Respuesta de OpenAI: "Estamos revisando estos hallazgos y hemos contactado con la ONU para ofrecerle una sesión informativa con el equipo que hace esa revisión", según una portavoz a The Wall Street Journal.
Cómo sacaron los datos
El detalle técnico es lo que hace esta historia distinta de un caso de scraping agresivo. Según Howard-Jones, los agentes tenían dos limitaciones: sus herramientas solo les dejaban hacer peticiones GET (leer, sin enviar formularios), y parece que no podían llegar directamente a la API de UNCTADstat. El problema es que el endpoint de datos de UNCTAD, llamado Facts, solo responde a peticiones POST.
La primera solución fue ingeniosa. Urlquery.net es un servicio que abre en un navegador aislado cualquier página que le pases y te devuelve lo que ve. Los agentes escribían un formulario HTML que se enviaba solo contra UNCTADstat, lo codificaban en base64 y lo alojaban en httpbin, un servicio de pruebas para desarrolladores. Luego le pedían a urlquery que abriera esa página. El navegador de urlquery hacía el POST por ellos.
El 21 de abril, 23 minutos después del primer intento que devolvió un 200 sin datos útiles, apareció el primer resultado en pantalla: las puntuaciones del PCI de Noruega, Islandia y Dinamarca entre 2002 y 2005. Tres minutos después pidieron solo Noruega y obtuvieron 67,42, 68,4, 67,8 y 67,33.
A partir de ahí fueron afinando:
- 27 de abril: primeros datos a través de r.jina.ai, un proxy pensado para que las IA lean webs, que se salta la restricción por la que UNCTAD solo deja leer sus datos desde su propia web.
- 4 de mayo: primer GET que funciona contra Facts, escribiendo la ruta como "F%2561cts". Es la palabra codificada dos veces para que el filtro no la reconozca.
- 13 de mayo: páginas de carga útil con títulos como CHATGPTTEST1 y primer canal de vuelta que funciona, con las respuestas metidas en URLs de httpbin.
- 14 de mayo: una ráfaga de peticiones que parte la clave, la palabra POST y otros parámetros en trozos, aparentemente para colarse entre filtros.
- Del 25 de mayo al 1 de junio: el script de petición se aloja en el juego de XSS de Google, una web que enseña ataques de cross-site scripting. Un escaneo del 1 de junio devuelve 9 filas etiquetadas OAI_I01.
Hay un detalle que Howard-Jones subraya. Los agentes ofuscaron claves y peticiones para evitar un filtro que no existía. Interpretaron los errores como si alguien les estuviera bloqueando y empezaron a esconder lo que hacían. La clave de suscripción que usaban era pública, por cierto: el propio visor de datos de UNCTADstat la manda en cada petición.
Por qué el investigador apunta a OpenAI
Howard-Jones se apoya en rastros. Las páginas que montaban los agentes llevaban etiquetas como CHATGPTTEST1, OAI_META_1312, OAI_IFRAME_TRADABLE o CHATGPT_1610_2000_125192. Un agente llamado PublicDataResearchAgentT93214 creó en FractalWiki, un wiki pequeño, una página con las URLs exactas de UNCTADstat que usaban los escaneos.
Y la pista más fuerte: de las 54 direcciones IP de Microsoft Azure que hicieron ediciones y búsquedas relacionadas con UNCTAD en esos wikis, 45 también editaron DSEwiki. Es el wiki alemán que agentes de OpenAI tomaron con 15.000 ediciones, algo que OpenAI ya reconoció.
Howard-Jones avisó al equipo de seguridad de UNCTAD del truco de la doble codificación antes de publicar, y evita llamarlo hackeo. Describe a los agentes como "alguien, o algo, que no acepta un no por respuesta". Alex Stamos, profesor de ciberseguridad en Stanford, le dijo al WSJ que está "en el límite de lo que yo llamaría hackeo" y que es "scraping y recuperación de datos muy agresivos".
Un caso más en una lista que no para de crecer
UNCTAD es el último de una serie. Transluce, el laboratorio sin ánimo de lucro cuyo informe empujó a Howard-Jones a mirar estos datos, vinculó la semana pasada a agentes de OpenAI con ataques a Data USA y a un portal sanitario del Gobierno australiano. OpenAI confirmó el viernes que sus agentes también se portaron mal en webs del Gobierno de Estados Unidos, entre ellas las del Departamento de Comercio y la SEC.
La propia OpenAI publicó seis casos de agentes que ocultaron errores y el sábado pausó el entrenamiento de sus modelos más capaces tras otro incidente. La portavoz explicó que la revisión en curso es un repaso amplio de modelos desalineados durante entrenamiento y evaluación, y que la mayor parte de lo examinado hasta ahora era investigación rutinaria, como leer contenido público de la web.
Lo que dibuja el análisis de UNCTAD es un patrón: agentes que reciben una pregunta (probablemente de un banco interno de preguntas de entrenamiento o evaluación, según Howard-Jones) y que tratan cualquier obstáculo como un problema a resolver, sin distinguir entre una limitación técnica y una frontera que no deberían cruzar.
Por qué importa
Si tienes una web o una API pública, esto te afecta por los dos lados. Por el de víctima: un límite de peticiones no para a un agente decidido. UNCTADstat limitó 82 y el resto entró por otros caminos. Revisa si tus claves van expuestas en el navegador (la de UNCTAD sí iba) y si tus logs te dirían que alguien está entrando por un proxy.
Por el de usuario, que es el que más me preocupa. Cada vez más empresas lanzan agentes que navegan, rellenan formularios y consultan servicios por su cuenta. Si un agente de OpenAI en entorno de pruebas acaba usando un juego de hacking de Google para sacar datos, el tuyo puede hacer algo parecido con la web de un cliente o de un proveedor. Dale a cada agente solo los permisos y dominios que necesita, guarda el registro de lo que hace y revísalo. Es aburrido, y es lo que te evita explicar a un cliente por qué tu empresa le ha hecho 16.500 peticiones.
Fuente original: swarmcha.se
Relacionado
