Comparativa de sandboxes para agentes 2026: srt, gVisor, Firecracker, E2B
Has decidido que tu agente de IA necesita un sandbox. ¿Cuál? ¿Y está siquiera en la categoría adecuada para tu modelo de amenazas? La respuesta honesta en 2026 es que «sandbox para agentes» abarca dos niveles muy distintos: envoltorios ligeros basados en primitivas del sistema operativo con los que ejecutas un comando, y herramientas con un límite más fuerte (contenedores y, después, kernels en espacio de usuario y microVM). Elegir entre niveles sin decirlo es como los equipos acaban creyendo que un envoltorio de comandos es un límite a prueba de escapes. Esta guía compara el panorama y lo clasifica con honestidad, tomando como referencia srt, recién publicado como código abierto por Anthropic.
Dos categorías, dichas de entrada
- Pares reales de
srt: sandboxes ligeros, locales en el host y basados en primitivas del sistema operativo con los que envuelves un comando: bubblewrap, Firejail, nsjail, Landlock ysandbox-exec(Seatbelt) de macOS. - Otra categoría: límites más fuertes y/o servicios remotos: contenedores Docker, gVisor, Firecracker/microVM y servicios de sandbox en la nube como E2B. Los modelos de permisos en tiempo de ejecución (Deno/Bun) son, a su vez, otra categoría distinta: dentro del proceso, no a nivel del sistema operativo.
La tabla comparativa
| Herramienta | Qué es | Modelo y fuerza del aislamiento | Sistemas operativos | Lista permitida de red integrada | Categoría frente a srt |
|---|---|---|---|---|---|
| sandbox-runtime (srt) | Sandbox de sistema de archivos y red de Anthropic, basado en primitivas del sistema operativo, para agentes y CLI | Seatbelt (mac) + bubblewrap/netns+seccomp (Linux) + WFP (Win, alfa); a nivel del sistema operativo, no es una VM | macOS, Linux, WSL2; Windows en alfa | Sí: lista permitida de dominios con denegación por defecto mediante proxies HTTP y SOCKS en el host | — (referencia) |
| bubblewrap (bwrap en bruto) | Sandbox de espacios de nombres sin privilegios: el motor de Linux sobre el que se construye srt | Espacios de nombres de Linux (mount/pid/net/user); aislamiento fuerte de sistema de archivos y de procesos | Solo Linux | Ninguna (netns activado o desactivado; el proxy lo añades tú) | Par real (de más bajo nivel; srt lo envuelve) |
| Firejail | Sandbox SUID con una biblioteca de perfiles para aplicaciones de escritorio y CLI | Espacios de nombres + seccomp + capabilities; buen confinamiento de aplicaciones (la superficie SUID es un punto en contra) | Solo Linux | Reglas de netfilter/netns por perfil (más toscas que una lista permitida de dominios) | Par real |
| nsjail | Jaula de procesos de Google basada en espacios de nombres y seccomp (con origen en CTF y CI) | Espacios de nombres + seccomp-bpf + rlimits + cgroups; fuerte y muy configurable | Solo Linux | Basada en netns; sin lista permitida de dominios | Par real |
| Landlock | LSM de Linux para reglas de sistema de archivos (y, recientemente, de red) por proceso y sin privilegios | LSM del kernel; control de acceso al sistema de archivos, reglas limitadas de puertos TCP en kernels más recientes | Solo Linux 5.13+ | Mínima (a nivel de puerto en kernels más recientes); sin filtrado por dominios | Par real (primitiva/biblioteca) |
| sandbox-exec de macOS (Seatbelt) | El sandbox de perfiles integrado de Apple: el motor de mac sobre el que se construye srt | Sandbox del kernel mediante perfiles SBPL; fuerte, pero con una API obsoleta y poco documentada | Solo macOS | El perfil puede limitar host y puerto; sin lista permitida de dominios por sí solo | Par real (de más bajo nivel; srt lo envuelve) |
| Permisos de Deno / Bun | Opciones de lista permitida a nivel del runtime (--allow-read/-net/-write) | Puerta del runtime dentro del proceso; solo cubre el código que ejecuta ese runtime, no CLI hijos arbitrarios | Multiplataforma (donde funcione el runtime) | Lista permitida --allow-net=host:puerto (limitada al runtime) | Distinta (modelo de permisos del runtime, no un sandbox del sistema operativo) |
| Docker / contenedores | Aislamiento de contenedores a nivel del sistema operativo (espacios de nombres + cgroups, kernel compartido) | Contenedor con kernel compartido; más fuerte que los espacios de nombres sin más, más débil que una VM | Nativo en Linux; en mac/Win mediante una VM | iptables/políticas de red; sin lista permitida de dominios por defecto | Otra categoría (buena para anidar srt dentro) |
| gVisor (runsc) | Kernel en espacio de usuario que intercepta las llamadas al sistema antes de que lleguen al host | Intercepción de llamadas al sistema en espacio de usuario; mucho más fuerte que los contenedores, por debajo de una VM | Linux (x86-64/arm64) | Mediante la red de contenedores; sin lista permitida de dominios integrada | Otra categoría (límite de kernel más fuerte) |
| Firecracker / microVM | MicroVM KVM con su propio kernel invitado (con origen en AWS Lambda/Fargate) | Límite de VM virtualizada por hardware; el aislamiento habitual más fuerte | Host Linux/KVM | Red de VM completa; la política depende de ti | Otra categoría (microVM) |
| E2B | Servicio de sandbox en la nube para la ejecución de código de IA | MicroVM Firecracker por sesión, remotas (según varias fuentes secundarias; no confirmado con la documentación de E2B en esta sesión) | Nube (SDK multiplataforma) | Gestionada por el servicio | Otra categoría (servicio de microVM en la nube) |
| Daytona | Ejecutor de código abierto/alojado de entornos de desarrollo y sandboxes para agentes | Depende del backend: contenedores Docker por defecto, con opciones de Kata/microVM según se informa; el aislamiento depende del backend elegido | Nube + autoalojado | Red de contenedores | Otra categoría (orquestador de entornos / nube) |
| Cloudflare Sandbox / Workers | Computación en el borde: aislados V8 (Workers) + un SDK de sandbox de contenedores [SIN VERIFICAR: no confirmado con una fuente primaria en esta sesión] | Aislado V8 (el nivel más débil) para Workers; contenedor para el Sandbox SDK; remoto | Nube/borde | Salida gestionada por la plataforma | Otra categoría (nube/borde) |
| Apple Containerization | Framework que ejecuta cada contenedor Linux en su propia VM ligera en macOS [SIN VERIFICAR: detalles de conocimiento general, no confirmados con una fuente primaria en esta sesión] | MicroVM por contenedor en Apple silicon; límite de nivel VM (según se informa) | macOS (Apple silicon) | Red de VM | Otra categoría (VM por contenedor) |
Las filas marcadas como [SIN VERIFICAR] o «según se informa» no pudieron confirmarse con una fuente primaria en nuestra investigación: tómalas como orientativas, no como autorizadas. Las filas de srt y de los pares basados en primitivas del sistema operativo proceden de la propia documentación de Anthropic.
Clasificación
Nivel 1: pares ligeros locales (envolver un comando). Ganador: srt
Para envolver un agente o un comando de CLI local con la mínima configuración y una lista permitida de red integrada, srt es el par que mejor encaja. Es la única herramienta de este grupo que incluye de serie una lista permitida de dominios con denegación por defecto y una política JSON lista para usar. bubblewrap, Seatbelt, nsjail, Firejail y Landlock en bruto te dan las mismas primitivas de aislamiento (en algunos casos srt está literalmente construido sobre ellas), pero la ergonomía la construyes tú, sobre todo la capa de red. Planteamiento honesto: el valor de srt está en la ergonomía, más el proxy de lista permitida de red, más el enfoque en agentes, no en un límite de aislamiento más fuerte que bubblewrap o Seatbelt. Es esas herramientas, con una interfaz mucho más agradable.
Nivel 2: la capa intermedia, Docker
Los contenedores están entre los pares basados en primitivas del sistema operativo y las herramientas de clase VM. Un contenedor con kernel compartido aísla procesos y sistema de archivos mejor que los espacios de nombres sin más, pero peor que una VM. En la práctica, Docker es la capa pragmática de defensa en profundidad de «anida srt dentro de mí»: ejecuta el contenedor como límite exterior y srt dentro de él para la política detallada de sistema de archivos y de lista permitida de dominios.
Nivel 3: aislamiento que asume el escape, gVisor, Firecracker, E2B
Para la ejecución no fiable, multiinquilino o de «da por hecho que el código intentará escapar», sube de categoría. gVisor (un kernel en espacio de usuario) y Firecracker/microVM (virtualizadas por hardware) ofrecen un límite claramente más fuerte a cambio de más sobrecarga; E2B es la versión gestionada y alojada de ese enfoque de microVM. Aquí es donde srt explícitamente no compite: su propia documentación afirma que no es un límite de aislamiento completo, así que queda por debajo de las herramientas de clase VM en fuerza de aislamiento bruta.
Caso especial: los permisos en tiempo de ejecución (Deno/Bun)
Solo ayudan si el código del agente se ejecuta dentro de ese runtime. Las opciones --allow-net/--allow-read/--allow-write son una puerta real dentro del proceso, pero no confinan comandos de shell arbitrarios ni subprocesos lanzados. Son un complemento de un sandbox del sistema operativo, no un sustituto.
Cómo elegir, en una línea cada uno
- Desarrollo local, envolver un agente o un CLI, quieres una lista permitida de dominios con una configuración mínima:
srt. - Ya vives en Linux y quieres la primitiva en bruto: bubblewrap (o Firejail/nsjail para perfiles o configuración); después añade tu propia capa de red.
- Defensa en profundidad para un agente semifiable: Docker por fuera,
srtpor dentro. - Código no fiable o multiinquilino: gVisor o Firecracker/microVM; E2B si lo quieres alojado.
- Código del agente que se ejecuta de verdad dentro de Deno/Bun: usa las opciones del runtime además, no en su lugar.
Sea cual sea el nivel en el que acabes, combina el sandbox con visibilidad sobre a qué se conectan realmente tus agentes. Para el análisis a fondo del propio srt (mecanismo, límites y un checklist de endurecimiento de 13 puntos), lee sandbox-runtime (srt) de Anthropic, explicado. Fuentes primarias de esta comparativa: el repositorio de sandbox-runtime, el blog de ingeniería de Anthropic y la documentación de sandboxing de Claude Code.
Preguntas frecuentes
¿Cuál es el mejor sandbox para agentes en 2026?
No hay uno solo que sea el mejor: depende del modelo de amenazas. Para envolver un agente o un comando de CLI local con la mínima configuración y una lista permitida de red integrada, srt de Anthropic es el par ligero que mejor encaja. Para la ejecución no fiable o multiinquilino de «asume el escape», sube de categoría a gVisor o a Firecracker/microVM (E2B es la versión gestionada). Docker está en medio como la capa pragmática de defensa en profundidad dentro de la que anidas srt.
¿Es srt más fuerte que Docker o que una VM?
No. srt ofrece un confinamiento basado en primitivas del sistema operativo (Seatbelt en macOS, bubblewrap en Linux) y su propia documentación dice que no es un límite de aislamiento completo. Docker (contenedor con kernel compartido), gVisor (kernel en espacio de usuario) y Firecracker (microVM virtualizada por hardware) ofrecen cada uno un límite más fuerte. La ventaja de srt es la ergonomía, el enfoque en agentes y un proxy integrado de lista permitida de dominios, no la fuerza de aislamiento bruta.
¿En qué se diferencia srt de bubblewrap o Seatbelt en bruto?
srt está construido sobre ellos: bubblewrap en Linux y sandbox-exec/Seatbelt en macOS. Usar las primitivas en bruto te da la misma fuerza de aislamiento, pero tienes que preparar a mano los bind-mounts, las opciones o los perfiles SBPL y construir tú la capa de red. srt añade un formato de política JSON listo para usar y una lista permitida de dominios con denegación por defecto aplicada por proxies HTTP y SOCKS en el host, algo que las primitivas en bruto no ofrecen.
¿Sustituyen los permisos en tiempo de ejecución como los de Deno o Bun a un sandbox?
Solo en parte. Las opciones de permisos de Deno/Bun (--allow-read/-net/-write) son una puerta del runtime dentro del proceso que cubre el código que ejecuta ese runtime. Son excelentes si el agente vive dentro de Deno o Bun, pero no confinan comandos de shell arbitrarios ni subprocesos; para eso necesitas un sandbox a nivel del sistema operativo como srt o un contenedor.
¿Qué sandbox tiene una lista permitida de dominios de red integrada?
Entre los pares ligeros locales, srt destaca: incluye una lista permitida de dominios con denegación por defecto aplicada por proxies HTTP y SOCKS5 en el host. bubblewrap, Firejail, nsjail, Landlock y Seatbelt en bruto te dan controles de red de activado/desactivado o a nivel de puerto y netns, pero ninguna lista permitida de dominios de serie. Los contenedores y las VM gestionan la red a nivel de plataforma, también sin una lista permitida de dominios integrada por defecto.
¿Dónde encaja srt para la ejecución de código no fiable?
srt no es el nivel adecuado para código realmente no fiable o multiinquilino, porque no es un límite de VM. Úsalo como capa interior, anidado dentro de un contenedor (Docker) o de una microVM (Firecracker, gVisor o un servicio alojado como E2B). Así obtienes la política detallada de sistema de archivos y de red de srt más un límite exterior más fuerte que resiste un escape a nivel del sistema operativo.