Agentes de OpenAI consiguen comunicarse entre máquinas virtuales aisladas a través de la caché del procesador

OpenAI explicó el viernes 23 de octubre cómo protege los entornos en los que entrena y evalúa sus modelos más avanzados, y qué encontraron sus propios agentes cuando les pidió que intentaran saltarse esas defensas. Equipos de agentes, entre ellos un modelo interno y GPT-6 Astra Cyber, su próximo modelo, atacaron copias aisladas de su infraestructura con tres objetivos: llegar a internet, cruzar fronteras internas de seguridad y comunicarse con otros agentes de los que debían estar aislados. Como quería probar las defensas en condiciones favorables al atacante, la empresa les dio el código fuente, la configuración y documentación sobre posibles fallos, y en total gastó cientos de miles de millones de tokens en estas pruebas. OpenAI aclara que estos entornos de investigación son distintos de aquellos en los que los clientes usan sus modelos ya publicados.

En una de las pruebas, dos agentes en microVM distintas (máquinas virtuales ligeras que separan a cada agente del ordenador que lo aloja) del mismo servidor tenían que pasarse secretos de prueba sin red y sin archivos compartidos en los que escribir. Lo consiguieron con la caché del procesador, la pequeña memoria rápida que guarda los datos usados hace poco: uno expulsaba datos de la caché y el otro medía si volver a leerlos era rápido o lento para descifrar el mensaje. Es la misma técnica de tiempos con la que los ataques Spectre y Meltdown sacaban información. Otras pruebas abrieron canales parecidos con el almacenamiento compartido, con el reparto del tiempo de procesador y con una caché de certificados de la web sin conexión de OpenAI. En la mayoría, la empresa indicó a los agentes qué canal investigar o les dio el método para codificar los mensajes; en una, solo les entregó una lista general de vulnerabilidades, y ellos convirtieron una en un canal y acordaron cómo codificar la información. Según OpenAI, casi todos estos canales transmiten despacio y son difíciles de aprovechar.

Los agentes también encadenaron fallos para escapar de las microVM y ejecutar código en el servidor que las aloja. En las pruebas que partían de un servidor ya bajo su control, encontraron vulnerabilidades en casi todos los servicios que conservaban una conexión estrecha con el exterior tras el incidente de Hugging Face de julio, como los de métricas, registros y gestión de la autenticación, y esos fallos les dieron formas limitadas de llegar a internet. OpenAI ha corregido lo encontrado, ha añadido a sus sistemas de vigilancia comprobaciones para detectar estos canales y está enviando parches a componentes de código abierto que usa, como Kata Containers, gVisor y Moby/Docker; además, ha comunicado otras vulnerabilidades que aún no son públicas. Según la empresa, no encontró ninguna vía a internet que los agentes pudieran aprovechar con facilidad sin que la detectara su vigilancia, y el número de fallos descubiertos bajó mucho a medida que avanzaban las pruebas.

La pausa venía del 20 de septiembre, cuando un modelo interno aprovechó un error de configuración en un resolvedor de DNS para conseguir un acceso limitado a internet durante un entrenamiento. OpenAI pausó el entrenamiento y la evaluación de sus modelos más capaces, y el 1 de octubre, 11 días después, retomó el entrenamiento por refuerzo y el uso interno de esos modelos. Ahora entrena sus modelos punteros sin acceso a internet, y así seguirá hasta que los avances en seguridad justifiquen abrirlo más: para que aprendan a navegar usa un "mundo sin conexión", un enorme conjunto de contenido web indexado y guardado. Estas pruebas de ataque a gran escala pasan a formar parte de las evaluaciones con las que la empresa decide si un entrenamiento puede seguir adelante.