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

Clonar un repositorio ya basta. 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.

Dos detalles merecen énfasis. Primero, los arreglos son por ruta y no por clase: Manifold reportó una segunda vía hacia Claude Code 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. Si tu control es «hemos actualizado», tu control tiene un número de versión y una condición de carrera dentro.

La mitigación que recomienda Manifold merece hacerse hoy, cabe en un comando y es una buena muestra de lo estrecho que resulta un arreglo por incidencia:

# Auditar un repositorio que vas a abrir con un agente
git config --get core.fsmonitor

# Desactivar el mecanismo globalmente
git config --global core.fsmonitor false

# O neutralizarlo en las llamadas en segundo plano
git -c core.fsmonitor=false status

Eso cierra core.fsmonitor. 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, y el apaño propuesto era 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.

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.

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.

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 y eliminó una clase entera en tres productos.

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.

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.

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 sugerido 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 lo resume así: 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. Por separado, la divulgación GitSpawn de Manifold Security en septiembre de 2026 cubrió goose (CVE-2026-72718), Codex (CVE-2026-19592), Claude Code (CVE-2026-55607) y Hermes Agent (CVE-2026-71963), con Qwen Code y Grok Build también confirmados vulnerables en ese momento.

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

Sí, y ese es el hallazgo de GitSpawn. 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. Auditarlo es un comando, git config --get core.fsmonitor, y desactivarlo globalmente es git config --global core.fsmonitor false.

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