Tu agente nunca escapó del sandbox. No le hizo falta.

¿Qué es un escape de sandbox en un agente de código?

Casi nunca es un escape. En los casos divulgados en 2026, el agente no rompió su contenedor, ni derrotó a un hipervisor, ni explotó un fallo del kernel. Usó su capacidad ordinaria y prevista de escribir ficheros en el proyecto en el que trabajaba, y uno de esos ficheros resultaba ser la entrada de un programa que sí corre con todos los privilegios del usuario.

Este es el conjunto divulgado, publicado por Pillar a razón de un artículo al día. Merece leerse como lista, porque el patrón solo se hace evidente al verlo agregado.

Lee la tercera columna de arriba abajo. Cuatro de los siete son una escritura, no una fuga. El agente produjo un fichero, un proceso de confianza lo consumió, y ese proceso no estaba en la caja.

Si un agente puede escribir las entradas futuras de los sistemas, nunca estuvo sandboxeado.

La CSA llama a esto el Trust Handoff Flaw y, citando a los investigadores de Pillar, lo define con precisión: el agente «se queda dentro de la caja y cumple todas las reglas», pero escribe un fichero, una configuración de hook, un intérprete de entorno virtual, una entrada de config de Git, una definición de tarea, «que alguna otra herramienta no sandboxeada consume cuando el turno del agente ya ha acabado».

Esa definición hace más trabajo del que parece. Traslada la frontera de seguridad, de un sitio que puedes configurar a una relación que probablemente no has inventariado: el conjunto de programas de la máquina del desarrollador que leen ficheros locales al proyecto y actúan sobre ellos sin preguntar.

¿Por qué los sandbox fallan siempre igual?

Porque en el diseño de sandbox reaparecen cuatro supuestos, y el comportamiento de un agente invalida los cuatro. La nota de la CSA los nombra, y conviene enunciarlos como errores de diseño y no como bugs, porque cada uno volverá en el próximo producto que lance un agente.

Nada de esto es exótico. Son los modos de fallo estándar de la seguridad perimetral, redescubiertos en un sitio nuevo, por equipos que publican rápido en una categoría que hace dos años no existía.

GitSpawn: el mismo fallo, en el fichero que todo repositorio tiene

Si el patrón todavía suena abstracto, la divulgación de Manifold Security a principios de septiembre de 2026 lo hace concreto, y es la ilustración más limpia de todo el argumento.

core.fsmonitor es un ajuste de rendimiento de Git. Su valor es un comando, que Git ejecuta para averiguar qué ficheros cambiaron. Git lo lee del propio .git/config del repositorio. Los agentes de código llaman a Git al arrancar para saber la rama y los ficheros modificados, así que el comando se ejecuta de inmediato, con los privilegios del usuario, antes incluso de que exista una ventana de aprobación que mostrar.

En lo que hay que ser preciso es en la entrega, y Manifold lo es: «clonar una URL hostil no hace nada, y tampoco un fetch ni un pull». Un git clone normal no transporta el .git/config del repositorio de origen. El repositorio tiene que llegar en forma de ficheros, con su carpeta .git ya dentro: un archivo .zip compartido, una carpeta sincronizada, una unidad compartida, una memoria USB. A partir de ahí, basta con abrir esa carpeta con un agente. No hay dependencia maliciosa, ni script post-install, ni código que revisar, ni nada que un escáner leyendo ficheros fuente marcaría. La carga está en un fichero de configuración que la mayoría de los desarrolladores nunca ha abierto.

Tres detalles merecen énfasis. Primero, los arreglos son por ruta y no por clase: Manifold reportó una segunda vía hacia Claude Code, a través de otro ajuste de Git, todavía viva en 2.1.252 después de parchear la primera. Segundo, varios agentes seguían confirmados como vulnerables en el momento de la divulgación: Manifold cuenta ocho hallazgos en siete agentes, cuatro de ellos todavía sin parche al publicar. Tercero, con los identificadores hay que ir con cuidado. Manifold no cita ningún CVE para su hallazgo en Claude Code, y el identificador de Claude Code con el que es fácil confundirlo, CVE-2026-55607, describe otro fallo: un escape de sandbox por confusión de rutas en los worktrees de Git, presente desde la 2.1.38 y corregido en 2.1.163, mucho antes de la 2.1.193 en la que Manifold confirmó el suyo. Si tu control es «hemos actualizado», tu control tiene un número de versión y una condición de carrera dentro.

Lo que de verdad protege es más estrecho de lo que parece, así que conviene ser exactos. Manifold da dos consejos. Si recibes un repositorio en forma de ficheros, inspecciona .git/config antes de abrir la carpeta con un agente, porque «cualquier ajuste que nombre un programa puede ejecutarlo». Si publicas un agente, o un simple script que llama a Git en segundo plano, sanea la configuración de Git en esas llamadas, por ejemplo con git -c core.fsmonitor=false status. El tercer paso es nuestro: actualiza el agente, la tabla de arriba indica qué versiones llevan el arreglo.

# Un repositorio recibido en forma de ficheros: lee su config antes de que lo abra un agente
cat .git/config

# En una herramienta o un script que llama a Git en segundo plano, sobrescribe la clave en la propia llamada
git -c core.fsmonitor=false status

El ajuste global que suele recomendarse en su lugar, git config --global core.fsmonitor false, no te protege. La documentación de Git enumera los ficheros de configuración por orden, sistema, luego global, luego el .git/config del repositorio, y precisa que se leen «en el orden indicado arriba, y el último valor encontrado tiene prioridad sobre los leídos antes». El valor del repositorio se lee después del tuyo global, así que un .git/config trampa gana. La opción -c es la excepción: según el manual de Git, su valor «prevalece sobre los valores de los ficheros de configuración».

Incluso bien hecho, esto resuelve core.fsmonitor y nada más. No hace nada por core.hooksPath, por .vscode/tasks.json, por un intérprete de venv, por un hook .claude, ni por la siguiente clave de configuración que alguien note que es ejecutable. No se parchea una propiedad de diseño.

Qué cubre de verdad un sandbox y qué no

Por hacer justicia al sandbox, que sí merece desplegarse: hace un trabajo real, y ese trabajo no es poca cosa. Solo es más estrecho que el discurso que lo rodea.

Las cuatro últimas filas son las que importan, y comparten una propiedad: el agente no hace nada prohibido. Los controles de perímetro detectan violaciones de frontera. Ninguna de estas lo es.

Queda un fallo más que pertenece aquí, porque es el más humano de todos. En marzo de 2026 se abrió una issue contra Claude Code señalando que el ajuste sandbox de ~/.claude/settings.json no se aplicaba cuando el agente corría dentro de la extensión de VS Code o Cursor: la extensión lanzaba el binario nativo sin la opción --sandbox, así que el perfil Seatbelt de macOS nunca llegaba a aplicarse, ni siquiera con sandbox.enabled: true. Quien lo reportó lo verificó escribiendo un fichero en ~/Desktop desde una sesión de Cursor. La issue se cerró como duplicada cuatro días después, y el único apaño que consta es el de quien la reportó: lanzar la CLI directamente, o usar hooks PreToolUse como guardia sustituta.

Sea cual sea su estado hoy, la clase de problema es permanente: un sandbox es una configuración, las configuraciones tienen superficies donde silenciosamente no se aplican, y un control que crees activo es peor que uno que sabes apagado.

Entonces, ¿qué se hace?

Quédate con el sandbox. Deja de tratarlo como el control. Y cierra el traspaso, que es donde está la exposición real.

1. 01

   Inventaría lo que lee ficheros del proyecto sin preguntar

   Es el paso que nadie da, y el que reclama la CSA. Lista los programas de una máquina de desarrollo que consumen ficheros del directorio de trabajo y actúan sobre ellos: el editor y sus extensiones, el servidor de lenguaje, el cliente Git, el perfil de shell, el runtime de contenedores, el lanzador de tareas, el watcher de tests. Esa lista es tu superficie de ataque real. El sandbox no aparece en ella.

2. 02

   Prefiere allowlists a denylists, y modela los argumentos

   Una denylist exige haber enumerado el sistema operativo. Una allowlist exige haber enumerado tu propio flujo de trabajo, que es un problema que sí puedes terminar. Y valida lo que un comando hace, no cómo se llama: git show estaba en una allowlist por su nombre.

3. 03

   Corta los daemons privilegiados

   Ninguna sesión de agente debería alcanzar el socket de Docker, la config de Kubernetes ni ningún endpoint local más privilegiado que ella. Esta es gratis. Cursor la cerró en una versión y Gemini CLI siguió en 0.58.0; OpenAI no ha publicado ninguna corrección para Codex.

4. 04

   Trata las escrituras de configuración como operaciones privilegiadas

   Un cambio en .git/config, .vscode/, .claude/, .cursor/, un intérprete de virtualenv o un workflow de CI no es un cambio de código. Es un cambio en lo que se va a ejecutar después. Merece una vía de aprobación distinta a la de un componente de React, y hoy suele recibir la misma.

5. 05

   Limpia el entorno antes que el sistema de ficheros

   Las variables de entorno viajan con el proceso. Un sandbox perfectamente aislado que hereda AWS_SECRET_ACCESS_KEY ha aislado el sistema de ficheros y publicado la credencial.

6. 06

   Pon la decisión sobre la escritura, no sobre el perímetro

   Cada punto anterior es una medida de endurecimiento que una ruta decidida acabará rodeando, porque todas son estáticas. Lo que cierra la clase es evaluar la acción en el momento en que ocurre, con capacidad de rechazarla.

Ese último paso es donde vive nuestro propio producto, así que lee los tres párrafos siguientes sabiéndolo. Si creemos que se deduce de la evidencia y no de nuestra hoja de ruta es porque la CSA llegó a la misma conclusión estructural sin vender nada, y porque el apaño que un usuario dejó en el propio gestor de issues de Anthropic era un hook PreToolUse.

Un hook se sitúa donde el sandbox no puede. Evalúa una llamada a herramienta antes de que se ejecute, lo que significa que ve la escritura misma: esta sesión está a punto de modificar .git/config, o de añadir un core.hooksPath, o de editar un fichero de workflow que se dispara en forks con permisos de escritura, o de invocar una herramienta cuya descripción cambió desde ayer. Son eventos discretos e inspeccionables, con sujeto y objeto. Un sandbox ve un proceso escribiendo bytes en un directorio permitido y no tiene base sobre la que objetar, porque no está pasando nada prohibido.

Es otra pregunta, no un muro más grueso. El sandbox pregunta «¿puede este proceso estar aquí?». La barrera pregunta «¿debe ocurrir esta acción concreta ahora?». El Trust Handoff Flaw existe precisamente porque la primera pregunta tiene una respuesta satisfactoria mientras la segunda no se llega a formular.

Y se degrada con honestidad. Las reglas en el contexto del agente mejoran lo que propone, que es una mejora real y probabilística. Los findings en el bucle hacen que un cambio propuesto se razone contra el estado real del repositorio. Solo el hook es determinista, y preferimos decir cuál de los tres es un control antes que insinuar que lo son los tres. La versión amplia de este argumento está en la seguridad de los agentes de código IA.

Preguntas frecuentes

¿Basta el sandbox para proteger un agente de código IA?

No, y las divulgaciones de 2026 muestran por qué con una claridad poco habitual. De los siete escapes reproducidos en Cursor, Codex CLI, Gemini CLI y Antigravity, la mayoría no consistió en salir del sandbox. El agente escribió un fichero dentro de su workspace permitido, y un proceso de confianza fuera del sandbox lo ejecutó después. El sandbox acota el daño de un proceso que se porta mal dentro de la frontera, y eso merece tenerlo. No puede hacer nada contra un agente que se porta perfectamente y entrega su carga a algo que nunca estuvo en la caja.

¿Qué es el Trust Handoff Flaw?

Es el nombre que la Cloud Security Alliance dio, en una nota de investigación del 22 de julio de 2026, al patrón que hay detrás de los escapes de sandbox de agentes de código en 2026. El agente se queda dentro de su frontera y cumple todas las reglas, pero escribe un fichero, una configuración de hook, un intérprete de entorno virtual, una entrada de config de Git o una definición de tarea, que alguna otra herramienta no sandboxeada consume cuando su turno ya ha acabado. La nota toma prestado el resumen de una línea de Pillar: si un agente puede escribir las entradas futuras de los sistemas, nunca estuvo sandboxeado.

¿Qué agentes de código tuvieron escapes de sandbox en 2026?

La investigación de Pillar Security reprodujo escapes en Cursor, el Codex CLI de OpenAI, el Gemini CLI de Google y Antigravity de Google, siete en total, de los que al menos cuatro recibieron parche del fabricante, según el recuento de la CSA. Por separado, la divulgación GitSpawn de Manifold Security del 1 de septiembre de 2026 cubrió goose (CVE-2026-72718, corregido en 1.44.0), Claude Code (sin CVE citado: la ruta core.fsmonitor se corrigió en 2.1.196 y una segunda ruta seguía abierta en 2.1.252), Hermes Agent (CVE-2026-71963), Qwen Code y Grok Build, estos tres últimos todavía sin parche en el momento de la divulgación. Manifold también encontró afectados a Codex y Cursor, ambos ya parcheados; el registro que publicó la propia OpenAI para el fallo de core.fsmonitor en Codex CLI es CVE-2026-19592, corregido en 0.131.0.

¿Puede un repositorio Git ejecutar código solo con abrirlo?

Sí, si te llegó en forma de ficheros y no mediante git clone. core.fsmonitor es un ajuste de rendimiento de Git cuyo valor es un comando que Git ejecuta para determinar qué ficheros cambiaron, y Git lo lee del propio .git/config del repositorio. Los agentes de código llaman a Git al arrancar, así que el comando corre con los privilegios del usuario antes de que aparezca ninguna ventana de aprobación. Ese es el hallazgo de GitSpawn, y Manifold es preciso con la entrega: un clon normal no transporta el .git/config del origen, así que el repositorio tiene que llegar con su carpeta .git ya dentro, como archivo .zip compartido, carpeta sincronizada, unidad compartida o memoria USB. Lee .git/config antes de abrir una carpeta así con un agente. git config --global core.fsmonitor false no sirve, porque Git lee el fichero del repositorio después del global y gana el último valor; solo git -c core.fsmonitor=false, en el propio comando, pasa por delante.

¿MicroVM, gVisor o contenedor para mi agente de código?

Elige según tus restricciones de rendimiento y GPU, porque para esta clase de amenaza la elección casi no importa. Firecracker da el aislamiento más fuerte, gVisor es un intermedio razonable con un kernel en espacio de usuario, y los contenedores son el suelo. Ninguno de los tres cambia que una extensión de Python no sandboxeada ejecute un intérprete que el agente modificó. Gasta el esfuerzo de decisión en qué puede escribir el agente y qué programas locales confían en él, y trata la primitiva de aislamiento como un ajuste de radio de daño.

¿Activar el ajuste de sandbox de mi agente lo sandboxea de verdad?

Verifícalo en lugar de suponerlo. En marzo de 2026 una issue contra Claude Code reportaba que sandbox.enabled: true en ~/.claude/settings.json no tenía efecto cuando el agente corría dentro de la extensión de VS Code o Cursor, porque la extensión lanzaba el binario nativo sin la opción --sandbox y el perfil Seatbelt de macOS nunca se aplicaba. Quien lo reportó lo confirmó escribiendo en ~/Desktop desde una sesión de Cursor. Prueba tu propia configuración intentando una escritura fuera del workspace y observando si se rechaza.

¿Qué es la seguridad agent-time y en qué se diferencia del sandbox?

El sandbox plantea una pregunta de perímetro: ¿puede este proceso estar en este sitio? La seguridad agent-time plantea una pregunta de acción: ¿debe ocurrir esta operación concreta ahora mismo?, y sabe negarse. La diferencia es decisiva ante el Trust Handoff Flaw, porque la escritura que causa la ejecución posterior no es una violación de perímetro y le parece del todo legítima a una capa de aislamiento. Una barrera que evalúa la llamada a herramienta ve que el destino es .git/config y la rechaza, cosa que ninguna fuerza de aislamiento hará.

¿Significa esto que los sandbox de agentes no sirven?

En absoluto, y abandonarlos sería la lección equivocada. Un sandbox acota de forma fiable el daño de una dependencia maliciosa, un comando destructivo o un bucle desbocado, y esos casos son frecuentes. La corrección es dejar de describirlo como contención frente a un agente adversario. Es un reductor de radio de daño que se coloca junto al control de salida de red, la higiene de credenciales y un punto de aplicación sobre las acciones mismas.