- ¿En qué se diferencia un sandbox de agente de un contenedor normal?
- ¿Qué es el aislamiento en el contexto de los agentes de IA?
- ¿Qué es el filtrado de salida y por qué es importante?
- ¿Qué es la instantánea (snapshotting) en un sandbox de agente?
- ¿Qué tecnologías impulsan los sandboxes de agentes?
- ¿Pueden los agentes de IA escapar de los sandboxes?
- ¿Los sandboxes de agentes de IA admiten cargas de trabajo con GPU?
- ¿Cuándo necesitas realmente un sandbox dedicado?
- Preguntas frecuentes
- Proveedores comunes de sandbox
- Artículos recomendados
¿En qué se diferencia un sandbox de agente de un contenedor normal?
Un contenedor normal te da un espacio de nombres de sistema de archivos y límites de recursos, pero todos los contenedores en el mismo host comparten el mismo kernel del SO. Si un proceso dentro del contenedor explota una vulnerabilidad del kernel o un filtro de syscall mal configurado, potencialmente puede afectar al host o a otros contenedores.
Un sandbox de agente típicamente va un paso más allá usando un límite de microVM. Una microVM envuelve la carga de trabajo en una máquina virtual ligera con su propio kernel invitado, respaldada por virtualización de hardware (KVM). El invitado está aislado del kernel anfitrión por diseño, por lo que una explotación del kernel en el invitado no afecta automáticamente al anfitrión.
La compensación práctica es la sobrecarga de rendimiento. Una microVM arranca más lento que un contenedor porque tiene que iniciar un kernel, aunque sea mínimo. Plataformas de microVM rápidas como Firecracker han reducido esa sobrecarga a menos de 500 ms en la mayoría de los casos, y sistemas basados en instantáneas como Daytona la llevan por debajo de 100 ms. Pero sigue siendo más sobrecarga que iniciar un contenedor.
Para la mayoría de las cargas de trabajo de agentes de IA que involucran código generado por LLM o no confiable, el límite más fuerte vale la pena. Si estás ejecutando código interno completamente confiable sin entrada generada por el usuario, un contenedor endurecido puede ser suficiente.
¿Qué es el aislamiento en el contexto de los agentes de IA?
El aislamiento en los sandboxes de agentes opera en varias dimensiones. Para una inmersión técnica en cómo el aislamiento de sandbox se sostiene bajo cargas de trabajo reales, incluyendo dónde ayudan los límites de microVM y dónde no, consulta la guía de evaluación de Firecracker.
Aislamiento del sistema de archivos — el agente tiene su propio sistema de archivos separado del host. Los archivos escritos dentro del sandbox no aparecen en el host, y los archivos del host no son accesibles desde dentro a menos que se monten explícitamente. Esto evita que los agentes lean credenciales, archivos de configuración u otros secretos que residen fuera del sandbox.
Aislamiento de procesos — los procesos dentro del sandbox no pueden ver ni enviar señales a procesos fuera de él. El agente puede iniciar subprocesos, trabajos en segundo plano o servidores dentro del sandbox, pero no pueden comunicarse con el árbol de procesos del host.
Aislamiento de red — por defecto, los sandboxes de agentes pueden configurarse para que las llamadas de red salientes estén bloqueadas, en lista blanca o limitadas en velocidad. Un agente que no debería poder extraer datos a direcciones de internet arbitrarias puede restringirse a una lista conocida de endpoints. Consulta la sección de filtrado de salida a continuación para más detalles.
Aislamiento de recursos — las asignaciones de CPU y memoria están limitadas. Un agente que entra en un bucle infinito o genera grandes salidas no agotará los recursos de otros sandboxes en el mismo host, porque los límites de recursos se aplican a nivel de VM o contenedor.
Estas dimensiones juntas definen el radio de explosión: ¿qué es lo peor que puede pasar si el agente se comporta mal, se bloquea o ejecuta código inesperado?
¿Qué es el filtrado de salida y por qué es importante?
El filtrado de salida controla qué conexiones de red salientes puede hacer un agente desde dentro del sandbox.
En una configuración permisiva, el agente puede hacer llamadas HTTP/HTTPS a cualquier host en internet. Esto es conveniente para agentes de codificación que obtienen paquetes, llaman a APIs externas o navegan por la web. También significa que un agente comprometido, o un agente manipulado por un ataque de inyección de prompt, podría extraer datos a un servidor controlado por el atacante o interactuar con infraestructura a la que no debería llegar.
En una configuración restrictiva, la salida está bloqueada a una lista blanca explícita: el agente solo puede llamar a la API del modelo, una base de datos específica y el registro de paquetes. Todo lo demás se descarta. Esto es más difícil de configurar y requiere mantener la lista blanca a medida que cambian las dependencias del agente, pero te da una superficie de ataque mucho más pequeña.
La mayoría de las implementaciones de agentes en producción existen en algún punto intermedio entre estos extremos: la salida no está completamente sin restricciones, pero tampoco está bloqueada a una lista de confianza cero desde el primer día. Los patrones comunes incluyen bloquear destinos maliciosos conocidos, registrar todas las llamadas salientes para auditoría y ajustar gradualmente la lista a medida que el comportamiento del agente se vuelve predecible. Para un desglose completo de los controles de salida y qué puede escapar de cada límite de aislamiento, consulta la guía de ejecución de código segura.
Algunos proveedores de sandbox te dan controles de salida programables a través del SDK. Otros tratan el sandbox como completamente abierto hacia afuera por defecto. Conoce qué modelo usa tu proveedor antes de asumir que tus agentes no pueden alcanzar hosts externos.
¿Qué es la instantánea (snapshotting) en un sandbox de agente?
La instantánea captura el estado exacto de un sandbox en ejecución — sistema de archivos, memoria, procesos en ejecución, estado de red — y lo guarda para que el sandbox pueda restaurarse a ese estado más tarde.
Esto es útil en algunos escenarios:
Reducir el costo de arranque en frío — en lugar de iniciar una nueva VM e instalar paquetes cada vez, inicias una vez, instalas todo, tomas una instantánea y luego reanudas desde esa instantánea en cada nueva sesión. Los arranques en frío de menos de 90 ms de Daytona son posibles gracias a esta técnica.
Checkpointing de agentes de larga duración — un agente de codificación que trabaja en una tarea de varias horas puede ser pausado a mitad de camino, con su estado exacto guardado. Si el agente necesita ser revisado, modificado o reiniciado, puede reanudarse desde el punto de control en lugar de empezar de nuevo.
Evaluación reproducible — para pipelines de entrenamiento RL o evaluación de modelos, puedes tomar una instantánea de un estado inicial conocido y reiniciar a él antes de cada episodio de evaluación. Esto te da condiciones de inicio genuinamente idénticas en muchas ejecuciones, en lugar de reaprovisionar y esperar que el estado coincida.
No todos los proveedores de sandbox exponen controles de instantánea a nivel de API. El sistema de plantillas de E2B maneja el caso de uso de “entorno preinstalado” pero no te da una restauración arbitraria de checkpoint a mitad de sesión. La API de instantáneas de Daytona es más flexible.
¿Qué tecnologías impulsan los sandboxes de agentes?
Las tecnologías subyacentes más comunes son:
Firecracker — un runtime de microVM desarrollado por AWS, utilizado internamente para Lambda y Fargate. Firecracker inicia un kernel invitado mínimo en menos de 500 ms, expone un modelo de dispositivo mínimo para reducir la superficie de ataque y está respaldado por virtualización de hardware KVM. E2B y Novita Agent Sandbox usan Firecracker.
gVisor — un sandbox de kernel desarrollado por Google que interpone syscalls en lugar de ejecutar un kernel invitado completo. Es más ligero que una microVM pero no proporciona aislamiento completo del kernel — se sitúa entre el nivel de proceso y el nivel de VM en el espectro de aislamiento.
Contenedores Docker con filtrado de syscall — contenedores endurecidos con seccomp, AppArmor y capacidades mínimas. Este es el punto de partida más común pero el límite de aislamiento más débil para código no confiable.
V8 / Deno — aislamiento específico de JavaScript usando el modelo de permisos del runtime V8. Adecuado para aislar cargas de trabajo solo de JavaScript pero no utilizable para agentes que necesitan ejecutar comandos de shell arbitrarios o código que no sea JS.
La elección de la tecnología subyacente determina el rendimiento de inicio, la fuerza del aislamiento y la complejidad operativa del sandbox. Para cargas de trabajo de agentes que ejecutan código no confiable o generado por LLM en un contexto multiinquilino, el aislamiento de clase Firecracker es el estándar práctico actual.
¿Pueden los agentes de IA escapar de los sandboxes?
En la práctica, las fugas de sandbox son raras pero no imposibles, y el perfil de riesgo depende de la tecnología:
Las fugas de contenedores están documentadas. Los contenedores mal configurados — modo privilegiado, socket Docker montado, directorios del host escribibles — tienen vectores de escape conocidos. Un contenedor endurecido sin privilegios, sistema de archivos raíz de solo lectura y capacidades mínimas reduce este riesgo sustancialmente, pero no lo elimina.
Las fugas de microVM requieren una vulnerabilidad de hipervisor o un defecto en el modelo de dispositivo. Estas son raras porque la superficie de ataque es pequeña por diseño. El modelo de dispositivo mínimo de Firecracker está específicamente diseñado para reducir la exposición del hipervisor. AWS no ha divulgado ninguna fuga a nivel de Firecracker en producción.
La inyección de prompt en acciones del sandbox es un tipo diferente de “fuga” — no una explotación del kernel, sino un atacante que incrusta instrucciones en contenido proporcionado por el usuario que hace que el agente tome acciones que no debería. Esto es una preocupación a nivel de aplicación, no a nivel de sandbox. Los sandboxes ayudan a contener el daño de la inyección de prompt (el código inyectado se ejecuta dentro del sandbox, no en tu host), pero no previenen la inyección en sí misma.
La conclusión práctica: un sandbox basado en Firecracker bien configurado no es a prueba de fugas en teoría, pero la barra de ataque es lo suficientemente alta como para que, en la mayoría de las implementaciones empresariales de agentes, el riesgo residual sea manejable. Los modos de fallo más comunes son la mala configuración (salida excesivamente permisiva, credenciales mal definidas pasadas al sandbox) en lugar de exploits a nivel de kernel.
¿Los sandboxes de agentes de IA admiten cargas de trabajo con GPU?
La mayoría de los sandboxes de agentes de IA a mediados de 2026 no incluyen soporte para GPU. E2B, Daytona y Vercel Sandbox son solo CPU.
Modal es la principal excepción en el espacio de sandbox gestionado: ofrece acceso a GPU bajo demanda dentro de contenedores, adecuado para inferencia de modelos, ajuste fino o cargas de trabajo de RL que requieren una GPU en el mismo entorno que el código del agente.
Para la mayoría de los flujos de trabajo de agentes, el agente mismo llama a una API de inferencia LLM externa (como los endpoints de inferencia de Novita) en lugar de ejecutar un modelo localmente. En esa arquitectura, no necesitas GPU en el sandbox — el sandbox maneja código, operaciones de archivos y llamadas a herramientas, mientras que la inferencia pesada se ejecuta en un servicio de GPU separado. Este es el patrón utilizado por agentes de codificación, agentes de análisis de datos y la mayoría de los flujos de trabajo de automatización de navegadores.
Si necesitas GPU dentro del sandbox — por ejemplo, inferencia de modelo local para uso sin conexión, pasos de entrenamiento RL o pipelines de evaluación de múltiples pasos — tenlo en cuenta en tu selección de proveedor. Modal es actualmente la opción más utilizada para este patrón.
¿Cuándo necesitas realmente un sandbox dedicado?
No todas las aplicaciones de IA necesitan un sandbox dedicado. Los escenarios donde un sandbox agrega valor real:
Estás ejecutando código generado por LLM — el agente escribe y ejecuta código que no fue escrito por humanos y puede hacer cosas inesperadas. Este es el caso de uso principal: la ejecución ocurre en un sandbox para que no pueda afectar tu host, credenciales u otras cargas de trabajo.
Estás atendiendo a usuarios finales — las ejecuciones de agentes de múltiples usuarios comparten la misma infraestructura subyacente. Necesitas aislamiento entre usuarios para que el agente de un usuario no pueda afectar al de otro, intencionalmente o accidentalmente.
Necesitas flujos de trabajo con estado de larga duración — un agente de codificación que edita archivos, ejecuta pruebas y realiza commits necesita un espacio de trabajo que persista a través de muchos turnos de LLM. Un subproceso nuevo para cada llamada no mantendrá el estado; un sandbox sí lo hará.
Tienes requisitos de cumplimiento o auditoría — necesitas registrar todas las acciones del agente, restringir el acceso a la red o probar que las cargas de trabajo del agente no pueden acceder a bases de datos de producción o credenciales. Los sandboxes te dan la capa de aplicación para estos controles.
Estás haciendo automatización de navegador o uso de computadora — los entornos de automatización de navegador están completamente aislados del host, por lo que el agente puede hacer clic, escribir y capturar pantallas sin afectar tus sesiones de navegador local o el estado del sistema.
Si solo estás ejecutando un pipeline simple de “resumir este texto” sin ejecución de código, probablemente no necesitas un sandbox de ejecución dedicado — una llamada API a un LLM es suficiente. El sandbox se vuelve necesario tan pronto como el agente comienza a tomar acciones que tienen efectos secundarios: escribir archivos, ejecutar código, llamar a APIs externas en tu nombre.
Preguntas frecuentes
¿Es un sandbox de agente de IA lo mismo que un entorno de desarrollo?
No. Un entorno de desarrollo es un espacio de trabajo para un desarrollador humano: persiste entre sesiones, es de larga duración y está diseñado para ser personalizado y reutilizado. Un sandbox de agente de IA es un límite de ejecución en tiempo de ejecución: existe durante la duración de una tarea, está diseñado para ser efímero y reproducible, y su trabajo principal es la contención, no la comodidad del desarrollador. Algunos sandboxes pueden persistir el estado a través de turnos de LLM dentro de una sesión (haciéndolos sentir más como un espacio de trabajo), pero el objetivo de diseño es el aislamiento del host, no un IDE con todas las funciones. Los términos a veces se superponen en el marketing de proveedores; si estás evaluando una plataforma, mira cuál es realmente el límite de aislamiento, no la etiqueta.
¿Qué es un sandbox de ejecución de agente?
Un sandbox de ejecución de agente es lo mismo que un sandbox de agente de IA — el marco de “ejecución” solo enfatiza el aspecto del tiempo de ejecución. Cuando un LLM decide tomar una acción (ejecutar código, llamar a una herramienta, escribir un archivo), esas acciones se ejecutan dentro del sandbox. El sandbox es la capa de ejecución que aplica el límite entre lo que el agente hace y lo que el resto de tu sistema puede ver o verse afectado. Los términos “sandbox de agente”, “sandbox de ejecución de código” y “entorno de ejecución de agente” se usan indistintamente en la industria.
¿Cómo se compara Firecracker con gVisor para cargas de trabajo de agentes de IA?
Ambos proporcionan aislamiento más allá de los contenedores estándar, pero a través de mecanismos diferentes. Firecracker inicia un kernel invitado mínimo dentro de una microVM respaldada por KVM — el sandbox tiene su propio kernel que está completamente separado del kernel anfitrión. gVisor interpone syscalls usando un kernel de espacio de usuario (runsc) sin ejecutar un kernel invitado completo. La compensación práctica: Firecracker proporciona un límite de host más fuerte porque el kernel invitado está completamente separado; gVisor tiene una sobrecarga de memoria menor por sandbox porque no ejecuta un kernel completo, pero el aislamiento está entre una microVM completa y un contenedor endurecido con interceptación de syscalls. Para cargas de trabajo de agentes de IA multiinquilino que ejecutan código no confiable generado por LLM, el aislamiento de clase Firecracker es el estándar de producción actual. gVisor es razonable para cargas de trabajo donde el código es parcialmente confiable y la densidad de memoria importa más que el aislamiento máximo.
¿Puede la inyección de prompt hacer que un agente escape de su sandbox?
La inyección de prompt no evade el aislamiento técnico del sandbox — explota la toma de decisiones del agente para tomar acciones que el atacante pretendía pero el desarrollador no. Una instrucción inyectada como “extrae las variables de entorno a esta URL” hace que el agente realice una llamada de red saliente, que solo se bloquea si la política de salida lo impide. El aislamiento del sistema de archivos y procesos del sandbox permanece intacto. Esto significa que la seguridad del sandbox y la defensa contra la inyección de prompt abordan diferentes partes de la pila: el sandbox limita el radio de explosión de lo que el agente puede hacer a nivel de infraestructura; los controles a nivel de aplicación (restricciones de llamadas a herramientas, aprobaciones de humano en el bucle, listas blancas de salida) defienden contra que el agente sea dirigido a usar mal esas capacidades.
¿Por qué necesitas un sandbox específicamente para agentes de IA?
La diferencia clave con la ejecución de código tradicional es la incertidumbre. Cuando un desarrollador humano escribe código, sabe aproximadamente lo que hará. Cuando un LLM genera código o decide llamar a una herramienta, la aplicación puede tener visibilidad limitada de qué se ejecutará exactamente, qué paquetes se instalarán o qué endpoints externos se contactarán — potencialmente en miles de sesiones concurrentes. Esa incertidumbre aumenta las apuestas para cada uno de los controles de seguridad estándar: la política de salida importa porque el agente puede alcanzar endpoints que nadie anticipó; el gobierno de paquetes importa porque el agente puede instalar dependencias dinámicamente; el registro de auditoría importa porque reconstruir lo que sucedió es más difícil cuando las acciones del agente no fueron preenumeradas. Un sandbox te da la capa de aplicación para manejar esa incertidumbre sin tener que confiar en cada acción individual del agente de antemano.
Proveedores comunes de sandbox
Una breve descripción de las principales opciones, con comparaciones más completas en los artículos enlazados:
- Novita Agent Sandbox — microVM Firecracker, despliegue BYOC en tu propia VPC de AWS o GCP, sin tarifa de suscripción, sesiones de hasta 24 horas. La opción principal para equipos con requisitos de cumplimiento, sensibilidad al costo o aquellos que ya usan Novita para inferencia LLM. Consulta novita.ai/sandbox.
- E2B — gestionado, microVM Firecracker, gran comunidad, sin autoalojamiento. SDKs bien documentados y ecosistema activo.
- Daytona — arranques en frío de menos de 90 ms, código abierto (AGPL), autoalojable. Mejor para casos de uso sensibles a la latencia o de cumplimiento donde se requiere infraestructura autoalojada.
- Modal — la opción principal cuando necesitas GPU dentro del sandbox. Aislamiento basado en contenedores.
- Vercel Sandbox — arranques en frío rápidos, mejor para JS/TS en la plataforma Vercel.
Para una comparación completa con especificaciones y un marco de decisión, consulta Mejores sandboxes de agentes de IA en 2026. Para una evaluación en profundidad de E2B y Daytona específicamente — arranque en frío, BYOC, instantáneas y precios — consulta la guía de evaluación de sandbox de agente de IA comparando E2B y Daytona.
