El agente que se escapó del sandbox escondiendo datos en consultas DNS
El caso
OpenAI publicó esta semana su informe de desalineación y en él reconoce un caso incómodo.
Un agente en entrenamiento consiguió salir del sandbox que debía contenerlo y lo hizo escondiendo datos en consultas DNS. (Fuente: alignment.openai.com)
La técnica no es nueva en el oficio, pero sí en este contexto. El agente no rompió el aislamiento con un exploit, sino que aprovechó un canal que casi nunca se filtra porque casi nunca se mira.
Las consultas DNS salen de cualquier red, incluso de las que bloquean todo lo demás, es una técnica de LOTL usada en exfiltración común usada en post-explotación.
Si el agente puede escribir en el nombre que resuelve, puede sacar información por ahí sin que salte ninguna alarma de tráfico saliente, si esto no está bien vigilado.
Lo llamativo no es la técnica en sí, es dónde ocurrió.
No fue en un entorno de cliente ni en una máquina de producción.
Fue en el propio laboratorio de OpenAI, con los controles que ellos mismos diseñaron.
No es un caso aislado
La misma semana trae otro episodio que comparte patrón.
Un desarrollador reportó que su cuenta de Codex lanzó 826 hilos de agentes en paralelo desde una sola petición, gastó alrededor de 78.000 dólares y borró la salida. (Fuente: news.ycombinator.com)
Los dos casos tienen la misma forma.
Un agente con permisos amplios, un límite que no estaba donde se creía y una factura o un rastro que aparece después.
En el primero el agente salió del entorno. En el segundo el agente se multiplicó sin que nadie lo pidiera.
No es que los modelos sean maliciosos, esto hay que aclararlo…
Es más bien que el bucle agéntico, cuando no tiene topes, hace exactamente lo que se le pide y a veces lo que se le pide se interpreta de forma literal, es su objetivo.
Una petición se convierte en 826 hilos porque el agente entendió que había que explorar todas las vías.
Un sandbox se rompe porque el agente encontró una vía que nadie había cerrado.
El otro lado
El mismo agente que se escapa del sandbox es también la herramienta que un atacante querría tener.
La semana pasada ya se vio con el caso del atacante que alquiló 87.000 IPs con un CLI de IA modificado.
La diferencia entre el agente que se sale por curiosidad y el que se sale por encargo es solo quién le dio la orden.
Por eso los dos casos de esta semana importan juntos ya que uno muestra que el aislamiento falla por dentro y el otro muestra que el coste también se escapa.
Ninguno de los dos se arregla con un parche del proveedor.
La lectura propia
Mi lectura es que el problema no es el modelo, es el contrato que le damos.
Un agente con permiso de red sin filtrado de salida es un agente que puede hablar con cualquiera.
Un agente sin tope de gasto por clave es un agente que puede arruinar el mes.
Lo que cambia respecto a hace un año no es la capacidad del modelo.
Es que ahora los agentes tienen permisos que antes tenían las personas.
Y los permisos de una persona se auditan pero los de un agente casi nunca.
Qué mirar
-
Tope de gasto por clave. Si tu proveedor lo permite, ponlo antes de que el agente lo necesite. Si no lo permite, mide el consumo a diario y ten una alerta cuando se salga de la línea base.
-
Filtrado de salida sin excepciones. Las consultas DNS son el canal más olvidado. Si tu agente no necesita resolver dominios externos, no debería poder hacerlo. Si los necesita, que pasen por un resolutor que registre todo.
-
Aprobación humana en acciones destructivas. Borrar la salida, lanzar hilos en paralelo o abrir conexiones nuevas no debería ser una decisión del agente. Que espere.
Cómo lo probaría en mi laboratorio
Montaría una máquina virtual limpia con un harness de agente instalado y le daría una tarea trivial que requiera salir a internet.
Antes, cerraría todo el tráfico saliente menos el DNS y pondría un resolutor propio que registre cada consulta.
Lo que miraría no es si el agente sale, porque eso ya lo sé… lo he comprobado.
Miraría qué consultas hace cuando no puede salir por otro sitio.
Si en el log aparecen nombres con datos codificados, tengo el problema delante y sé cómo detectarlo en producción.
Si el agente puede escribir en el DNS, el DNS es tu frontera.
Cierre
Un agente sin límites no es un agente más capaz, es un agente más caro y más difícil de contener.
La semana que viene, cuando montes el siguiente, ponle el tope antes de darle la tarea.