Construir un sandbox seguro para agentes de código en Windows

Los agentes de código viven en un lugar incómodo del sistema: necesitan permisos de un desarrollador real para ser útiles —leer, escribir, ejecutar comandos, crear ramas— y, al mismo tiempo, necesitan no salirse de ahí cuando algo se descarrila. En Linux y macOS, los sistemas operativos ofrecen primitivos pensados para esto: seccomp, bubblewrap, Seatbelt. Windows, en cambio, no traía algo equivalente listo para usar. La pregunta era cómo construir un sandbox propio que no convirtiera al agente en una experiencia impracticable.

Las dos opciones malas

Antes de tener un sandbox dedicado, un agente de código en Windows forzaba al desarrollador a elegir entre dos extremos. Aprobar cada comando, incluso los de sólo lectura, mata el principal beneficio del agente: ahorrarse el trabajo tedioso. Habilitar "modo acceso total" deja al modelo ejecutar lo que quiera sin supervisión. Ninguna de las dos vías sobrevive a un día de uso real.

Lo que Windows sí ofrece —y por qué no alcanzaba

El sistema tiene primitivos como AppContainer, Windows Sandbox y Mandatory Integrity Control. AppContainer es un modelo de aislamiento basado en capacidades, pensado para apps que declaran exactamente qué necesitan. Suena ideal hasta que se piensa qué hace un agente de código: lanza shells, invoca Git, ejecuta builds, instala paquetes, decide en cada paso qué binario correr. El perfil "aplicación acotada" simplemente no encaja.

Windows Sandbox, por su parte, es una máquina virtual descartable. Robusta para experimentos puntuales, pero demasiado pesada y aislada para integrarse con el flujo de un editor que tiene que ver el workspace del usuario.

Del "unelevated" al "elevated"

La primera versión —pensada como prueba— corrió el agente con permisos reducidos respecto al usuario. Funcionaba, pero arrastraba complicaciones: muchas operaciones legítimas requerían escalar y la experiencia se sentía frágil. La segunda versión invirtió el modelo: el sandbox se ejecuta con privilegios suficientes y aplica restricciones explícitas hacia adentro. Escrituras confinadas al directorio de trabajo, sin acceso a internet por defecto, lectura amplia para que el agente pueda razonar sobre el proyecto. Cada proceso hijo hereda el mismo perímetro.

El equilibrio que vale la pena

Un sandbox demasiado estricto vuelve al agente inútil; uno demasiado permisivo lo vuelve peligroso. El diseño correcto persigue una propiedad sencilla: por defecto, el agente puede hacer lo razonable sin pedir permiso, y no puede hacer lo riesgoso aunque el modelo se equivoque. Cuando el sandbox cumple esa promesa, el desarrollador deja de tener que vigilar cada comando.

Este patrón se generaliza más allá de Windows. En Arman Solutions construimos integraciones de agentes con la misma filosofía: el perímetro de ejecución se diseña primero, después se entrena al agente para vivir adentro de ese perímetro. La velocidad importa, pero llega tarde si no llega segura.