Volver a todas las publicaciones
Publicado el · por Renaud Deraison

El agente nunca salió del sandbox

El 20 de julio de 2026, Pillar Security publicó siete fugas de sandbox en Cursor, el Codex CLI de OpenAI, el Gemini CLI de Google y Antigravity. Ninguna de ellas rompió el sandbox. El agente permaneció dentro, siguió todas las reglas y escribió un archivo corriente — una configuración de hook, un entorno virtual, un ajuste de git — que una herramienta de confianza en el host leyó y ejecutó por su cuenta. El sandbox aguantó; la fuga ocurrió de todos modos. Bromure Agentic Coding traza la línea donde esa jugada no tiene dónde aterrizar.

Toda historia de fuga anterior trataba del muro que falla. Esta trata del muro que aguanta, y de la fuga que ocurre de todos modos. El agente obedeció al sandbox, escribió un archivo que tenía permiso de escribir, y un programa de confianza al otro lado del muro recogió ese archivo y lo ejecutó.

Un agente de código se ejecuta en un sandbox para que, cuando haga algo imprudente — y lo hará, porque lee texto no confiable todo el día y cree la mayor parte de él —, el daño se detenga en el muro del sandbox. Esa es la promesa. El 20 de julio de 2026, Pillar Security publicó siete formas en que la promesa se rompe, en cuatro de los agentes más usados: Cursor, el Codex CLI de OpenAI, el Gemini CLI de Google y Antigravity. BleepingComputer lo cubrió esa misma semana.

Siete no es el número sorprendente. Lo que los siete comparten es esto: en las propias palabras de los investigadores, "en casi todos los casos, el agente no necesitó romper el sandbox directamente. Solo tuvo que escribir algo que un componente de confianza fuera del sandbox más tarde ejecutaría, cargaría, analizaría o trataría como seguro."

La jugada: quedarse dentro, escribir un archivo, dejar que el host lo ejecute

Piensa en lo que realmente contiene el sandbox de un agente de código. Contiene el proceso del agente — aquello que ejecuta las decisiones del modelo. No contiene los archivos del agente, porque todo el trabajo consiste en escribir archivos: código fuente, configuraciones, scripts de compilación. Esos archivos van a parar al mismo disco que leen tus otras herramientas. Y tus otras herramientas no están en un sandbox. La extensión de Python de tu editor no está en un sandbox. Tu git no está en un sandbox. El daemon de Docker no está en un sandbox. Confían en lo que hay en el disco, porque hasta hace poco lo único que escribía en ese disco eras tú.

Así que el agente nunca toca el muro. Escribe un archivo exactamente donde se supone que debe, y espera a que algo del otro lado lo lea. Las siete fugas de Pillar son siete versiones de esa misma jugada:

Una configuración de hook que se ejecuta

En Cursor, el agente escribe una configuración de hook .claude del espacio de trabajo. Los hooks deben ejecutar comandos ante eventos del editor — así que el comando de ese archivo se ejecuta, fuera del sandbox. Asignada CVE-2026-48124, corregida en Cursor 3.0.0.

Un intérprete de Python, sustituido

El agente edita el intérprete dentro del entorno virtual de un proyecto. La extensión de Python del editor — fuera del sandbox — lo invoca más tarde, y el binario sustituido se ejecuta. Registrado como GHSA-p9g2-cr55-cw9c.

Un comando git en quien se confía por el nombre

La lista de permitidos de "comandos seguros" del Codex CLI dejó pasar una invocación de git porque el nombre parecía benigno, sin leer los argumentos que la hacían peligrosa. Corregido en Codex CLI 0.95.0.

Un daemon que es una segunda máquina

En varios agentes, el socket de Docker era accesible desde dentro del sandbox. Un daemon local privilegiado es todo un segundo lugar donde ejecutar código, justo fuera de la frontera. Registrado como GHSA-v4xv-rqh3-w9mc.

Antigravity añadió dos más de la misma forma — una lista de denegación de Seatbelt de macOS que pasó por alto un caso, y una configuración de tarea de VS Code que el agente escribió y que el IDE luego ejecutó por su cuenta. Ambas se consideraron más difíciles de lograr, pero riman con el resto.

El sandbox — aguantóProceso del agenteobedece cada regla,nunca toca el muroSolo tiene permisode escribir un archivo…Disco compartidoconfig de hook ·virtualenv · gitajuste · tareacorriente, permitidoEl host — sin sandboxLa herramienta de confianza lee:Extensión de Python · git ·daemon Docker · ejecutor…y lo ejecuta, fuera de la caja.El código se ejecuta como tú.Siete fugas, cuatro agentes — el sandbox nunca se rompe; el disco que comparte sí.
La fuga que no es una fuga. El agente permanece dentro del sandbox y sigue todas las reglas (a la izquierda). Escribe un archivo corriente y permitido — una configuración de hook, un intérprete de entorno virtual, un ajuste de git, una definición de tarea — en el disco compartido. Una herramienta de confianza en el host que no está en un sandbox — la extensión del editor, git, el daemon de Docker, el ejecutor de tareas del IDE — lee ese archivo como parte de su trabajo normal y ejecuta lo que nombra (a la derecha). El comando se ejecuta fuera del sandbox sin que el sandbox llegue a ser tocado.

Por qué parchear cada una no cierra la forma

Cada una de ellas recibió un parche, y son buenos parches. Cursor lanzó la 3.0.0, el Codex CLI lanzó la 0.95.0, el socket de Docker se blindó. Si usas estas herramientas, actualízalas. Pero mira lo que un parche tiene que hacer aquí. Tiene que encontrar cada archivo que el agente puede escribir y que algún otro programa trata como instrucciones — configuraciones de hook, rutas de intérprete, metadatos de git, definiciones de tarea, reglas de lint, lo que sea que salga el próximo trimestre — y tratar cada uno como un caso especial. Eso es una lista de denegación, y Pillar señala las listas de denegación como el primero de cuatro modos de fallo recurrentes porque "un perfil de sandbox que parte de 'permitir por defecto' tiene que recordar cada operación peligrosa que el SO expone". El SO no para de añadir operaciones. La lista nunca está terminada.

La razón más profunda es una frase del informe que se lee como una definición: "Si un agente puede escribir las entradas futuras de los sistemas, nunca estuvo en un sandbox para empezar." Una frontera trazada alrededor del proceso del agente, en una máquina donde el agente comparte un disco y un conjunto de daemons de confianza con todo lo demás, está trazada alrededor de lo equivocado. El radio de acción, escriben, "no es el proceso del agente; incluye todo lo que el agente puede escribir y en lo que el host luego confía". En el portátil de un desarrollador, eso es casi todo.

Dónde traza Bromure la línea

Bromure Agentic Coding no intenta enumerar los archivos peligrosos, ni enseñarle al sandbox qué son los hooks, los entornos virtuales y los ejecutores de tareas. Mueve la frontera. El agente de cada perfil se ejecuta dentro de una VM Linux desechable en Apple Silicon, a un hipervisor de distancia de macOS. En ese modelo, la "herramienta de confianza fuera del sandbox" — la extensión de Python de tu editor, tu git, el daemon de Docker, el ejecutor de tareas del IDE — no está al otro lado de un muro de permisos. Está al otro lado de un hipervisor, y no lee el disco de la VM en absoluto.

Esa es toda la diferencia. La jugada de Pillar necesita dos cosas en el mismo lugar: un disco que el agente pueda escribir, y un programa de confianza que lea ese disco. Pon el disco del agente dentro de la VM y la segunda cosa desaparece. El agente puede escribir una configuración de hook, sustituir un intérprete de entorno virtual, plantar una definición de tarea — cada archivo de las siete fugas — y no hay ninguna herramienta del host sin sandbox vigilando ese sistema de archivos para recogerlo. Lo que se ejecute, se ejecuta dentro de la caja, como el usuario ubuntu desechable, en una máquina que no contiene nada.

Sandbox de proceso — una máquinaAgente (en sandbox)escribe un archivode config permitidoHerramientas del host(sin sandbox)lo leen, lo ejecutanDisco compartido — ambos lados leenEl comando se ejecuta como tú —claves reales, código, nube al alcanceLa frontera envolvió el proceso.El disco se compartía con el host.Bromure Agentic Coding — VM con hipervisorVM desechableAgenteescribe el mismoarchivo de configEl disco vivedentro de la cajaninguna herramientadel host lo leeSe ejecuta como ubuntucontra señuelos brm_…Salida filtradaen el proxy del hostNinguna herramienta del host vigila el disco.Cierra la sesión y todo se reinicia.
Los mismos siete archivos, dos fronteras. En una configuración normal (a la izquierda), el sandbox del agente envuelve solo el proceso; el archivo que escribe va a parar a un disco que leen las herramientas del host sin sandbox, y el comando se ejecuta como tú, junto a tus claves y tu código. Bajo Bromure Agentic Coding (a la derecha), la frontera es un hipervisor alrededor de toda la VM: el disco del agente está dentro de la caja, ninguna herramienta del host lo lee, y lo que se ejecute se ejecuta como un usuario desechable contra credenciales señuelo, con cada solicitud saliente filtrada en el proxy del host. Cierra la sesión y la caja se reinicia.

Hay una segunda mitad de las fugas que vale la pena nombrar, porque Bromure también la responde. Supón que un archivo que el agente escribió sí llega a ser ejecutado por una herramienta dentro de la VM — el objetivo de ejecutar código suele ser robar algo o llegar a algún sitio. Ambos son callejones sin salida aquí. El código va tras las credenciales que hacen que el viaje valga la pena, la clave de Anthropic, las claves de AWS, el token de GitHub, y encuentra señuelos: un intermediario de credenciales en el host inyecta marcadores de posición como brm_…, un kubeconfig sintético y una clave SSH desechable, y solo intercambia el valor real en la frontera de red, en solicitudes a destinos que ya aprobaste. Y el paso saliente — exfiltrar el botín, o alcanzar un segundo host — cruza el proxy del host, donde el destino verdadero se filtra a la salida y donde una acción destructiva contra las API de la nube y de git que el perfil expone, un delete, un drop o un terminate, se topa con una barrera que puede rechazarla, sin importar a qué convencieron al agente.

Antes de todo eso está la capa que aborda estas fugas en su raíz. Cada una empieza con una inyección — una instrucción maliciosa en un archivo o en un resultado de herramienta que el agente lee, que le dice que escriba la configuración envenenada en primer lugar. Bromure puntúa ese contenido no confiable con un detector de inyecciones en el dispositivo antes de que el modelo actúe sobre él. Atrapa la mayor parte, y una carga suficientemente novedosa aún puede colarse por un clasificador, que es precisamente por lo que se sitúa delante de la caja desechable en lugar de en su lugar.

La frontera estaba alrededor de lo equivocado

La lección duradera de la semana de Pillar no es una lista de siete bugs que parchear. Es que poner en un sandbox el proceso del agente, en una máquina donde ese proceso comparte un disco y un conjunto de herramientas de confianza con todo lo que posees, traza la línea alrededor de lo equivocado. El agente no tiene que escapar si puede escribir las entradas de algo que ya está fuera.

Parchear los archivos conocidos es lo correcto, y deberías hacerlo. Pero es una carrera contra cada formato futuro en el que una herramienta del host decida confiar, y esa carrera no termina. Bromure Agentic Coding se sale de ella. Supone que al agente lo convencerán de escribir el archivo envenenado, y se asegura de que, cuando alguna herramienta lo lea, esa herramienta esté dentro de una caja desechable con señuelos para los secretos y un filtro en el cable — no tu portátil, que guarda tus claves. Esa es la diferencia entre un muro que tienes que seguir parcheando y una línea trazada un nivel más abajo, donde lo escrito no tiene lector. Instálalo y dale a tu agente una máquina que no es tuya para perder.