Sandboxes para agentes de codificación

Un agente de codificación que puede leer tu repositorio, ejecutar comandos shell, editar archivos, instalar paquetes, construir contenedores, hablar con APIs externas y abrir sesiones de navegador no es sólo un autocompletado mejor. Es un entorno de ejecución con un modelo de lenguaje adjunto. La propia documentación de Claude Code lo describe como una herramienta de codificación ágil que lee tu código base, edita archivos, ejecuta comandos y se integra con herramientas de desarrollo. Los documentos de LangChain Deep Agents describen los backends sandbox como el lugar donde los agentes ejecutan comandos shell, manipulan sistemas de archivos y delegan el trabajo a subagentes. Docker ahora distribuye Sandboxes específicamente para agentes de codificación de IA, y Freestyle pone la frase "Sandboxes for Coding Agents" directamente en su página de inicio. (Claude API Docs)

Ese cambio es importante porque una vez que el modelo puede actuar, la principal pregunta de seguridad deja de ser "¿Cómo de preciso es el modelo?" y se convierte en "¿Qué puede tocar esta cosa cuando está equivocada, manipulada o demasiado confiada?" La guía de seguridad de agentes de OpenAI califica la inyección de instrucciones como un riesgo común y peligroso y advierte explícitamente que el texto malicioso puede empujar a los agentes hacia acciones no deseadas, incluida la exfiltración de datos a través de llamadas a herramientas posteriores. El NIST enmarca el mismo tipo de problema en el secuestro de agentes, una forma de inyección indirecta de avisos en la que las instrucciones maliciosas se ocultan en el contenido que consume un agente. (Desarrolladores de OpenAI)

Por eso importan los cajones de arena. No porque hagan que los modelos sean fiables, ni porque solucionen la inyección puntual, sino porque definen el radio de explosión cuando un agente codificador inevitablemente hace algo que usted no quería autorizar.

Por qué los agentes de codificación necesitan sandboxes

El primer error que cometen los equipos es tratar a los agentes de codificación como si fueran simples chatbots con un mayor acceso a los archivos. Las principales plataformas de agentes de codificación no se comportan así. Claude Code está documentada como una herramienta que puede inspeccionar una base de código, editar archivos, ejecutar comandos y trabajar en tareas de desarrollo. Los agentes profundos de LangChain pueden ejecutar comandos shell a través de backends de sandbox, persistir en memoria, intercambiar backends de sistemas de archivos y delegar subtareas a subagentes especializados para el aislamiento de contextos. Docker Sandboxes admite plantillas de agente listas para usar para Claude Code, Codex, Copilot, Gemini, Kiro, OpenCode y Docker Agent. (Claude API Docs)

Ese conjunto de capacidades es exactamente lo que hace que estos sistemas sean útiles. También es lo que los hace operativamente peligrosos. Una vez que un agente puede ejecutar pytestInstalar npm paquetes, abrir una rama o inspeccionar un fallo de compilación, está a sólo unas pocas llamadas a herramientas de hacer algo con consecuencias mucho mayores: editar un script de despliegue, filtrar un token a un servicio remoto, modificar un hook Git o levantar un contenedor que ejecuta código que no has auditado.

La respuesta intuitiva suele ser "basta con exigir aprobaciones". Eso ayuda, pero no se sostiene bien como único control. El inicio rápido de Anthropic dice que Claude Code pide permiso antes de modificar archivos, y el escrito de Anthropic de marzo de 2026 sobre el modo automático dice que los usuarios aprobaron el 93 por ciento de las solicitudes de permiso. Esta cifra es reveladora. Si casi todas las solicitudes son aprobadas, los diálogos de permiso están sirviendo en parte como una ceremonia, no como un límite fiable. La plantilla sandbox de Docker para Claude Code va incluso más allá y documenta que su imagen base lanza Claude Code con --skip-permissions por defecto, sustituyendo de forma efectiva los avisos interactivos detallados por el aislamiento en tiempo de ejecución y los controles circundantes. (Claude API Docs)

La guía de OpenAI llega a la misma conclusión práctica desde una dirección diferente. Su documentación sobre la seguridad de los agentes sostiene que el objetivo no puede ser la detección perfecta de entradas maliciosas. La estrategia más fiable es diseñar sistemas que limiten el impacto de la manipulación incluso cuando ésta tiene éxito. En otras palabras, el modelo puede seguir siendo falible si el entorno está suficientemente delimitado. (OpenAI)

Un arenero es la expresión ingenieril de esa idea.

Qué aísla realmente un sandbox de agente de codificación

Un verdadero sandbox no es sólo "otro lugar donde ejecutar código". Es un conjunto de límites.

El primer límite es el límite del sistema de archivos. El agente debe ser capaz de leer y escribir sólo en el árbol de trabajo o volúmenes montados explícitamente para él. Cualquier cosa fuera de ese ámbito no debería ser accesible. LangChain describe las cajas de arena como el límite que impide que el agente alcance los archivos del host. El modelo de seguridad de Docker es aún más concreto: el principal límite de confianza es la microVM, y sólo el espacio de trabajo explícitamente compartido cruza dentro de ella. (Documentos LangChain)

El segundo límite es el límite del proceso y del núcleo. Si el agente instala paquetes, lanza servicios, inicia contenedores o genera subprocesos, esas acciones deben permanecer dentro de un entorno de ejecución que no comparta procesos de host o un kernel de host desprotegido. Los documentos de aislamiento de Docker enfatizan que cada sandbox tiene su propia microVM y kernel Linux. Los documentos de diseño de Firecracker describen el límite de virtualización como la primera capa de aislamiento, y luego añaden seccomp, cgroups, namespaces y jailing para la defensa en profundidad. (Documentación de Docker)

El tercer límite es el límite de la red. Los agentes de codificación son inusualmente ávidos de red. Quieren instalar dependencias, buscar documentación, llamar a las API de LLM, consultar GitHub y, a veces, rastrear la web o hablar con los puntos finales de MCP. Sin una política de red, "aislado" puede significar "libre para filtrar". La postura predeterminada de Docker bloquea HTTP y HTTPS salientes a menos que las reglas lo permitan, bloquea todos los TCP, UDP e ICMP sin procesar y también bloquea el tráfico a rangos de IP privados y direcciones locales de host. GKE Agent Sandbox enmarca la misma cuestión como un fuerte aislamiento de procesos, almacenamiento y red para el código no fiable. (Documentación de Docker)

El cuarto límite es el límite de credenciales. Una caja de arena no sirve de mucho si el agente puede leer las claves de la API que quieres proteger. El diseño de Docker evita pasar secretos de proveedor sin procesar a la máquina virtual utilizando un proxy del lado del host que inyecta credenciales en las cabeceras HTTP salientes. Sus documentos son explícitos en que los valores de las credenciales en bruto nunca entran en la máquina virtual. (Documentación de Docker)

El quinto límite es el límite del ciclo de vida. El trabajo de los agentes rara vez es de una sola vez. Un sandbox útil tiene que soportar un estado de inicio, un estado de trabajo, un estado de pausa y un estado de borrado. Tiene que preservar las cosas correctas y destruir las cosas correctas. E2B documenta sistemas de archivos aislados, comandos en segundo plano, volúmenes montados y la capacidad de conectarse a sandboxes en ejecución. Freestyle documenta la suspensión, parada, instantánea, bifurcación, tiempo de espera y eliminación. Daytona documenta la creación de sandboxes a partir de instantáneas y el control de los intervalos de auto-parada, auto-archivado y auto-borrado. (E2B)

Esa distinción es importante porque un tiempo de ejecución de agente que no puede preservar el estado es lento y torpe, mientras que un tiempo de ejecución de agente que preserva todo para siempre se convierte en un objetivo longevo.

Modelos de aislamiento para agentes codificadores

Los equipos a menudo discuten el "sandboxing" como si hubiera una única implementación. No es así. Las propiedades de seguridad de un contenedor de núcleo compartido, un sandbox de gVisor, una microVM y una VM Linux completa son materialmente diferentes.

Esta es la forma práctica de pensar en el espacio de diseño.

Modelo de aislamiento	Límite del núcleo	Resistencia típica	Principal contrapartida	Mejor ajuste
Contenedor de núcleo compartido	No hay núcleo invitado separado	Puesta en marcha rápida, utillaje maduro, densidad barata	El riesgo de fuga está directamente relacionado con el endurecimiento del núcleo anfitrión y del tiempo de ejecución.	Automatización interna de confianza con acciones de bajo riesgo
Sandbox aplicación-núcleo como gVisor	Límite de software adicional por encima del núcleo anfitrión	Mayor mediación de llamadas al sistema, ideal para plataformas nativas de clústeres	No es idéntica a la semántica completa de Linux, puede necesitar ajustes.	Ejecución de código multiusuario en Kubernetes
MicroVM	Núcleo invitado ligero y separado	Mayor aislamiento del host con un arranque relativamente rápido	Más sobrecarga que los contenedores, más complejidad del ciclo de vida	Agentes autónomos que necesitan shell, paquetes y flujos de trabajo tipo Docker
VM Linux completa	Sistema completo separado para invitados	Semántica Linux completa, fuerte aislamiento de la carga de trabajo, amplia compatibilidad	Mayor coste de recursos, más Estado que gestionar	Bancos de trabajo de agentes de larga duración, flujos con mucho navegador, virtualización anidada

Ese cuadro es una síntesis, pero las piezas que hay detrás no son hipotéticas. gVisor se describe a sí mismo como un sandbox formado por múltiples procesos, con un Sentry que intercepta y responde a las llamadas del sistema. GKE Agent Sandbox de Google utiliza gVisor para crear una barrera entre la aplicación y el nodo del clúster. Firecracker considera que las microVM combinan el aislamiento de la virtualización de hardware con la velocidad y flexibilidad de los contenedores. Kata Containers describe su objetivo como máquinas virtuales ligeras que se asemejan a los contenedores pero mantienen las ventajas de aislamiento de las máquinas virtuales. Freestyle va un paso más allá en el lenguaje de su propio producto y dice claramente: no contenedores, máquinas virtuales Linux completas con acceso root real. (gVisor)

Aquí es donde muchas discusiones sobre "agentes sandbox" se vuelven descuidadas. Un contenedor de núcleo compartido no es automáticamente malo. Puede ser completamente apropiado para herramientas internas en las que ya confías. Pero cuando la gente dice que quiere dejar que un agente de codificación instale paquetes arbitrarios, construya imágenes, ejecute navegadores o ejecute comandos shell no revisados, la conversación sobre el aislamiento cambia. La cuestión ya no es si el tiempo de ejecución es conveniente. La cuestión es qué límite falla primero cuando se manipula el agente.

La comparación de la arquitectura de Docker con otras alternativas deja claro este punto. Contrasta las cajas de arena de microVM con un contenedor que monta el socket del host, con Docker-in-Docker y con la ejecución directa en el host. Su conclusión no es ideológica. Los entornos aislados cuestan más porque incluyen una máquina virtual y un demonio aislado. Pero ese trueque compra un límite significativo cuando se quiere dar a algo autónomo todas las capacidades de Docker sin confiarle el entorno del host. (Documentación de Docker)

Freestyle destaca un lado diferente del comercio. Su modelo de producto se basa en máquinas virtuales Linux completas, redes completas, acceso root real, servicios systemd y virtualización anidada. Esto tiene sentido si su agente necesita una semántica que es difícil de fingir dentro de un entorno más restringido, especialmente cuando el estado del navegador, la bifurcación paralela o los flujos de trabajo VM-in-VM son importantes. (Estilo libre)

La elección correcta no tiene que ver con la fidelidad a una marca. Se trata de la forma del trabajo. Si su problema principal es la ejecución de código multi-tenant nativo de clúster, gVisor o los enfoques respaldados por Kata pueden ser suficientes. Si su problema principal es un agente de codificación autónomo con shells, Docker, gestores de paquetes, ramificación y estado activo, las microVM o las VM completas suelen ser más naturales.

La velocidad, el estado y la ramificación importan más de lo que la mayoría de los equipos esperan

Un sandbox que es seguro pero demasiado lento será eludido. Este es uno de los resultados más predecibles de las herramientas para desarrolladores.

Los agentes de codificación no se comportan como trabajos nocturnos por lotes. Van de un lado a otro leyendo, editando, compilando, probando, llamando a herramientas y esperando a los humanos. Abren varias hipótesis, abandonan algunas y retoman otras. Eso significa que el tiempo de ejecución tiene que estar optimizado para iteración interactivano sólo para una ejecución puntual.

Los documentos de Freestyle VM son inusualmente explícitos al respecto. Dicen que las máquinas virtuales se aprovisionan en menos de 800 milisegundos desde la solicitud de la API hasta la máquina en ejecución, se suspenden y se reanudan en menos de 100 milisegundos, y se pueden bifurcar a mitad de la ejecución con un impacto mínimo en el rendimiento. Su documentación también explica por qué: las instantáneas de memoria y las capas almacenadas en caché agilizan el arranque, mientras que la suspensión conserva el estado exacto de la memoria en lugar de forzar un reinicio completo. Los ejemplos están escritos para creadores de aplicaciones y agentes basados en navegador, pero el patrón es más amplio. Si un agente alcanza un estado de navegador interesante o un grafo de dependencias parcialmente construido, ser capaz de bifurcar ese estado es dramáticamente mejor que recrearlo desde cero veinte veces. (Documentación sobre Freestyle)

GKE Agent Sandbox de Google revela una versión nativa de clúster de la misma idea. Su documentación define tanto un SandboxTemplateque sirve de modelo reutilizable, y un archivo SandboxWarmPoolque mantiene los pods precalentados listos para ser reclamados. No se trata sólo de un detalle de Kubernetes. Es una concesión a la realidad de que los sistemas autónomos necesitan capacidad de calentamiento si se quiere una capacidad de respuesta percibida por el ser humano. (Documentación sobre Google Cloud)

Los documentos de Daytona describen otro patrón útil: la creación de sandboxes a partir de instantáneas y el control del ciclo de vida posterior a la ejecución con intervalos de auto-parada, auto-archivado y auto-borrado. Este conjunto de características se refiere a un problema familiar de los agentes. Algunas sesiones son entornos de desarrollo activos. Otras son experimentos efímeros. Otras están inactivas, pero merece la pena mantenerlas como líneas de base exactas. Una política de ciclo de vida no es suficiente. (Daytona)

La documentación de E2B cubre la parte operativa que a menudo se ignora en los diagramas de arquitectura. Admite comandos en segundo plano, vigilancia de directorios, sistemas de archivos aislados, volúmenes persistentes que sobreviven a los ciclos de vida de los entornos aislados y montajes que permiten reutilizar un volumen en varios entornos aislados a lo largo del tiempo. No son campanas y silbatos. Son la diferencia entre un agente que puede ejecutar un servidor de desarrollo y esperar a los registros, frente a un agente que sólo puede disparar comandos puntuales y perder el contexto. (E2B)

Una forma útil de evaluar una plataforma es plantearse cuatro preguntas operativas:

Capacidad	Por qué es importante para los agentes de codificación	Lo que se rompe cuando falta
Puesta en marcha rápida o piscina caliente	Mantiene los bucles de iteración utilizables	La gente deja de esperar y recurre a la ejecución local
Pausa, reanudación y parada automática	Conserva el estado sin quemar computación ociosa	Las sesiones largas se encarecen o se matan con demasiada agresividad
Instantáneas y bifurcaciones	Permite a los agentes partir de un estado conocido como bueno	La exploración compleja se vuelve lenta e irreproducible
Trabajos en segundo plano y almacenamiento persistente	Compatible con servidores de compilación, ejecutores de pruebas, navegadores y registros.	El sandbox se siente apátrida incluso cuando el trabajo no es

Las plataformas anteriores implementan estas ideas de forma diferente, pero la lección es consistente: para codificar agentes, el aislamiento es sólo la mitad del diseño. La otra mitad es la gestión del estado.

Los secretos, la política de red y la confianza en el espacio de trabajo son el verdadero plano de control

Un equipo puede conseguir el aislamiento primitivo correcto y aún así construir un sistema inseguro.

La documentación actual del sandbox de Docker es útil porque es inusualmente sincera sobre lo que el agente puede hacer. El límite de confianza primario es la microVM, pero dentro de la VM el agente tiene control total, incluyendo privilegios sudo. El espacio de trabajo está montado en lectura-escritura. Con el montaje directo por defecto, los cambios en los archivos aparecen en el host inmediatamente. El tráfico de red es denegado por defecto, pero las peticiones HTTP y HTTPS permitidas son proxyadas a través del host. Las credenciales pueden ser inyectadas por el proxy del lado del host sin exponer valores sin procesar dentro de la máquina virtual. (Documentación de Docker)

Es un modelo sólido, pero no es lo mismo que "el agente no puede hacerme daño". Los documentos de Docker advierten explícitamente de que, aunque el host está aislado, el espacio de trabajo compartido no es inofensivo. Si el agente edita archivos que los humanos ejecutan más tarde - Git hooks, CI configs, IDE task configs, Makefile, paquete.json scripts, archivos de construcción - el daño puede cruzar la frontera cuando un humano o pipeline ejecuta esos archivos más tarde. Incluso señalan el hecho de que los ganchos de Git en .git/ no aparecen en git diff. Ese es el tipo de detalles que los equipos olvidan hasta que les muerden. (Documentación de Docker)

Este es el modelo mental correcto:

• Aislamiento del huésped protege tu máquina.
• Confianza en el espacio de trabajo protege a tu yo futuro.
• Política de redes protege el mundo exterior y tus datos.
• Gestión de credenciales protege las identidades a través de las que puede actuar su agente.

Esos aviones deben diseñarse juntos.

El plano de credenciales es especialmente sutil. La postura predeterminada de Docker dice que no hay credenciales disponibles a menos que las proporciones, y cuando se proporcionan, el proxy del lado del host las inyecta en las cabeceras HTTP salientes para que los valores sin procesar no entren en la máquina virtual. Los documentos de la caja de arena de shell repiten la misma idea para los proveedores compatibles y afirman que las credenciales nunca se almacenan dentro de la caja de arena en ese flujo. Esto es mucho mejor que colocar claves API en variables de entorno dentro del tiempo de ejecución del agente. (Documentación de Docker)

Pero el modelo tiene un caso límite que importa en la práctica. El FAQ de Docker explica que si necesitas una variable personalizada que no está soportada por el flujo proxy, puedes escribirla en /etc/sandbox-persistent.sh. La documentación también advierte que esto almacena el valor dentro del sandbox, donde el proceso agente puede leerlo directamente. La diferencia entre "inyección de credenciales" y "presencia de credenciales" es enorme. La primera limita la divulgación. La segunda asume que el propio agente es de confianza. (Documentación de Docker)

El plano de configuración es igual de importante. Docker's sandbox FAQ dice que la configuración del agente a nivel de usuario desde el host, tales como ~/.claude o ~/.codexno se copia en el sandbox; sólo está disponible la configuración a nivel de proyecto en el directorio de trabajo. Esto es bueno desde una perspectiva de contención del host, pero también significa que las habilidades a nivel de proyecto, los hooks, las instrucciones locales y la configuración repo-scoped se convierten en la principal superficie de control que ve el agente. Los documentos de configuración de Anthropic refuerzan el modelo operativo: la configuración del proyecto es el ámbito compartido por el equipo para permisos, ganchos y servidores MCP, y el ámbito del proyecto prevalece sobre el ámbito del usuario. (Documentación de Docker)

Por eso son tan valiosas las directrices de OpenAI sobre Skills. Los documentos advierten de que las Skills introducen riesgos de seguridad como la exfiltración de datos impulsada por la inyección de comandos, y dicen explícitamente que los desarrolladores no deben exponer un repositorio abierto de Skills a los usuarios finales, ya que las aplicaciones maliciosas pueden provocar la filtración de datos. SKILL.md pueden provocar la elusión de políticas, acciones destructivas o filtraciones. Recomiendan integrar las competencias de los desarrolladores, asignarlas a flujos de trabajo delimitados y ocultar las acciones de alto impacto tras aprobaciones y comprobaciones de políticas. (Desarrolladores de OpenAI)

En pocas palabras, una caja de arena no es sólo un problema de tiempo de ejecución. Es un problema de empaquetado. Cualesquiera que sean las instrucciones, herramientas, configuraciones, plugins o habilidades que montes en el tiempo de ejecución se convierten en parte de la superficie de ataque.

La inyección puntual se vuelve más peligrosa cuando el agente puede ejecutar

Los equipos de seguridad a veces hablan de la inyección puntual como si se tratara de un extraño fallo de calidad del modelo. Ese encuadre es demasiado pequeño para los agentes de codificación.

El trabajo del NIST sobre el secuestro de agentes describe claramente el patrón subyacente: se incrustan instrucciones maliciosas en datos que un agente probablemente leerá, como un sitio web, un archivo o un correo electrónico, y se engaña al agente para que realice una tarea diferente y potencialmente dañina. La propia guía de OpenAI dice que las inyecciones de instrucciones se producen cuando texto o datos no fiables entran en el sistema e intentan anular las instrucciones, con resultados que pueden incluir la fuga de datos privados y el uso de herramientas desalineadas. El último artículo de OWASP sobre la inyección de prompt añade un matiz importante que muchos blogs de ingeniería siguen desdibujando: la inyección de prompt y el jailbreaking están relacionados, pero el problema más profundo es que la entrada puede hacer que el modelo pase directivas maliciosas o inseguras a etapas posteriores del sistema. OWASP también señala que RAG y el ajuste fino no resuelven completamente el problema. (NIST)

En los flujos de trabajo de codificación, esto aparece en lugares familiares:

Un archivo README indica al agente que "arregle la compilación" e incluye instrucciones que redirigen silenciosamente la instalación del paquete o sugieren la descarga de un script de ayuda desde un dominio controlado por el atacante.

Un comentario sobre un problema afirma que un arnés de pruebas sólo funciona si el agente imprime el entorno completo, revelando tokens o URLs internas.

Un archivo de resultados de referencia indica al agente que "verifique la conectividad de la red" rizando un servicio privado o un dominio público ingeniosamente nombrado.

Un agente con capacidad de navegador lee una página que parece documentación pero que contiene instrucciones ocultas para persistir un cambio de configuración malicioso en el repositorio.

La cuestión no es que el modelo sea crédulo. La cuestión es que el el agente tiene demasiados privilegios en relación con la fiabilidad del contenido que lee.

El artículo de OpenAI de marzo de 2026 sobre la resistencia a la inyección de comandos ofrece un argumento útil en este sentido: intentar clasificar a la perfección cada entrada maliciosa suele ser un objetivo de optimización erróneo. Lo mejor es limitar las consecuencias del éxito. Esta filosofía de diseño se traslada de forma natural a los entornos aislados de agentes de codificación. El tiempo de ejecución debería asumir que alguna instrucción maliciosa acabará aterrizando en el contexto del modelo. La cuestión es si el resultado es "una mala respuesta en una transcripción" o "un script de construcción editado, datos filtrados y una nueva rama empujada aguas arriba". (OpenAI)

Un sandbox no elimina el secuestro, pero puede reducir el resultado.

Una política de red de denegación por defecto puede detener la ruta de exfiltración.

Un proxy de credenciales puede impedir que el modelo lea la clave sin procesar que está utilizando.

Un subagente de sólo lectura con ámbito de proyecto puede inspeccionar material sospechoso sin obtener permisos de edición.

Un gancho puede requerir una revisión manual antes de permitir cualquier llamada a una herramienta con capacidad de red o que cambie de estado.

Un verificador independiente puede volver a ejecutar el paso final de forma independiente en lugar de confiar en la narración del agente generador.

El modelo de subagente de Anthropic es útil en este caso. Sus documentos describen agentes de exploración y planificación incorporados de sólo lectura, junto con subagentes personalizados que pueden tener sus propias restricciones de herramientas, modos de permiso, ganchos y habilidades. Se trata de un modelo mejor que el de un agente monolítico para todas las herramientas. Recon, la búsqueda de código, los parches, las acciones de liberación y la publicación de paquetes no son la misma tarea y no deberían compartir la misma autoridad. (Claude API Docs)

Las CVE en tiempo de ejecución que deben recordar los creadores de sandboxes

Los debates sobre los entornos aislados pueden derivar hacia la teoría. Los CVE en tiempo de ejecución los devuelven a la realidad.

El primer CVE que todo arquitecto de sandbox debe recordar es CVE-2019-5736. NVD lo describe como runc que permitía a los atacantes sobrescribir el host runc binario y así obtener acceso root al host, dada la capacidad de ejecutar un comando como root dentro de ciertos contenedores. La razón por la que todavía importa no es nostalgia. Es un recordatorio claro de que cuando tu límite de confianza depende de un contenedor en tiempo de ejecución que comparte un kernel anfitrión y un binario en tiempo de ejecución anfitrión, los errores en esa pila pueden colapsar el límite por completo. (nvd.nist.gov)

El segundo es CVE-2024-21626. Los anuncios de seguridad de NVD y Docker describen una fuga de descriptor de archivo en runc 1.1.11 y anteriores que podrían permitir a un proceso contenedor recién generado aterrizar con un directorio de trabajo en el espacio de nombres del sistema de archivos del host, dando acceso al sistema de archivos del host. El propio aviso de Docker dice que los ataques también podrían adaptarse para sobrescribir binarios de host semi-arbitrarios, permitiendo escapes completos de contenedores. Docker Engine 24.0 señala la corrección en runc 1.1.12. (nvd.nist.gov)

Estos fallos son importantes para los agentes de codificación por tres razones.

En primer lugar, los agentes de codificación son mucho más propensos que las cargas de trabajo de las aplicaciones tradicionales a manejar entradas de compilación no fiables. Construyen contenedores, ejecutan pruebas, instalan paquetes y, a veces, ejecutan comandos en repositorios que nunca antes habían visto.

En segundo lugar, los agentes de codificación tientan a los equipos a conceder privilegios de herramienta superiores a los normales. Si el agente no puede ejecutar Docker, construir dependencias o generar contenedores de ayuda, a menudo no puede terminar la tarea. Eso crea presión para difuminar la línea entre "tiempo de ejecución útil" y "tiempo de ejecución de confianza".

En tercer lugar, los agentes autónomos cambian la economía de la explotación. Un atacante humano todavía tiene que crear una ruta manualmente. A un agente de codificación se le puede engañar para que explore repetidamente ramas, pruebe soluciones y ponga en funcionamiento cualquier entorno que se le proponga.

Una arquitectura aislada no hace que estos CVE sean irrelevantes. Lo que cambia es el daño que pueden causar. Un enfoque basado en microVM reduce la dependencia de los límites del kernel del host de una forma que no lo hace un contenedor de kernel compartido. Una VM completa va más allá. gVisor y Kata apuntan a diferentes puntos de la misma curva, intercambiando características de compatibilidad y rendimiento por aislamiento adicional. (gVisor)

La lección práctica es sencilla:

Lección CVE	Por qué es importante para los agentes de codificación
Los escapes en tiempo de ejecución de los contenedores no son casos excepcionales	Es más probable que los agentes ejecuten rutas de código controladas por atacantes o semiconfiables
Los servicios de acogida compartidos multiplican el impacto	Los dæmons Docker, los sockets y los montajes directos amplían el radio de explosión.
El nivel de parche no basta por sí solo	Sigues necesitando límites que supongan que aún no se ha encontrado el siguiente error de ejecución

Si debe utilizar contenedores de núcleo compartido, manténgalos parcheados de forma agresiva y reduzca la superficie expuesta. No montes el socket Docker del host en nada autónomo. Si el trabajo requiere "ejecutar código arbitrario y construir contenedores arbitrarios", prefiera un tiempo de ejecución en el que el límite del host sea más fuerte que el aislamiento del espacio de nombres por sí solo. (Documentación de Docker)

Las solicitudes de permisos no son un modelo de seguridad duradero

La aprobación interactiva es útil. La aprobación interactiva como límite principal es frágil.

El inicio rápido de Anthropic presenta el camino feliz: Claude Code propone un cambio, lo muestra, pide aprobación y luego realiza la edición. Ese flujo es excelente para el desarrollo individual. Se vuelve menos fiable cuando el agente es de larga duración, de varios pasos, o funciona dentro de un entorno de mayor volumen. El post sobre el modo automático de Anthropic es sincero sobre la razón por la que construyeron la automatización en el manejo de la aprobación: los usuarios aprobaban el 93 por ciento de las solicitudes de permiso, por lo que el sistema necesitaba una manera de reducir la fatiga de aprobación sin dejar de capturar el riesgo. (Claude API Docs)

El ejemplo más revelador es la plantilla sandbox de Docker para Claude Code. Su documentación afirma que el sandbox utiliza una imagen de Claude Code que se lanza con --skip-permissions por defecto. Esto no es una acusación contra Docker. Es una señal sobre la ergonomía del mundo real. Una vez que los equipos pasan a flujos autónomos o semiautónomos, el modelo de solicitud por acción es demasiado lento. La respuesta no es desear que el problema desaparezca. La respuesta es mover los controles hacia abajo y hacia fuera: hacia los límites del tiempo de ejecución, las políticas de salida, la gestión de secretos y la separación de flujos de trabajo. (Documentación de Docker)

El propio modelo de herramientas de Anthropic soporta este tipo de estratificación. Sus documentos de configuración definen los ámbitos gestionado, de usuario, de proyecto y local, con la configuración gestionada en la parte superior y la configuración del proyecto por encima de la configuración del usuario. Sus documentos de subagentes describen las restricciones de las herramientas por agente y los componentes de sólo lectura. Su SDK de agente expone Solicitud de permiso eventos de gancho que se pueden gestionar mediante programación, y el tipo de salida de gancho admite el bloqueo de la ejecución y la devolución de un motivo. (Claude API Docs)

Eso conduce a un patrón mucho más saludable para la seguridad de los agentes de codificación:

• Utiliza el sandbox para eliminar la confianza a nivel de host.
• Utilice la política de red para eliminar las salidas no aprobadas.
• Utilice proxies secretos para que el agente pueda utilizar las credenciales sin leerlas.
• Utiliza ajustes a nivel de proyecto para que los equipos puedan versionar permisos y ganchos con el repositorio.
• Utilice subagentes de sólo lectura para la exploración y la planificación.
• Reserve la aprobación humana para las acciones con consecuencias para la empresa, como la publicación de paquetes, la ampliación de ramas, los cambios de infraestructura o la rotación de secretos.

Una política de gancho ilustrativa podría ser la siguiente:

# Lógica de política ilustrativa para el tiempo de ejecución de un agente de codificación.
# No se trata de la forma exacta de la API, sino del patrón de control.

APPROVAL_REQUIRED_TOOLS = {"Bash", "Edit", "Write", "McpTool"}
ALLOWED_HOSTS = {"api.github.com", "registry.npmjs.org", "pypi.org"}
HIGH_IMPACT_COMMANDS = {"git push", "npm publish", "pip upload", "scp", "ssh"}

def on_permission_request(nombre_herramienta: str, entrada_herramienta: dict) -> dict:
    cmd = (tool_input.get("command") or "").strip()

    si tool_name no está en APPROVAL_REQUIRED_TOOLS:
        return {"continuar_": True}

    if any(cmd.startswith(prefix) for prefix in HIGH_IMPACT_COMMANDS):
        return {
            "continue_": False
            "decisión": "bloquear",
            "razón": "Comando de alto impacto requiere aprobación humana explícita fuera de la sesión del agente",
            "systemMessage": "Comando de alto impacto bloqueado. Utilizar flujo de trabajo de liberación".
        }

    si "curl " en cmd o "wget " en cmd:
        host = extract_host(cmd) # tu analizador sintáctico
        si host no está en ALLOWED_HOSTS:
            return {
                "continuar_": False
                "decisión": "block",
                "reason": f "El host de salida {host} no está en la lista de permitidos",
                "systemMessage": "Salida bloqueada a host no aprobado".
            }

    return {"continue_": True}

Esto no sustituye al aislamiento en tiempo de ejecución. Es lo que parece un modelo de aprobación maduro una vez que dejas de pedir a los humanos que hagan clic en cada evento menor.

Diseño de una arquitectura sandbox de producción para agentes de codificación

Un diseño de producción tiene que separar al menos seis preocupaciones.

El primero es el plano de control. Aquí es donde se decide quién puede iniciar un sandbox, bajo qué identidad se ejecuta la sesión, qué plantilla base utiliza, cuánto tiempo puede vivir y si se le permite llamar a herramientas en red.

El segundo es el plano de ejecución. Esta es la zona de pruebas real: microVMs, pods respaldados por gVisor, VMs completas, o algún otro tiempo de ejecución limitado. La propiedad crítica es que se comporta como una máquina de trabajo para el agente pero no como su host.

El tercero es el plano político. Los documentos de la caja de arena de Docker son un buen ejemplo de la aplicación de políticas fuera del agente: proxy de red del lado del host, denegación de salida por defecto, controles de ruta del host e inyección de credenciales. Los ámbitos de configuración y ganchos de Anthropic muestran cómo la política también puede vivir a nivel de repositorio y agente. (Documentación de Docker)

El cuarto es el plano artefacto. Una sesión de un agente de codificación no debe ser una caja negra. Necesita diffs, trazas de herramientas, transcripciones, salidas de comandos, identificadores de entorno y suficiente estado para volver a ejecutar la demanda final de forma independiente. El énfasis de LangChain en el humano-en-el-bucle y la separación de backend es útil aquí, al igual que el modelo de gancho y subagente de Anthropic. (Documentos LangChain)

El quinto es el plano de verificación. Aquí es donde muchas herramientas internas siguen siendo débiles. El mismo agente que plantea la hipótesis de un problema no debería ser el único sistema autorizado para afirmar que el problema es real. Se necesita una comprobación independiente, ya sea una repetición limpia en otro sandbox, un validador de sólo lectura o un trabajo independiente que confirme el cambio de estado o la afirmación de explotabilidad.

El sexto es el plano del ciclo de vida. No es lo mismo una tarea scratch de corta duración, un entorno de referencia reproducible y una sesión de navegador que un agente quiere bifurcar veinte veces. El modelo de suspensión, snapshot y fork de Freestyle, los warm pools de GKE, la creación basada en snapshot de Daytona con políticas de ciclo de vida post-stop y los volúmenes de E2B son ejemplos de plataformas que exponen el ciclo de vida como una decisión de primera clase en lugar de tratarlo como una trivialidad de limpieza. (Documentación sobre Freestyle)

Una arquitectura de referencia útil tiene este aspecto:

Usuario u Orquestador
        |
        v
Plano de control
identidad, selección de plantillas, presupuesto, selección de políticas
        |
        v
Motor de políticas
reglas de salida, montajes de espacios de trabajo, controles de herramientas, reglas de aprobación
        |
        v
Sandbox Runtime Pool
microVMs, sandboxes respaldados por gVisor, o VMs completas
        |
   +----+----+-----------------------------+
   | | |
   v v v
Secretos Proxy Repo y Artifact Layer Tool Gateway
inyección de encabezado, sin claves en bruto en VM MCP o sólo APIs aprobadas
   |
   v
Verificador y almacén de pruebas
repetición independiente, rastros, registros, resultados
   |
   v
Revisión humana y exportación

La cuestión más profunda es que "cajón de arena" no debería ser un sustantivo. Debería ser un límite del sistema con una política y pruebas adjuntas.

Patrones prácticos de las actuales plataformas sandbox

El mercado está convergiendo por fin en la idea de que los agentes de codificación necesitan tiempos de ejecución dedicados, pero las implementaciones siguen reflejando diferentes supuestos.

Sandboxes Docker está orientado a flujos de trabajo locales y adyacentes al desarrollador. Las opciones clave son el aislamiento de microVM, un motor Docker privado dentro de cada sandbox, montaje directo del espacio de trabajo, inyección de credenciales en el host y reglas de red de denegación por defecto. Los ejemplos de CLI son intencionadamente simples:

sbx run claude ~/mi-proyecto

Para los equipos que ya viven cerca de Docker, esto es atractivo porque mantiene el flujo de trabajo legible. El agente ve un directorio de proyecto y una máquina utilizable, pero el límite del host sigue siendo más fuerte que un simple contenedor con un socket mount. El coste es que el montaje directo por defecto significa que la confianza en el espacio de trabajo se convierte en una tarea de revisión de primera clase, no una ocurrencia tardía. (Documentación de Docker)

Sandbox de Docker revela un patrón igualmente importante: la plataforma sabe que no todos los agentes tienen plantillas oficiales. La plantilla shell existe como un entorno mínimo para la instalación manual y la depuración. Eso es práctico, pero también es donde más importa la disciplina, porque "basta con instalar la herramienta de forma interactiva" puede derivar en "hemos perdido la pista de lo que hay exactamente en este tiempo de ejecución". Las plantillas personalizadas son la respuesta más limpia cuando un flujo de trabajo se estabiliza. (Documentación de Docker)

Sandbox de agentes de GKE está determinado por la ingeniería de la plataforma más que por la ergonomía del desarrollador local. La documentación muestra cómo crear un clúster de GKE con gVisor, desplegar el controlador del Agente Sandbox, definir un SandboxTemplatey mantener la capacidad precalentada con SandboxWarmPool. El ejemplo es explícito sobre el uso de grupos de nodos habilitados para gVisor y un runtimeClassName: gvisor en la plantilla del pod. Eso hace que esta ruta sea atractiva para los equipos que quieren sandboxing como una plataforma interna primitiva en lugar de una herramienta del lado del desarrollador. (Documentación sobre Google Cloud)

Un fragmento de clúster representativo tiene este aspecto:

apiVersion: extensions.agents.x-k8s.io/v1alpha1
tipo: SandboxTemplate
metadatos:
  name: python-runtime-template
spec:
  podTemplate:
    spec:
      runtimeClassName: gvisor
      contenedores:
        - name: python-runtime
          imagen: registry.k8s.io/agent-sandbox/python-runtime-sandbox:v0.1.0
---
apiVersion: extensions.agents.x-k8s.io/v1alpha1
tipo: SandboxWarmPool
metadatos:
  name: python-sandbox-warmpool
spec:
  replicas: 2
  sandboxTemplateRef:
    nombre: python-runtime-template

Ese patrón dice algo importante: algunas organizaciones no necesitan "un producto sandbox". Necesitan un sustrato arenero dentro de Kubernetes.

Estilo libre está optimizado para una clase diferente de problemas. Su documentación y páginas de producto enfatizan las máquinas virtuales Linux completas, el arranque rápido desde instantáneas de memoria, la semántica de suspender frente a parar, las instantáneas, la bifurcación, los flujos de trabajo Git y las primitivas Linux reales como servicios, usuarios, grupos y virtualización anidada. Es un buen ajuste para los agentes que necesitan comportarse más como usuarios del sistema operativo que como tareas sin estado. El detalle más llamativo de la documentación es el ejemplo del estado del navegador: si un agente está navegando por una página web y quiere explorar veinte rutas, Freestyle dice que puede bifurcar la máquina virtual veinte veces desde el mismo estado. Esto no es palabrería de marketing. Es una articulación fuerte de una necesidad real del agente. (Estilo libre)

E2B está más centrado en el SDK. Su documentación hace hincapié en los entornos aislados para la ejecución de código, las API de comandos, los trabajos en segundo plano, los sistemas de archivos, los volúmenes, la carga y descarga de datos y el control opcional del acceso a Internet. Esto lo hace atractivo cuando el producto que estás construyendo es en sí mismo una aplicación que necesita primitivas sandbox como objetos API más que como infraestructura de usuario final. El modelo de volumen es especialmente útil cuando quieres que el estado sobreviva a un sandbox individual. (E2B)

Daytona se sitúa cerca del extremo "entorno de desarrollo como agente en tiempo de ejecución" del espectro. Sus documentos exponen los tiempos de ejecución del lenguaje, la creación basada en instantáneas y los controles del ciclo de vida posteriores a la parada, como la parada automática, el archivado automático y la eliminación automática. Para los equipos que quieren espacios de trabajo reproducibles con gestión explícita de instantáneas, es un modelo limpio. (Daytona)

Aquí no hay un ganador universal. La elección correcta depende de si su problema más difícil es el aislamiento del host local, la tenencia del clúster, la ramificación con estado, el acceso programable al SDK o la semántica del banco de trabajo de larga duración.

Sandboxes para agentes de codificación en flujos de trabajo de seguridad

Los ingenieros de seguridad tienden a notar antes la necesidad de sandboxes porque los flujos de trabajo ofensivos y de verificación son implacables. Un agente que está escribiendo pruebas unitarias puede perder tiempo. Un agente que está tocando un objetivo vivo, una sesión de navegador o una cadena de pruebas puede crear falsos positivos, falsos negativos o ruido destructivo.

En los flujos de trabajo que requieren mucha seguridad, el tiempo de ejecución tiene que realizar tres tareas a la vez. Tiene que restringir la ejecución, preservar suficiente estado para la repetición y soportar la verificación paralela. Por eso son tan importantes las características operativas comentadas anteriormente. La bifurcación desde el estado del navegador es valiosa cuando se exploran múltiples rutas de explotación o ramas de autorización. Los comandos en segundo plano y el almacenamiento persistente son útiles cuando un agente necesita mantener un servicio de prueba en ejecución mientras sondea el comportamiento de otro proceso. La salida denegada por defecto es útil cuando el agente sólo debe hablar con infraestructura aprobada. (Documentación sobre Freestyle)

Aquí es también donde una mentalidad de "agente codificador" puro empieza a agotarse. Un sandbox puede limitar lo que toca el agente. No puede decir por sí mismo si la conclusión del agente es fiable. En la validación de la seguridad, la hipótesis y la prueba deben permanecer separadas. El material público en inglés de Penligent es inusualmente coherente en este punto. Sus escritos sobre los arneses de Claude Code hacen hincapié en una capa de planificación, el límite de la herramienta, el modelo de aprobación, el verificador y la cadena de pruebas. Su artículo sobre Claude Code Security y Penligent enmarca el flujo de trabajo como auditoría de caja blanca más prueba de caja negra y re-verificación. (Penligente)

Esta distinción es útil mucho más allá de Penligent. Los Sandboxes resuelven el problema de los límites de ejecución. No resuelven automáticamente el problema de las pruebas. Si un agente de codificación dice "he reproducido el problema", un equipo de seguridad sigue necesitando una repetición limitada, trazas limpias, captura de artefactos y, preferiblemente, un verificador independiente en un entorno nuevo.

Para los equipos que construyen herramientas de seguridad interna, esto a menudo conduce a un diseño de dos tiempos de ejecución. Un sandbox realiza el trabajo exploratorio: lectura de repositorios, creación de arneses, configuración del navegador, sondeo de bajo riesgo. Un segundo tiempo de ejecución, o al menos una segunda identidad de agente, realiza la verificación con políticas más estrictas y un estado inicial más limpio. Esa separación es más importante que si la marca del tiempo de ejecución en la caja es Docker, GKE, Freestyle, E2B o Daytona.

Errores comunes que cometen los equipos con los entornos aislados para agentes de codificación

El primer error es pensar que un sandbox evita la inyección puntual. No es así. Limita lo que un agente secuestrado puede dañar. NIST, OpenAI y OWASP apuntan a la misma lección: el modelo puede seguir siendo manipulado por datos no fiables. El sistema es más seguro sólo si se limitan las capacidades aguas abajo. (NIST)

El segundo error es tratar el aislamiento del host como la historia completa. Los documentos de Docker dejan claro que los cambios en el espacio de trabajo están activos en el host por defecto. Si el agente edita scripts o configuraciones que los humanos ejecutan más tarde, el límite puede ser cruzado por la siguiente acción humana. La seguridad del host y la seguridad del espacio de trabajo son cosas diferentes. (Documentación de Docker)

El tercer error es confiar demasiado en los proxies secretos. La inyección de proxy es buena. Evita que las claves en bruto se queden en archivos o variables de entorno dentro del sandbox. Pero una vez que concedes rutas de red permitidas, el agente todavía puede usar esas identidades para actuar. Un sandbox que no puede leer la clave todavía puede hacer mal uso de la clave si la política permite la petición. (Documentación de Docker)

El cuarto error es dejar que las instrucciones a nivel de proyecto se extiendan. La guía de habilidades de OpenAI advierte directamente contra los catálogos de habilidades abiertos no aprobados, y las preguntas frecuentes de Docker muestran cómo la configuración a nivel de proyecto es exactamente lo que se lleva a la caja de arena. Eso significa que las habilidades, los ganchos, las instrucciones locales y la configuración del repositorio merecen la misma disciplina de revisión de código que los scripts de construcción. (Desarrolladores de OpenAI)

El quinto error es llamar a un contenedor sandbox cuando todavía tiene el socket Docker del host, amplios montajes de host, o acceso a la red sin restricciones. La propia comparación de Docker con las alternativas es contundente: un contenedor con un montaje de socket es un patrón de herramientas de confianza, no un patrón de agente autónomo. (Documentación de Docker)

El sexto error es suponer que las aprobaciones manuales se ampliarán indefinidamente. La cifra de aprobación del 93% de Anthropic es un buen recordatorio de que los seres humanos normalizan rápidamente las indicaciones repetitivas. La aprobación debe reservarse para los momentos adecuados, no para cada acción. (Antrópico)

Cómo elegir una caja de arena para los agentes de codificación

Empiece por la tarea, no por la categoría del producto.

Si su principal preocupación es proteger un puesto de trabajo de desarrollador frente a agentes locales autónomosLas cajas de arena al estilo microVM son un fuerte valor por defecto. El diseño actual de Docker es un ejemplo claro: máquina virtual aislada, demonio aislado, proxy de credenciales del lado del host, salida denegada por defecto. (Documentación de Docker)

Si su principal preocupación es ejecución de muchos trabajos de agentes no fiables dentro de la infraestructura de la plataformaPor ejemplo, en el caso de GKE Agent Sandbox con gVisor, o en el de los diseños basados en Kata, en los que el aislamiento basado en máquinas virtuales es más importante que la comodidad del desarrollador local. (Documentación sobre Google Cloud)

Si su principal preocupación es bancos de trabajo de agentes de estadoEn el caso de sesiones de larga duración, especialmente las que utilizan mucho navegador, las características que Freestyle enfatiza - suspensión, instantáneas, bifurcación, semántica Linux completa, sincronización Git - están más cerca de lo que necesitas que un ejecutor de trabajos efímeros. (Documentación sobre Freestyle)

Si su principal preocupación es incrustar sandboxing en su propio producto como objetos SDKLos modelos E2B y Daytona suelen ser más adecuados porque exponen sistemas de archivos, comandos, volúmenes y semántica de instantáneas directamente a los desarrolladores de aplicaciones. (E2B)

Elijas lo que elijas, evalúalo con la misma lista de comprobación:

• ¿Cuál es el verdadero límite de confianza?
• ¿Qué se comparte con el anfitrión, si es que se comparte algo?
• ¿Cómo se presentan los secretos al agente?
• ¿Qué rutas de red son accesibles por defecto?
• ¿Puede separar la exploración de sólo lectura de la ejecución con capacidad de escritura?
• ¿Puede reproducir, bifurcar o instantanear el estado de forma limpia?
• ¿Qué pruebas sobreviven una vez finalizada la sesión?
• ¿Qué ocurre si el agente lee instrucciones maliciosas y las obedece?

Un buen sandbox no hace que un agente de codificación sea seguro. Hace que los comportamientos inseguros sean más evitables, más inspeccionables y más contenibles.

Lecturas complementarias y referencias

• Descripción general del producto Freestyle y documentación sobre máquinas virtuales, incluyendo máquinas virtuales Linux completas, arranque en subsegundos, suspensión, instantáneas y bifurcación. (Estilo libre)
• Documentación sobre Docker Sandboxes, incluida la arquitectura, el modelo de seguridad, las capas de aislamiento, la gestión de credenciales, la postura de seguridad predeterminada y los agentes compatibles. (Documentación de Docker)
• Documentación de LangChain Deep Agents sobre sandboxes, ejecución shell, subagentes y aprobación humana. (Documentos LangChain)
• Documentación de E2B sobre entornos aislados, comandos en segundo plano, sistemas de archivos, volúmenes y controles de acceso a Internet. (E2B)
• Documentación del sandbox Daytona sobre soporte de tiempo de ejecución, instantáneas y controles del ciclo de vida. (Daytona)
• Firecracker, gVisor, y Kata Containers para las primitivas de aislamiento subyacentes a muchas cajas de arena de agentes modernas. (GitHub)
• OpenAI, NIST y OWASP sobre inyección puntual, secuestro de agentes, seguridad de habilidades e impacto limitado. (OpenAI)
• Avisos de NVD y Docker para CVE-2019-5736 y CVE-2024-21626. (nvd.nist.gov)
• Claude Code Harness for AI Pentesting, para la capa de planificación, el límite de la herramienta, el modelo de aprobación, el verificador y la cadena de pruebas en los flujos de trabajo de seguridad. (Penligente)
• AI Agents Hacking in 2026, para la visión del riesgo de los agentes desde el punto de vista de la ejecución, incluidos el secuestro y el uso indebido de herramientas. (Penligente)
• Claude Code Security y Penligent, From White-Box Findings to Black-Box Proof, para la distinción entre razonamiento y prueba en la validación de la seguridad. (Penligente)
• Página de inicio de Penligent. (Penligente)