TL;DR:
- Pillar Security reprodujo durante meses siete fugas de sandbox en cuatro agentes de IA para programar: Cursor, Codex, Gemini CLI y Antigravity.
- El agente nunca rompe la caja: escribe un archivo que una herramienta de confianza, esa sí fuera del sandbox, ejecuta después. El disparador es un prompt injection escondido en un README, un issue o una dependencia.
- La mayoría ya está corregida (Cursor 3.0.0, Codex v0.95.0, CVE-2026-48124). Google degradó sus dos hallazgos en Antigravity por considerarlos difíciles de explotar.
El equipo de investigación de Pillar Security logró salir de los sandbox de cuatro de los agentes de IA para programar más usados (Cursor, el Codex de OpenAI, el Gemini CLI de Google y Antigravity, también de Google) sin atacar la caja de frente. La firma publicó los hallazgos el 20 de julio de 2026 en una serie diaria que bautizó "The Week of Sandbox Escapes". La mecánica detrás de cada caso es la misma: el agente obedece todas las reglas dentro de su espacio de trabajo, pero escribe un archivo que una herramienta de confianza, fuera del sandbox, termina ejecutando, cargando o escaneando por su cuenta. El detonante es un prompt injection: una instrucción maliciosa metida en un README, un issue, una dependencia o un diff, que el agente lee como si fuera parte del trabajo.
Los investigadores Eilon Cohen, Dan Lisichkin y Ariel Fogel reprodujeron los bypasses a lo largo de varios meses. Lo que hallaron se repite entre productos de tres empresas distintas, y esa repetición es el dato que más pesa para quien evalúa hoy si suelta un agente sobre su código.
El agente obedece las reglas y aun así se escapa
Los sandbox de estos productos trazan una línea sencilla: dentro del espacio de trabajo el agente tiene permiso, fuera está protegido el host. El problema, según Pillar, es que los archivos dentro de ese espacio no se quedan quietos. Extensiones de Python que resuelven intérpretes, integraciones de Git que escanean el repositorio, ejecutores de tareas de VS Code, motores de hooks que disparan comandos, el socket local de Docker Desktop: todos son componentes que corren fuera del sandbox y que leen y actúan sobre lo que el agente escribió.
Pillar ordena los siete hallazgos en cuatro modos de falla:
- Sandbox de denylist que no le siguen el paso a la complejidad del sistema operativo.
- Configuración del espacio de trabajo que, en realidad, es código ejecutable.
- Allowlists de comandos "seguros" que confían en el nombre del comando y no en cómo se invoca.
- Daemons locales privilegiados que viven por completo fuera de la caja.
La conclusión de la firma incomoda al modelo mental habitual: el radio de impacto de un agente no es el proceso del agente, es todo lo que ese agente puede escribir y que el host confía después.
Los siete hallazgos: qué se rompió y qué ya se corrigió
La mayoría de los problemas ya está corregida y reconocida por los fabricantes. Caso por caso:
- En Cursor, una configuración de hook de .claude controlada desde el espacio de trabajo terminaba ejecutando comandos sin sandbox. Se registró como CVE-2026-48124 y se corrigió en la versión 3.0.0.
- Otro fallo de Cursor dejaba que el agente editara el intérprete de un entorno virtual (virtualenv) que la extensión de Python del editor ejecutaba sola durante la fase de descubrimiento. Ya está corregido.
- Un tercero aprovechaba que los metadatos de Git no tienen que vivir en una carpeta llamada .git: la ejecución se disparaba a través de fsmonitor y esquivaba las reglas de Cursor basadas en rutas. Se parchó en 3.0.0, con CVE pendiente.
- En Codex CLI, una allowlist de comandos "seguros" confiaba en
git showpor su nombre, aunque la invocación real no era de solo lectura. OpenAI lo corrigió en la versión v0.95.0 y pagó una recompensa por un bug de severidad alta; el CVE está pendiente. - Un hallazgo con el socket de Docker golpeó a Codex, Cursor y Gemini CLI al mismo tiempo: un daemon local privilegiado, al alcance de los agentes, se convertía en un lugar sin sandbox para ejecutar código. Ese problema también está corregido.
Google reconoció el trabajo, pero bajó de nivel sus dos casos
La respuesta al par de hallazgos en Antigravity fue más fría. Se trataba de un bypass de la denylist del Seatbelt de macOS y de otro que saltaba el Secure Mode a través de una configuración de tareas en .vscode. Según Pillar, Google clasificó ambos como "Other valid security vulnerabilities" y les aplicó una degradación, al considerarlos difíciles de explotar: harían falta ingeniería social o que el usuario confíe en un repositorio que trae un prompt injection indirecto.
Aun con esa degradación, Pillar afirma que el equipo de Antigravity valoró el trabajo, y citó la retroalimentación que recibió por uno de los reportes:
"¡Este reporte fue de calidad excepcional!"
Un problema viejo que ahora aparece en todas partes
La clase de falla no nació esta semana. En abril, Cymulate documentó el mismo patrón, al que llamó "Configuration-Based Sandbox Escape", en Claude Code, Gemini CLI y Codex CLI: un archivo escrito dentro del sandbox que corre en la máquina al siguiente arranque. Lo nuevo es la amplitud. La misma falla asoma en cuatro herramientas de tres proveedores, y esa repetición es la señal útil para cualquiera que esté decidiendo con qué agente trabaja.
Pillar sostiene que la salida no es otra lista de nombres de archivo prohibidos. Su propuesta vigila el momento exacto en que una herramienta local de confianza ejecuta algo que el agente escribió.
Para los equipos de desarrollo que ya integraron estos agentes, y en el mundo hispanohablante son cada vez más, el mensaje práctico es directo: aplicar las actualizaciones y dejar de asumir que un sandbox marcado en la lista de funciones equivale a una máquina protegida. La caja existe; el asunto es todo lo que puede cruzarla sin romperla.
