- ¿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?
- ¿Cómo se delimitan los secretos y credenciales en un sandbox de agente? {#secrets-and-credentials}
- ¿Cómo funcionan los registros de auditoría en los sandboxes de agentes de IA? {#audit-logs}
- ¿Qué es la instantánea en un sandbox de agente?
- ¿Qué tecnologías potencian los sandboxes de agentes?
- ¿Pueden los agentes de IA escapar de los sandboxes?
- ¿Los sandboxes de agentes de IA soportan cargas de trabajo GPU?
- ¿Cuándo necesitas realmente un sandbox dedicado?
- ¿Cuál es la diferencia entre un intérprete de código y un runtime de agente? {#code-interpreter-vs-agent-runtime}
- ¿Cómo ejecutar código generado por IA de forma segura? {#run-ai-generated-code-safely}
- Preguntas frecuentes
- Proveedores comunes de sandboxes
- 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 anfitrión comparten el mismo kernel del SO. Si un proceso dentro del contenedor explota una vulnerabilidad del kernel o un filtro de syscall mal configurado, puede potencialmente afectar al anfitrión u otros contenedores.
Un sandbox de agente típicamente va un paso más allá utilizando 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 del anfitrión por diseño, por lo que una explotación del kernel en el invitado no afecta automáticamente al anfitrión.
La desventaja práctica es la sobrecarga de rendimiento. Una microVM arranca más lentamente que un contenedor porque tiene que iniciar un kernel, incluso uno mínimo. Las plataformas de microVM rápidas como Firecracker han reducido esa sobrecarga a menos de 500 ms en la mayoría de los casos, y los sistemas basados en instantáneas como Daytona la reducen 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 implican 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 sobre cómo el aislamiento del 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 anfitrión. Los archivos escritos dentro del sandbox no aparecen en el anfitrión, y los archivos del anfitrión 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 señalar 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 anfitrión.
Aislamiento de red — por defecto, los sandboxes de agentes se pueden configurar para que las llamadas de red salientes estén bloqueadas, en lista blanca o con límite de velocidad. Un agente que no debería poder exfiltrar datos a direcciones de internet arbitrarias puede restringirse a una lista conocida de endpoints. Consulta la sección de filtrado de salida más abajo 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 privará de recursos a otros sandboxes en el mismo anfitrión, 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, falla 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 realizar 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 prompts, podría exfiltrar 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 se bloquea 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 de tu 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: la salida no está completamente sin restricciones, pero tampoco está bloqueada desde el primer día a una lista de confianza cero. 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 controles de salida y qué puede aún escapar de cada límite de aislamiento, consulta la guía de ejecución segura de código.
Algunos proveedores de sandbox te dan controles de salida programáticos a través del SDK. Otros tratan el sandbox como completamente abierto a la salida por defecto. Conoce qué modelo usa tu proveedor antes de asumir que tus agentes no pueden alcanzar hosts externos.
¿Cómo se delimitan los secretos y credenciales en un sandbox de agente? {#secrets-and-credentials}
Los secretos pasados a un sandbox deben limitarse solo a lo que necesita esa ejecución específica del agente — y pasarse como variables de entorno o tokens de corta duración en lugar de credenciales de larga duración escritas en disco. El límite del sandbox limita el radio de explosión, pero no previene automáticamente que un agente lea y reenvíe cualquier credencial a la que pueda acceder dentro del entorno.
El principio central es el menor privilegio: pasa la credencial más limitada que funcione, no una clave de nube raíz o una cuenta de servicio con permisos amplios. Patrones comunes:
Variables de entorno al iniciar — inyecta un secreto en el entorno del sandbox al inicio. Está disponible para el código del agente pero no persiste en instantáneas del sistema de archivos ni aparece en los registros por defecto. Prefiere tokens de corta duración sobre claves API estáticas.
Bloqueo a nivel de DNS — algunas configuraciones de implementación te permiten restringir qué nombres DNS se pueden resolver desde dentro del sandbox. Esto evita que un agente contacte un endpoint de exfiltración de credenciales incluso si tiene acceso de red, bloqueando la resolución a nivel de DNS en lugar de por IP individual.
Cuentas de servicio limitadas con TTL corto — para agentes que llaman a APIs en la nube, usa cadenas de asunción de roles con un tiempo de vida corto. Si la credencial se filtra, la ventana del atacante está limitada por la vida del token.
Sin archivos de credenciales del anfitrión — evita montar archivos de credenciales del anfitrión (como ~/.aws/credentials) en el sistema de archivos del sandbox. Genera credenciales nuevas de corta duración por sesión en su lugar.
El sandbox proporciona el límite a nivel de procesos; tú sigues siendo responsable de lo que pasas dentro.
¿Cómo funcionan los registros de auditoría en los sandboxes de agentes de IA? {#audit-logs}
Los registros de auditoría para sandboxes de agentes típicamente cubren dos niveles: eventos a nivel de plataforma (sandbox creado, iniciado, detenido, agotado) y eventos a nivel de aplicación (comandos ejecutados, archivos modificados, llamadas API externas). La mayoría de los proveedores gestionados emiten eventos de plataforma automáticamente; el registro a nivel de aplicación es tu responsabilidad instrumentarlo.
Qué capturar para una cobertura de auditoría significativa:
Eventos del ciclo de vida del sandbox — marca de tiempo de creación, duración de la sesión, motivo de terminación (cierre normal, tiempo de espera o fallo). La mayoría de las plataformas gestionadas registran estos automáticamente y los exponen a través de API o panel.
Llamadas de red salientes — qué hosts contactó el agente, con marcas de tiempo. Aquí es donde el registro de salida y el registro de auditoría se superponen. Si tu plataforma soporta registro de salida, actívalo y dirige la salida a tu agregador de registros.
Entrada/salida de ejecución de código — los comandos que ejecutó el agente y los resultados que recibió. Esto es a nivel de aplicación y debe ser capturado en tu framework de agente, no en la capa de infraestructura del sandbox.
Mutaciones del sistema de archivos — archivos escritos, eliminados o modificados. Relevante para agentes de codificación y pipelines de procesamiento de datos. Algunas plataformas de sandbox exponen APIs de diferencias del sistema de archivos al final de la sesión; otras requieren instrumentación en tu código de agente.
Para casos de uso de cumplimiento (SOC 2, HIPAA, industrias reguladas), típicamente necesitas registros a nivel de plataforma en un almacén a prueba de manipulaciones, combinados con registros a nivel de aplicación de tu framework de agente. Verifica qué emite realmente tu proveedor versus qué requiere habilitación explícita antes de asumir cobertura.
¿Qué es la instantánea 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 arrancar una nueva VM e instalar paquetes cada vez, arrancas 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.
Puntos de control para agentes de larga duración — un agente de codificación trabajando en una tarea de varias horas puede pausarse 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 como bueno y restablecerlo antes de cada episodio de evaluación. Esto te da condiciones iniciales 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 restauración arbitraria de puntos de control a mitad de sesión. La API de instantáneas de Daytona es más flexible.
¿Qué tecnologías potencian los sandboxes de agentes?
Las tecnologías subyacentes más comunes son:
Firecracker — un runtime de microVM desarrollado por AWS, usado internamente para Lambda y Fargate. Firecracker arranca 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. Tanto E2B como Novita Agent Sandbox usan Firecracker.
gVisor — un sandbox de kernel desarrollado por Google que interpone en las llamadas al sistema 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 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 usable 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 de 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, los escapes de sandboxes son raros pero no imposibles, y el perfil de riesgo depende de la tecnología:
Los escapes de contenedores están documentados. Contenedores mal configurados — modo privilegiado, socket Docker montado, directorios del anfitrión 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.
Los escapes de microVM requieren una vulnerabilidad del hipervisor o un fallo en el modelo de dispositivo. Estos son raros 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 ningún escape a nivel de Firecracker en producción.
La inyección de prompts en acciones del sandbox es un tipo diferente de “escape” — 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 prompts (el código inyectado se ejecuta dentro del sandbox, no en tu anfitrión), pero no previenen la inyección en sí.
La conclusión práctica: un sandbox basado en Firecracker bien configurado no es a prueba de escapes 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 demasiado permisiva, credenciales mal delimitadas pasadas al sandbox) en lugar de explotaciones a nivel de kernel.
¿Los sandboxes de agentes de IA soportan cargas de trabajo GPU?
La mayoría de los sandboxes de agentes de IA a mediados de 2026 no incluyen soporte GPU. E2B, Daytona y Vercel Sandbox son solo CPU.
Modal es la principal excepción en el espacio de sandboxes gestionados — ofrece acceso GPU bajo demanda dentro de contenedores, adecuado para inferencia de modelos, ajuste fino o cargas de trabajo 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 GPU separado. Este es el patrón usado 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 fuera de línea, pasos de entrenamiento RL o pipelines de evaluación de varios pasos — tenlo en cuenta en la selección de tu proveedor. Modal es actualmente la opción más comúnmente usada 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 creado por humanos y puede hacer cosas inesperadas. Este es el caso de uso central: la ejecución ocurre en un sandbox para que no pueda afectar a tu anfitrión, credenciales u otras cargas de trabajo.
Estás sirviendo 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 confirma cambios necesita un espacio de trabajo que persista a través de muchas interacciones del LLM. Un subproceso nuevo para cada llamada no mantendrá el estado; un sandbox lo hará.
Tienes requisitos de cumplimiento o auditoría — necesitas registrar todas las acciones del agente, restringir el acceso de red o demostrar que las cargas de trabajo del agente no pueden acceder a bases de datos o credenciales de producción. 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 sandbox de automatización de navegador están completamente aislados del anfitrión, por lo que el agente puede hacer clic, escribir y tomar capturas de pantalla sin afectar tus sesiones locales de navegador o el estado del sistema.
Si solo estás ejecutando un simple pipeline de “resumir este texto” sin ejecución de código, probablemente no necesites 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.
¿Cuál es la diferencia entre un intérprete de código y un runtime de agente? {#code-interpreter-vs-agent-runtime}
Un intérprete de código ejecuta un solo fragmento de código en aislamiento y devuelve la salida. Es sin estado por defecto: cada ejecución comienza limpia, el resultado vuelve y nada persiste. Piensa en él como un kernel Jupyter en sandbox donde las celdas no comparten estado entre llamadas. Esta es la herramienta adecuada para análisis de datos, evaluación de fórmulas o ejecución de código único donde no necesitas estado entre ejecuciones.
Un runtime de agente es un entorno de ejecución persistente y con estado diseñado para flujos de trabajo de múltiples pasos. El agente puede escribir archivos, instalar paquetes, ejecutar procesos en segundo plano, hacer llamadas de red y acumular estado del espacio de trabajo a través de muchas interacciones del LLM, todo sin perder contexto entre pasos. Un agente de codificación que edita archivos, ejecuta pruebas, lee la salida de errores e itera está operando en un runtime de agente, no en un intérprete de código.
La distinción importa para el diseño de herramientas:
| Intérprete de código | Runtime de agente | |
|---|---|---|
| Estado entre llamadas | Ninguno (nuevo por ejecución) | Persistente dentro de la sesión |
| Acceso al sistema de archivos | Típicamente aislado por llamada | Espacio de trabajo persistente |
| Flujos de trabajo de múltiples pasos | No diseñado para ello | Caso de uso central |
| Duración típica de la sesión | Segundos | Minutos a horas |
| Ejemplos | Jupyter kernel, celda de código única | E2B, Daytona, Novita Agent Sandbox |
En la práctica, la línea se difumina. E2B y la mayoría de las plataformas de sandbox gestionadas pueden comportarse como un intérprete de código (ejecutar un fragmento, devolver salida) pero proporcionan la infraestructura completa de runtime de agente debajo — sistema de archivos persistente, gestión de procesos, acceso de red. Plataformas como Code Interpreter de OpenAI están diseñadas para el caso de uso sin estado y hacen concesiones deliberadas frente a la flexibilidad que proporciona un runtime de agente.
Elige un intérprete de código cuando necesites un entorno de ejecución rápido y aislado para una sola tarea sin requisitos de estado. Elige un runtime de agente cuando tu carga de trabajo implique edición iterativa de archivos, dependencias de paquetes instalados, procesos de larga duración o cualquier flujo de trabajo que necesite retomar donde lo dejó.
¿Cómo ejecutar código generado por IA de forma segura? {#run-ai-generated-code-safely}
Ejecutar código generado por IA de forma segura en producción requiere los controles adecuados en cada capa — el sandbox maneja el límite de ejecución, pero también hay decisiones a nivel de aplicación que debes tomar.
Usa aislamiento a nivel de microVM, no contenedores, para código no confiable. Los sandboxes basados en Firecracker (E2B, Novita Agent Sandbox) colocan el código generado por LLM dentro de una VM con su propio kernel. Los escapes de contenedores están documentados y tienen vectores conocidos; los escapes a nivel de microVM requieren una vulnerabilidad del hipervisor y son raros por diseño. El costo de arranque en frío vale la pena por el límite más fuerte cuando el código no fue revisado por humanos.
Restringe la salida a lo que realmente necesita el agente. Un agente que ejecuta código de análisis de datos probablemente no necesita alcanzar hosts de internet arbitrarios. Bloquea la salida a la API del modelo, un registro de paquetes específico y cualquier servicio externo que la tarea requiera explícitamente. En implementaciones BYOC, esto puede aplicarse a nivel del grupo de seguridad de la VPC. En implementaciones gestionadas, usa los controles de salida del proveedor si están disponibles, o acepta y registra la salida sin restricciones como un riesgo conocido.
Pasa solo credenciales limitadas y de corta duración. No des al sandbox acceso a bases de datos de producción, claves raíz de la nube o cuentas de servicio amplias. Pasa solo lo que necesita la tarea actual, usando credenciales con un TTL corto. Si el código generado lee y exfiltra una credencial, el daño está limitado.
Aplica tiempos de espera y límites de recursos. Establece límites explícitos de tiempo y memoria en la ejecución. Un bucle infinito generado por LLM o una salida inesperadamente grande deben terminar de manera controlada, no consumir la sesión indefinidamente ni llenar el disco.
Registra la salida y el historial de comandos desde el principio. No puedes investigar un comportamiento inesperado si no tienes un registro de lo que hizo el agente. Activa el registro de salida temprano, incluso en desarrollo. El registro a nivel de aplicación de comandos ejecutados, escrituras de archivos y llamadas externas es tu responsabilidad — la infraestructura del sandbox no hace esto automáticamente.
Ninguna configuración elimina el riesgo por completo. El objetivo es un riesgo residual conocido y acotado: el agente ejecuta código que no escribiste, dentro de un límite de aislamiento fuerte, con las credenciales y el acceso de red mínimos que necesita, y con suficiente registro para detectar y diagnosticar comportamientos inesperados.
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 entre interacciones del 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 anfitrión, no un IDE con todas las funciones. Los términos a veces se superponen en el marketing de los 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 hace el agente 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 arranca un kernel invitado mínimo dentro de una microVM respaldada por KVM — el sandbox tiene su propio kernel completamente separado del kernel del anfitrión. gVisor interpone en las llamadas al sistema usando un kernel en espacio de usuario (runsc) sin ejecutar un kernel invitado completo. La compensación práctica: Firecracker proporciona un límite de anfitrión 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 intercepción de llamadas al sistema. 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 prompts hacer que un agente escape de su sandbox?
La inyección de prompts no evita 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 “exfiltra 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 sistema de archivos y el aislamiento de procesos del sandbox permanecen intactos. Esto significa que la seguridad del sandbox y la defensa contra la inyección de prompts abordan diferentes partes del stack: 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 con intervención humana, 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, el desarrollador sabe aproximadamente lo que hará. Cuando un LLM genera código o decide llamar a una herramienta, la aplicación puede tener visibilidad limitada sobre qué exactamente se ejecutará, 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ó; la gobernanza 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 pre-enumeradas. 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 sandboxes
Una breve descripción de las principales opciones, con comparaciones más completas en los artículos enlazados:
- Novita Agent Sandbox — microVM Firecracker, implementación 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 sandboxes de agentes de IA comparando E2B y Daytona.
