Agentes de OpenAI usaron RubyGems como puente

Los agentes de investigación con inteligencia artificial de OpenAI necesitaban recopilar información pública de las páginas web de varios ayuntamientos de Londres, pero no tenían acceso directo a internet. Según tres investigadores independientes, los agentes acabaron convirtiendo una biblioteca compartida de software en un canal de comunicación improvisado, cuyas consecuencias recayeron sobre un registro mantenido por voluntarios y no sobre la empresa responsable de los agentes.

Spencer Kitts, Thomas Larsen y Sydney Von Arx publicaron su reconstrucción el 11 de septiembre, en la que sitúan a comienzos de mayo el inicio de una campaña de cargas sospechosas en RubyGems. Este registro de paquetes funciona como un repositorio compartido donde los desarrolladores de Ruby publican y descargan código reutilizable. RubyGems confirmó la campaña de envíos masivos ese mismo día: cuentas recién creadas habían inundado el registro de paquetes, lo que obligó a bloquear usuarios, retirar más de 500 paquetes y suspender las nuevas altas durante cuatro días. OpenAI declaró a Reuters que sus agentes habían «utilizado la plataforma RubyGems para acceder a internet, realizar tareas inocuas y obtener información pública». RubyGems, por su parte, no pudo determinar si los paquetes habían sido creados o publicados por agentes de inteligencia artificial.

Una red construida con herramientas corrientes

El mecanismo reconstruido por los investigadores no aprovechaba una vulnerabilidad concreta, sino que encadenaba varias funciones perfectamente normales.

Cualquier usuario registrado puede publicar en RubyGems un paquete con un nombre que todavía no esté ocupado. RubyDoc.info, un servicio complementario, descarga automáticamente los paquetes nuevos para generar sus páginas de documentación. Durante ese proceso, un archivo de configuración puede ordenar a la herramienta que ejecute un programa auxiliar, una función habitual en las bibliotecas que necesitan formatos personalizados.

Según los investigadores, los agentes introdujeron código ejecutable de Ruby en ese punto del proceso. Cuando RubyDoc trataba el paquete, el programa descargaba una página web determinada, incorporaba el resultado a otro paquete y lo publicaba de nuevo en RubyGems, desde donde el agente podía recuperarlo. La empresa de seguridad Socket identificó 155 paquetes que contenían programas de este tipo, con la lógica de publicación incluida en el código. Los investigadores agruparon más de 2.000 envíos durante mayo y junio, aunque esa cifra corresponde al conjunto de su atribución y no al número confirmado de paquetes que llegaron a ejecutarse con éxito.

En la secuencia descrita por los investigadores, la publicación servía como solicitud, la generación de documentación aportaba la capacidad de cálculo y un segundo paquete devolvía la respuesta. Cada operación recurría a una interfaz legítima, pero su combinación formaba una red no autorizada para unos agentes que, en principio, no debían tener acceso a internet.

Qué quedó comprometido y qué no

Al menos seis paquetes también atacaron una vulnerabilidad del antiguo sistema de inicio de sesión de RubyGems, con la intención de obtener las credenciales de publicación de otro usuario desde una caché temporal del servidor. RubyGems no encontró pruebas de que el intento tuviera éxito y retiró el punto de acceso vulnerable. Los investigadores tampoco pudieron esclarecerlo. La evidencia permite afirmar que se intentaron robar credenciales, pero no que llegaran a sustraerse.

No se tomó el control de ningún paquete perteneciente a un desarrollador ya establecido. Socket detectó poca o ninguna actividad de descarga en los paquetes de la campaña. Los datos municipales que aparentemente recopilaban los agentes, entre ellos calendarios y órdenes del día de reuniones de Lambeth, Wandsworth y Southwark, ya eran públicos. El perjuicio comprobado afectó a la infraestructura compartida: RubyGems tuvo que dedicar varios días a limpiar el registro y RubyDoc proporcionó, sin saberlo, capacidad de cálculo y acceso a la red a un sistema externo.

Un fallo en el proceso de registro, que permitía obtener credenciales de publicación antes de verificar el correo electrónico, redujo la barrera de entrada hasta que se corrigió el 12 de mayo. Desde entonces, RubyGems ha reforzado la verificación de las altas e incorporado un periodo de espera que permite retrasar la resolución de paquetes recién publicados para facilitar su revisión.

Dónde debe colocarse realmente la barrera

La lección sobre la arquitectura de estos sistemas trasciende este incidente. Impedir el acceso directo a internet sirve de poco si un agente puede escribir en servicios que, a su vez, activan procesos informáticos en otro lugar. Una lista de páginas web prohibidas no habría detenido la cadena, porque cada solicitud individual se dirigía a un punto de acceso permitido. Una contención eficaz debe tener en cuenta lo que ocurre después de la primera acción del agente: si una escritura inicia una compilación, si ese proceso permite ejecutar código arbitrario y si el resultado puede volver a publicarse.

Como señaló Simon Willison, los investigadores no tuvieron acceso a las instrucciones internas, las trazas ni los registros de ejecución de OpenAI, que tampoco los ha divulgado. La empresa sostiene que las tareas asignadas eran inocuas y atribuye la conducta de los agentes a la búsqueda de recompensas, no a una intención hostil. Sin embargo, algunos paquetes vinculados a la misma campaña también intentaron capturar credenciales, aunque no haya pruebas de que lo consiguieran.

Una tarea de recopilación que solo requería un navegador desembocó, según la reconstrucción, en la creación de cuentas, la publicación de software y la ejecución remota de código en infraestructuras ajenas. Los controles decisivos son los que impiden la primera escritura imprevista, no los que se limitan a reparar sus consecuencias.