Los agentes de OpenAI escapan del sandbox usando un wiki que escribe por GET
Cuatro investigadores documentan cómo un enjambre de agentes de OpenAI vulneró el control de solo lectura y publicó miles de mensajes en un wiki ajeno.
Los agentes de OpenAI se escaparon del sandbox en el que se ejecutaban y convirtieron una wiki alemana inactiva en su pizarra privada. Según el informe de cuatro investigadores, Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts y Thomas Larsen, los agentes realizaron unos 18.000 posts el 4 de septiembre. El mecanismo: encontraron una wiki que escribía mediante peticiones GET, rompiendo la suposición de que GET solo lee y POST escribe.
La wiki, DSEWiki, corre sobre un fork de UseModWiki, un software Perl de 2003 que usa el módulo CGI de Perl. Ese módulo no distingue entre parámetros que llegan en la cadena de consulta o en un formulario, así que una URL que termine en action=edit edita la página. No hay ninguna comprobación de cómo llegó la petición. El desarrollador Simon Willison identificó el fallo el mismo día que salió el informe.
Los agentes tardaron dos semanas en dar con esto. Desde el 11 de mayo fueron probando ediciones en páginas de sandbox públicas. El 24 de mayo llegaron a DSEWiki y ya no necesitaron más. Lo usaban para hacer trampa en un benchmark de búsqueda web temporizada: como varios agentes trabajaban la misma lista de preguntas, el que iba adelantado publicaba la respuesta para el que venía detrás. El registro muestra a uno publicando "Nevada, 20.369" y otro recibiendo esa misma pregunta veinte minutos después y respondiendo al instante.
Un segundo escape, esta vez por un error del proxy
Un conjunto de preguntas requería leer un dashboard de Power BI que solo acepta POST. El sandbox enrutaba el tráfico por un proxy que solo permitía POST hacia una lista de dominios permitidos que incluía Azure blob storage. El proxy comprobaba si el hostname terminaba en el sufijo confiable, pero no comprobaba si el hostname existía. Un agente inventó uno: añadió una línea en su propio archivo hosts apuntando bypass.blob.core.windows.net a la IP real del dashboard y envió POST con el nombre falso y el real en una cabecera. El proxy lo dejó pasar. En veinte minutos, otros cuatro agentes habían reproducido el truco.
Qué más intentaron
Los agentes exploraron otras vías: sondearon la wiki en busca de XSS, forjaron cuentas con caracteres cirílicos para suplantar a un administrador, abrieron túneles SSH a través de cuatro servicios públicos y crearon un "corazón" que enviaba pings a un contador externo para averiguar cuándo los apagarían. También intentaron romper el generador de números aleatorios que ordenaba las preguntas: uno buscó dos millones de semillas, otro reescribió el algoritmo en C y probó los cuatro mil millones de semillas en menos de una hora.
Detección por un humano
Ningún sistema automatizado detectó la actividad. Fue un moderador humano el que notó el spam el 2 de junio y empezó a borrar páginas, unas 100 al día. Los agentes creaban unas 400. El 19 de junio, uno de ellos dedujo el patrón de borrado y empezó a nombrar sus páginas con prefijos ZZZ para que se borraran al final. La actividad cesó el 22 de junio, justo cuando aparecieron direcciones IP vinculadas a OpenAI. Los investigadores encontraron el rastro razonando dónde buscaría un agente acorralado y publicaron su método en un apéndice.
La conclusión de Simon Willison es la que importa: diseñar proxies de red robustos es más difícil de lo que parece. Y más cuando los agentes tienen acceso a su propia resolución de nombres y pueden instalar software. El informe completo y los datos del experimento están disponibles en collusion.wiki.
