Pasamos mucho tiempo pensando en cómo darles a los agentes de AI acceso seguro a sistemas reales. En parte por curiosidad personal, y en parte por el trabajo que hacemos en Arcade.dev construyendo infraestructura para agentes, especialmente las partes que se rompen cuando dejas atrás los demos de juguete.
Entonces, cuando Docker lanzó Docker Sandboxes, que permiten a los agentes de AI correr dentro de un contenedor aislado en lugar de directamente en tu laptop, quisimos probarlo en serio. No como demo, sino con un codebase real, haciendo el tipo de cosas que cada vez más se les pide a los agentes.
Lo probamos con Claude Code. Esto es lo que fue esa experiencia en la práctica.
TL;DR
- La configuración es genuinamente fácil
- El aislamiento funciona exactamente como promete
- Al principio se siente fluido: olvidas que estás en un sandbox
- Los flujos de desarrollo reales revelan fricciones rápido
- Configurar el entorno, los binarios y el acceso a APIs es doloroso
- Base sólida, pero no algo que usaríamos a diario (todavía)
Por qué lo probamos
Una de las mayores preocupaciones con los agentes de código no es si pueden editar archivos, sino si van a hacer algo no deseado cuando tienen acceso real.
En la práctica, los fallos que vemos casi nunca son sobre un agente borrando archivos fuera de su workspace; el sandboxing ya limita eso. Lo que más preocupa son los agentes que tocan sistemas equivocados, usan credenciales incorrectas o ejecutan comandos en contextos que no entienden del todo.
Docker Sandboxes prometen reducir parte de ese riesgo aislando la ejecución. Eso valía la pena probarlo.
Configuración: sorprendentemente fluida
Empezar fue sencillo:
- Actualiza a la versión más reciente de Docker
- Corre
docker sandbox run claude - Entra a Claude Code
Una vez iniciado el sandbox, Claude podía ver sololos archivos de nuestro directorio de trabajo, nada más en la máquina.
Desde el punto de vista de la seguridad en ejecución, esto es una victoria real. No hay ambigüedad sobre qué puede tocar el agente localmente, y eso genera confianza de inmediato.
Al principio se siente casi mágico
Con tareas simples, la experiencia es casi indistinguible de correr Claude directamente.
Claude edita archivos, lee código y propone cambios sin fricción visible. Por un momento nos olvidamos de que estábamos dentro de un sandbox, lo cual es probablemente el mejor cumplido que puedes hacerle a este tipo de herramienta.
Lograr aislamiento sin que te lo recuerde constantemente es difícil de conseguir, y Docker lo clava en esa parte.
Donde las cosas empezaron a romperse
En el momento en que le pedimos a Claude hacer algo más cercano al desarrollo real, todo cambió.
Le pedimos que escribiera algunas pruebas y luego que corriera nuestra suite de tests con make test.
, falló de inmediato: make no estaba instalado en el sandbox.
Claude intentó recuperarse corriendo los comandos de test manualmente, pero eso también falló porque algunas de nuestras dependencias de desarrollo no son compatibles con el sistema operativo del sandbox.
Nada de esto sorprende si has trabajado con contenedores antes, pero es un recordatorio de que el aislamiento de ejecución y la paridad de entorno son problemas muy distintos.
Donde la fricción realmente se hace visible es en la configuración del entorno
El mayor dolor llegó cuando entraron las APIs.
Una de las pruebas requería una API key. Como el sandbox no se inició con esa variable de entorno, no podíamos agregarla simplemente.
En cambio, tuvimos que:
- Detener el sandbox
- Borrarlo
- Reiniciarlo con la variable de entorno
- Perder toda la conversación de Claude
Desde la perspectiva de un flujo con agentes, ese es un costo alto por un error pequeño de configuración.
Los agentes son iterativos por naturaleza. Perder contexto por cambios en el entorno rompe ese ciclo de una forma que nadie tolera por mucho tiempo.
Un supuesto que no nos dimos cuenta de que estábamos haciendo
También nos dimos cuenta de que teníamos un supuesto implícito: esperábamos que Claude trabajara en un git worktree, no directamente en nuestro directorio de trabajo.
En cambio, el sandbox monta el código directamente.
Eso genera algunos problemas:
- No puedes dejar fácilmente que el agente corra tareas largas en segundo plano
- Terminas compitiendo con el agente si intentas editar los mismos archivos al mismo tiempo
- Si el agente borra o reescribe partes grandes del repo, el impacto es inmediato
En ese punto, empiezas a ver el límite de lo que el sandboxing de ejecución realmente protege, y lo que no.
Lo que Docker Sandboxes hace bien
Para ser justos, hay mucho que destacar:
- La configuración inicial es fácil
- El aislamiento del sistema de archivos funciona como promete
- La integración con Claude se siente natural
- Para proyectos pequeños o nuevos, probablemente es suficiente
- Muchas veces olvidas que estás en un sandbox
Si tu principal preocupación es la seguridad local, Docker Sandboxes resuelven un problema real.
Donde tiene dificultades hoy
Desde la perspectiva del desarrollo diario, todavía hay algunas fricciones:
- Solo compatible con Claude
- Reinstalar binarios que ya existen localmente
- Las variables de entorno requieren reinicios completos
- UX de CLI con demasiado Docker para configuración básica
- Perder el contexto del agente cuando hay que reiniciar el sandbox con nueva configuración
Ninguno de estos problemas es catastrófico por sí solo, pero juntos limitan la frecuencia con la que lo usaríamos en trabajo real.
Lo que el sandboxing no resuelve
Una cosa que esta experiencia nos confirmó es que la seguridad del sistema de archivos suele ser la parte menos interesante del riesgo en agentes.
En la práctica, nos preocupa mucho más:
- qué servicios puede contactar un agente
- qué credenciales está usando
- si entiende la diferencia entre entornos de prueba y producción
- qué acciones puede tomar en nombre de un usuario
El sandboxing de ejecución responde *“¿Dónde puede correr este código?”* No responde “¿Qué debería tener permitido hacer este agente?”
Esa distinción queda muy clara cuando intentas usar estas herramientas en sistemas reales. Y es una razón clave por la que muchas empresas han elegido implementar Arcade.
Reflexiones finales
Docker Sandboxes se sienten como un avance importante. El aislamiento de ejecución funciona y la integración con Claude está bien pensada.
Pero los flujos de desarrollo reales son complicados. Dependen de paridad de entorno, contexto de larga duración, APIs, credenciales y permisos que no caben de forma ordenada en un contenedor limpio.
Desde nuestra perspectiva, esto se siente como infraestructura sólida, solo una capa de un stack más amplio que los equipos necesitarán a medida que los agentes pasen de experimentos a flujos de trabajo reales.
_________________________________________________________
¿Te interesa tener más control sobre el riesgo de agentes en tu empresa?Empieza con Arcade gratis
