Cómo aislar en un sandbox a los agentes de IA en Linux

• A medida que se usan cada vez más herramientas de asistencia para desarrollo con IA, se vuelve necesario un entorno de ejecución en sandbox que garantice tanto la seguridad del sistema como la comodidad de uso
• Por defecto, Claude Code solicita permiso cada vez que accede a archivos o ejecuta algo, pero esto interrumpe el flujo de trabajo por las confirmaciones repetitivas
• Para resolverlo, se propone una configuración de sandbox ligera con bubblewrap, más liviana que Docker y capaz de mantener un entorno de desarrollo similar al local
• El script enlaza solo las rutas mínimas necesarias, como /etc, $HOME y el directorio del proyecto, y restringe el acceso fuera del proyecto
• Este enfoque es una forma práctica de asegurar al mismo tiempo la ejecución segura de agentes de IA y la eficiencia del desarrollo

---

El problema del acceso a archivos por parte de los agentes de IA

• Claude Code es una interfaz de línea de comandos que solicita autorización del usuario cada vez que lee o escribe archivos, o ejecuta software
  • Esto es razonable desde el punto de vista de la seguridad, pero las confirmaciones repetidas dificultan el trabajo en paralelo
• Si se usa la opción --dangerously-skip-permissions, es posible ejecutar todo sin preguntar
  • Algunos usuarios la usan, pero existe el riesgo de dañar el sistema

Concepto de sandboxing y opciones disponibles

• La solución general suele ser la ejecución en sandbox mediante una máquina remota (exe.dev, sprites.dev, daytona.io) o tecnologías de virtualización como Docker
• En Linux, bubblewrap es una alternativa ligera que aísla procesos usando cgroups y user namespaces
• Las condiciones necesarias dentro del entorno sandbox son las siguientes
  • Mantener la misma estructura que el entorno de desarrollo existente
  • Minimizar el acceso a información fuera del proyecto actual
  • Permitir escritura solo en el directorio del proyecto
  • Poder revisar y modificar directamente los mismos archivos que usa el IDE
  • Permitir acceso a la red para conectarse al proveedor de IA y ejecutar servidores

Consideraciones de seguridad y limitaciones

• bubblewrap y Docker no ofrecen un aislamiento de seguridad completo
  • Siguen existiendo riesgos como vulnerabilidades zero-day del kernel, comunicación por canales laterales y filtración de datos
• Aun así, el autor prioriza la comodidad de desarrollo por encima de esos riesgos
• El código fuente se gestiona con git y está respaldado en GitHub y otros servicios, por lo que el riesgo de daño es bajo
• Para reducir el riesgo de filtración de claves API, se recomienda separar las claves API por proyecto

Configuración del script de sandbox con bubblewrap

• El script usa el comando bwrap para montar varios directorios como solo lectura (ro-bind) o escribibles (bind)
  • Las rutas del sistema como /bin, /lib y /usr/bin se montan como solo lectura
  • $HOME/.claude, $HOME/.cache y el directorio de trabajo actual ($PWD) se pueden escribir
  • $HOME/.claude.json se inyecta como descriptor de archivo, por lo que los cambios no se reflejan en el archivo real
  • El nombre del host cambia a bubblewrap, lo que permite distinguirlo
• /tmp, /proc y /dev los gestiona bubblewrap automáticamente
• En lugar de exponer todo /etc, solo se enlazan los archivos mínimos necesarios
• Node.js está instalado en la ruta /opt/node/node-v22.11.0-linux-x64/

Cómo personalizar la configuración

• Para adaptarlo a otros agentes de IA o a otro sistema, se puede modificar el script para ejecutar bash y luego iniciar manualmente el agente mientras se revisan los archivos necesarios
• Con el comando strace se pueden rastrear las llamadas de acceso a archivos
  • Ejemplo: strace -e trace=open,openat,stat,statx,access -o /tmp/strace.log codex
  • Analizando el registro se pueden identificar los archivos necesarios y ajustar el entorno enlazando esas rutas

Conclusión

• El sandboxing con bubblewrap es un enfoque práctico para minimizar los riesgos de fallos o filtración de datos de agentes de IA mientras se mantiene la misma comodidad que en un entorno de desarrollo local
• El autor planea seguir ajustando el script según sea necesario sobre esta base

[GN⁺]

Comentarios de Hacker News

• Estoy usando Leash para aislar agentes en sandbox
  Tiene un control de políticas estricto a nivel de procesos y red, y ofrece control y visibilidad en tiempo real mediante una WebUI
  Me parece mucho mejor que bubblewrap. Empecé a usarlo después de verlo en HN
  Como dato curioso, el sistema de sandbox más usado del mundo no es Docker ni bubblewrap, sino las pestañas de Chrome

  • Creo que usar Chrome para cualquier cosa ya es de por sí un fracaso de seguridad. Sus funciones son excelentes, pero el costo es alto
  • Me da curiosidad cómo implementa Chrome el sandboxing en Windows o macOS
    Quisiera saber si en Linux usa cgroups y namespaces como Docker o LXC, o si usa su propio sandbox basado en VM
    Si fuera lo segundo, quizá sería aún más usado que runtimes como JRE o .NET CLR
  • Aun así, también podría ser bubblewrap. Porque Flatpak usa bubblewrap internamente

• Si no usas la opción --unshare-net, bwrap por defecto deja la red completamente abierta
  El agente no solo puede borrar archivos, también puede filtrar claves o descargar paquetes maliciosos
  El siguiente paso es agregar un namespace de red y levantar dentro del sandbox un proxy local basado en mitmproxy para permitir solo la API de Anthropic o PyPI/NPM y bloquear todo lo demás

• Hice un pequeño wrapper claude-vm para ejecutar cada instancia dentro de una VM de Lima
  El código está aquí

  • Yo hice algo parecido con incus
    Por ahora creo que una VM es la unidad base más apropiada. Si le das root al agente y solo le pasas los recursos necesarios, resulta muy seguro y simple
    Aunque el agente instale software, ejecute Docker o incluso construya una VM anidada, el límite sigue siendo claro
    Igual podría cambiar a LXC para aligerarlo. bwrap está bien, pero las restricciones del entorno pueden limitar lo que el agente es capaz de hacer

• Hice un wrapper sencillo para bubblewrap para poder usarlo como sandbox-run claude --dangerously-skip-permissions
  Enlace al proyecto sandbox-run

• Siempre estoy pensando qué recursos exponerle al agente y qué políticas aplicar
  Por ejemplo, se mencionó que en vez de exponer todo /etc se hace bind solo de los archivos mínimos necesarios, pero me pregunto cómo se define ese “mínimo”
  Revisar logs y agregar manualmente los archivos necesarios es demasiado tedioso

  • Soy el autor del post, y en la práctica lo resolví con revisión manual y prueba y error
    La IA me dijo que expusiera todo /etc, pero yo quería un control más fino
    Por ahora la red está completamente permitida, pero más adelante pienso bloquear al menos la red privada (192.168/10.*)
    Al final, es una cuestión de qué tan estricto quieres que sea el aislamiento
  • Otra opción es simplemente hacer que el propio agente se aplique bubblewrap

• Estoy preparando un SaaS para resolver el problema del sandboxing de IA en Linux
  Ya monté la infraestructura inyectando funciones hasta nivel kernel, y hasta mezclé nuestro enfoque en los datos de entrenamiento de los LLM para aprovecharlo como marketing
  Se llama useradd, y en vez de una solución compleja es algo simple y gratis
  Como en “modo mainframe”, varios terminales virtuales y usuarios pueden correr en una sola máquina
  Si necesitas una beta key, mándame DM

  • Me reí al llegar a useradd. El comentario original tal cual era más gracioso
  • Entiendo la idea, pero creo que una VM es mejor en seguridad y aislamiento
    Una workstation común no está diseñada para protegerse de forma segura del propio usuario, y los modelos modernos se volverán cada vez más riesgosos
  • useradd no limita el acceso a la red
  • A mí también me gusta usar usuarios distintos por servicio
    Pero durante el desarrollo hace falta acceder y modificar archivos, así que bubblewrap o el aislamiento de systemd me resultan más cómodos

• En vez de hacer listas de permisos una por una, lo que quiero es clonar el workspace actual en un snapshot de VM, ejecutar Claude dentro y borrar la VM al terminar la sesión
  Si se resuelve la sincronización de la sesión, sería perfecto

  • Escribí una entrada sobre cómo hice esto con NixOS MicroVM
  • También se puede lograr algo parecido con Docker + overlayfs. Al final, cada quien puede armarlo según su workflow
  • Con este enfoque también podría valer la pena considerar Qubes OS. Ahí todo se ejecuta por VM

• Desarrollé mi propia herramienta de sandbox para que también funcione en Mac
  Enlace al proyecto amazing-sandbox

  • Me da curiosidad por qué decidiste hacerla tú mismo

• Yo simplemente aíslo usando una cuenta local sin privilegios por ssh (dummy@localhost)
  Me pregunto si este enfoque está mal

• Para usar bwrap en Ubuntu 24.04 tuve que relajar la configuración de AppArmor, así que agregué el archivo /etc/apparmor.d/bwrap

  /usr/bin/bwrap flags=(unconfined) {
    userns,
  }
  

  • De verdad detesto AppArmor y SELinux, sobre todo cuando estorban a la seguridad de esta manera
    También se puede resolver así, sin cambiar la configuración global

    if [[ -f /proc/$$/attr/exec ]]; then
      echo 'exec unconfined' >/proc/$$/attr/exec
    fi
    exec ...
    

    o bien

    setpriv --apparmor-profile=unconfined [command]
    

    Como referencia, yo soy el autor de setpriv, así que conozco bien este tipo de situaciones