Modo YOLO sin dejar mi portátil en manos de un agente de IA

Un contenedor de desarrollo convencional resulta útil para encapsular las dependencias, pero no constituye por sí solo una barrera de seguridad sólida.

El atajo habitual consiste en montar el socket de Docker del host para que una herramienta dentro del contenedor pueda crear y ejecutar otros contenedores. En la práctica, eso otorga a la herramienta el control del daemon de Docker del host. En el caso de un agente autónomo, socava buena parte del aislamiento buscado.

En Docker Sandboxes, el enfoque es distinto. Cada sandbox se ejecuta dentro de una microVM con entorno Linux, sistema de archivos, red y Docker Engine propios.

Dentro de ese entorno, el agente puede:

• instalar paquetes con sudo
• construir imágenes
• iniciar contenedores
• ejecutar Docker Compose
• modificar su entorno de desarrollo

Puede hacer todo eso sin obtener acceso al daemon de Docker del host ni a archivos situados fuera del espacio de trabajo que he decidido compartir.

El objetivo no es evitar por completo que el agente cause daños, sino reducir el alcance de esos daños y delimitarlo mejor.

Docker Sandboxes permite compartir un proyecto de dos formas prácticas.

Modo directo

El proyecto se monta con permisos de lectura y escritura. Los cambios que hace el agente aparecen de inmediato en mi copia de trabajo local. Utilizo este modo para el desarrollo habitual porque el agente y yo podemos trabajar sobre los mismos archivos.

La contrapartida está clara: el agente aún puede dañar el repositorio.

Modo de clonación

Cuando pruebo agentes que aún no conozco bien, realizo experimentos potencialmente destructivos o trabajo en paralelo, el modo de clonación ofrece una barrera más estricta. El repositorio del host se monta en modo de solo lectura, mientras el agente trabaja en un clon privado dentro de la sandbox. Los cambios solo llegan a mi copia de trabajo local cuando decido importarlos.

El modo de clonación impide modificar el repositorio, pero no consultar su contenido. Los archivos del repositorio, incluso los que Git ignora, pueden seguir visibles a través del montaje de solo lectura. Por eso, mantengo los secretos fuera del espacio de trabajo.

Una sandbox vacía resuelve el problema del aislamiento, pero no el de la configuración.

No quería que cada nueva sesión comenzara con una larga explicación sobre las bibliotecas nativas que necesita el proyecto, las versiones de las herramientas que exige la compilación o la forma de configurar el entorno de modelos locales.

Docker Sandboxes permite definir configuraciones de proyecto reutilizables llamadas kits. El kit de mi proyecto recoge las herramientas y la configuración que necesita el agente:

• dependencias nativas de compilación
• herramientas de desarrollo de Rust
• dependencias para las pruebas en el navegador
• variables de entorno
• el acceso a la red necesario durante la configuración inicial

La configuración concreta importa menos que el principio que hay detrás: el conocimiento necesario para preparar el entorno queda documentado junto al proyecto, en vez de tener que reconstruirlo de memoria.

Un agente de IA puede esbozar un spec.yaml específico para el proyecto tras inspeccionar el repositorio y preguntar por lo que no puede deducir: paquetes del sistema, comandos de compilación y de pruebas, servicios en segundo plano, acceso a la red, puertos y credenciales gestionadas por el host.

En una aplicación web, por ejemplo, el kit puede incluir Playwright y un navegador sin interfaz gráfica dentro de la sandbox. Así, el agente puede renderizar páginas, ejecutar pruebas de extremo a extremo y tomar capturas de pantalla para revisarlas visualmente. Si el agente y el modelo elegidos admiten imágenes como entrada, el propio agente también puede examinar esas capturas. Aun así, hay que revisar el archivo generado y validarlo con sbx kit validate.

También sirve como registro de problemas y soluciones

La primera versión del kit era mucho más sencilla. Fue creciendo cada vez que la realidad desmintió alguna de mis suposiciones.

En una versión, se sustituía el contenido de la variable PATH en lugar de añadirle nuevas rutas. Eso eliminaba rutas incorporadas por el entorno de ejecución de la sandbox e impedía que el agente de programación arrancara correctamente.

En otra, RUSTFLAGS se definía de forma global y sobrescribía sin querer una opción específica del proyecto que la CI utilizaba para excluir las pruebas que realizan solicitudes reales a proveedores de modelos.

Esos problemas podrían haber quedado relegados al historial del shell o a mis notas personales. Ahora, en cambio, las correcciones acompañan a la propia configuración y explican el motivo de cada ajuste.

Ahí reside el verdadero valor del kit. No se limita a instalar software: convierte el conocimiento sobre el entorno en código del proyecto que puede revisarse, versionarse y mejorarse.

Para el desarrollo habitual, creo una sandbox con nombre y la configuro con el kit del proyecto:

# Otros agentes compatibles son claude, gemini y opencode.
sbx run codex \
  --name aitopus \
  --kit ./sandbox/aitopus/

Este comando utiliza el montaje directo del proyecto, por lo que los cambios del agente aparecen en mi árbol de trabajo.

Cuando necesito una barrera más estricta, puedo crear otra sandbox en modo de clonación:

sbx run --clone --no-share-skills codex \
  --name aitopus-review \
  --kit ./sandbox/aitopus/

La configuración inicial puede llevar bastante tiempo porque el entorno incluye cadenas de herramientas nativas, binarios de navegadores y dependencias de compilación. La ventaja es que el estado de la sandbox y las cachés de compilación persisten entre sesiones.

Una vez completada la configuración inicial, puedo volver a conectarme a esa sandbox en lugar de reconstruir el entorno desde cero.

Un agente de programación sigue necesitando Internet. Puede tener que conectarse al proveedor del modelo, consultar registros de paquetes y repositorios de código fuente, o descargar archivos de versiones publicadas.

En las sesiones más sensibles, parto de una política de red restrictiva y permito únicamente los servicios que necesitan el agente y el proceso de compilación.

El proxy de credenciales de Docker Sandboxes permite conservar en el host las credenciales compatibles y adjuntarlas solo a las solicitudes aprobadas. Es preferible a copiar una clave API de larga duración en la sandbox y olvidar después dónde se guardó.

Aun así, el control de red tiene límites. Un servicio autorizado puede recibir la información que el agente le envíe. Restringir los destinos reduce la exposición; no significa que todas las solicitudes salientes estén justificadas.

Una sandbox limita el acceso, pero no garantiza que el código sea correcto. Reviso el trabajo del agente como si se tratara de una pull request de origen no fiable.

• Corrección. El agente puede introducir una dependencia vulnerable, interpretar mal un requisito o producir código que pase las pruebas pero contradiga el diseño previsto.
• Efectos en el host. En modo directo, el agente puede modificar mucho más que los archivos de código fuente habituales. Los hooks de Git, los flujos de trabajo de CI, las tareas del IDE, los scripts de compilación y la configuración del agente pueden acabar ejecutando código en el host.
• Cambios en el repositorio. El modo de clonación impide escribir directamente en la copia de trabajo del host, pero cualquier cambio que se reincorpore debe revisarse.
• Plataformas de destino. Una sandbox de Linux ofrece un entorno de trabajo más seguro y coherente, pero no es una prueba de que la aplicación terminada funcione correctamente en todas las plataformas de destino.

Las solicitudes de permiso son útiles cuando no existe una barrera más sólida, pero son un mal sustituto de una barrera diseñada de antemano.

Dentro de una microVM dedicada, el agente puede trabajar con mucha libertad. Puede instalar compiladores, modificar paquetes, crear contenedores y completar todo un ciclo de depuración sin tener que esperar una aprobación después de cada comando.

Le doy deliberadamente acceso al repositorio del proyecto, no al daemon de Docker del host ni a archivos ajenos al proyecto. Desde luego, tampoco le doy acceso sin restricciones al resto del portátil.

El resultado no solo es más seguro: también me permite ser más productivo.

Estoy menos pendiente de aprobar operaciones rutinarias, dedico menos tiempo a reparar mis cadenas de herramientas locales y necesito menos espacio en los prompts para explicar el entorno de desarrollo. El agente dispone de libertad suficiente para avanzar; yo conservo un perímetro claro que puedo revisar.

El mismo principio se aplica a la IA local: elegir dónde se realiza el procesamiento, decidir qué información puede cruzar ese límite y mantener el resto bajo control local.

Esta es la versión del modo YOLO con la que me siento cómodo:

no se trata de confiar ciegamente en un agente, sino de saber que he elegido el perímetro en el que quedarán confinados sus errores.

Nota: los kits de Docker Sandboxes siguen siendo experimentales. Consulta la documentación más reciente antes de utilizar comandos o campos de configuración concretos en un flujo de trabajo de producción.