Docker anunció recientemente Docker Sandboxes, un entorno ligero y contenerizado diseñado para que los agentes de código trabajen con los archivos de tu proyecto sin exponer toda tu máquina. Es una adición bien pensada al ecosistema y una señal clara de que las herramientas para agentes están madurando.
El sandboxing ayuda a resolver un problema real: los agentes necesitan espacio para operar. Instalan paquetes, ejecutan código y modifican archivos, y darles esa libertad sin exponer tu laptop le da tranquilidad a todo el equipo.
Pero el aislamiento del entorno solo cubre una parte del riesgo. Un sandbox controla dónde se ejecuta el código y qué archivos locales puede modificar el agente. No controla qué puede hacer ese agente en otros sistemas, ni con qué nivel de confianza interpreta la tarea que le diste.
Y ahí es donde aparecen la mayoría de los problemas reales.
Lo que Docker Sandboxes resuelve bien
El enfoque de Docker está bien alineado con lo que los desarrolladores necesitan hoy:
- Aislamiento del entorno
- Límites del sistema de archivos
- Espacios de trabajo reproducibles
- Protección contra código local no confiable o descontrolado, incluidas acciones destructivas en el sistema de archivos
- Compatibilidad con agentes de código modernos como Claude Code y Gemini CLI
Para flujos de trabajo locales, esto reduce una enorme categoría de riesgo sin frenar a nadie. Probablemente se convertirá en la forma predeterminada en que los agentes de código corren en computadoras de escritorio.
Pero incluso dentro de un contenedor perfecto, un agente puede tomar la decisión equivocada a nivel estratégico.
Dónde ocurren realmente la mayoría de las fallas de los agentes
Los equipos que experimentan con agentes de código han visto un patrón consistente en toda la industria:
El agente se comporta correctamente, pero fuera de la intención de la solicitud.
Algunos ejemplos comunes:
- Hacer merge de un PR que solo debía revisarse
- Reescribir archivos de configuración que considera desactualizados
- Borrar datos de prueba que “parecen sin uso”
- Refactorizar archivos de formas que pasan las pruebas pero cambian el comportamiento sutilmente
- Limpiar directorios de forma más agresiva de lo esperado
- Tratar contenido ambiguo (logs, comentarios, correos) como instrucciones
- Ejecutar comandos destructivos contra bases de datos en producción por falta de contexto
Sin exploit. Sin escape del sandbox. Sin malicia.
Solo capacidad, confianza y permisos más amplios de lo que la tarea requería.
Estas fallas no son causadas por una ejecución de código insegura: el sandboxing de ejecución es una base necesaria y cumple bien su función. Surgen porque el sandboxing por sí solo suele aislar únicamente la ejecución del agente (el proceso y el sistema de archivos en el que corre), sin limitar las capacidades que el agente está autorizado a usar en otros sistemas. El sandboxing añade restricciones sobre dónde puede ejecutar código el agente y a qué recursos locales puede acceder. No restringe:
- qué permisos tiene el agente
- qué herramientas o APIs puede llamar
- qué acciones pueden realizar esas herramientas
- con qué amplitud interpreta el agente las instrucciones ambiguas
Esos controles viven por encima del límite del sandbox, en las capas de decisiones, permisos y políticas.
Un sandbox puede evitar que acciones no deseadas afecten tu máquina. No puede determinar si la acción en sí era apropiada.
Eso es un tipo diferente de seguridad.
Una vez que trazas ese límite con claridad, la forma de una arquitectura de agentes más segura se vuelve mucho más obvia.
Un enfoque más completo para la seguridad de los agentes
Este es el modelo por capas al que muchos equipos han llegado al incorporar agentes en flujos de trabajo reales. Las capas son complementarias y trabajan juntas. En la práctica, los equipos suelen usar varias al mismo tiempo, incluido el sandboxing, para lograr una seguridad real.
1. Acceso de mínimos privilegios
Los agentes nunca deberían heredar el conjunto completo de capacidades que tiene una persona.
Limitar por defecto previene la mayoría de los resultados no deseados:
- Lectura vs. escritura
- Acceso delimitado a directorios o repositorios específicos (aplicado en la capa de sistema de archivos o autorización)
- Revisión vs. merge
- Comentario vs. commit
Si un agente no tiene permiso para realizar una acción sensible, no puede ejecutarla por accidente.
2. Autenticación y autorización correctas
El aislamiento del entorno protege la máquina. Los permisos protegen los sistemas.
Los patrones más sólidos que están surgiendo incluyen:
- OAuth con alcance de usuario y scopes mínimos y precisos
- Autorización just-in-time en lugar de tokens globales
- Cero exposición de credenciales al modelo
- Control granular a nivel de herramienta/acción
Esto evita que acciones “confiadas pero no deseadas” alcancen más allá de su ámbito apropiado.
3. Sandboxing de ejecución (la parte de Docker)
Esta capa se encarga de:
- ejecución de código no confiable
- dependencias locales
- instalación de paquetes
- contención del runtime
- límites de recursos
La solución de Docker encaja muy bien en esta capa.
4. Auditoría y trazabilidad
Cuando algo inesperado ocurre, los equipos necesitan ver:
- qué vio el agente
- qué entendió
- qué decidió
- qué ejecutó
- qué permitió el sistema
Esto no es solo para seguridad: también sirve para depuración y construcción de confianza.
5. Aprobación humana para acciones de alto impacto
Los agentes hacen borradores. Los agentes proponen. Los agentes preparan.
Pero los merges, eliminaciones, cambios de permisos y otras operaciones irreversibles todavía se benefician de un paso de revisión humana.
Piénsalo menos como una restricción y más como un guardarrail alrededor de la intención.
Cómo trabajan juntas estas capas
- Sandboxing protege el entorno
- Mínimos privilegios protege el sistema
- Auth protege identidad y acceso
- Auditabilidad protege comprensión
- Revisión humana protege la intención
Cuando estas capas se alinean, los agentes se vuelven considerablemente más seguros, no porque los modelos mejoren, sino porque la arquitectura lo hace.
Un futuro colaborativo para la seguridad de los agentes
El anuncio de Docker es una señal positiva. Refleja un cambio más amplio hacia tratar la seguridad de los agentes como arquitectura, no como algo secundario.
El sandboxing de ejecución es una base importante. Pero a medida que los agentes van más allá de los flujos de trabajo locales de un solo usuario, los equipos necesitan cada vez más controles que estén por encima de la capa de ejecución: autorización con alcance de usuario, permisos a nivel de herramienta, auditabilidad y visibilidad centralizada del comportamiento de los agentes. Un enfoque que vemos ganando terreno es centralizar esas preocupaciones en un plano de control dedicado, en lugar de reconstruirlas dentro de cada agente o herramienta. Este es el modelo detrás de Arcade.dev: un runtime de MCP con autorización como prioridad que maneja permisos, gobernanza y visibilidad en agentes multiusuario, sin depender de dónde ni cómo se ejecutan esos agentes.
El sandboxing mantiene segura la ejecución. La autorización centralizada y la gobernanza ayudan a mantener el comportamiento de los agentes alineado a medida que los sistemas escalan.
