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.
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.
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.