Opciones de Sandbox de Agentes de IA de Código Abierto: Qué Verificar Antes de Autoalojar

Los equipos que evalúan sandboxes de agentes de IA de código abierto primero deben verificar el límite de aislamiento real, el modelo de persistencia del espacio de trabajo, los controles de tráfico de salida y paquetes, el manejo de secretos, la auditabilidad y el esfuerzo operativo necesario para ejecutarlos de forma segura. La elección correcta depende menos de encontrar un ganador universal y más de hacer coincidir un modelo de sandbox con tu modelo de amenazas, la carga de trabajo del agente, las necesidades de cumplimiento y la capacidad de ingeniería.

¿Qué se considera un sandbox de agente de IA?

Un sandbox de agente de IA es un entorno de ejecución donde un agente puede ejecutar código, inspeccionar archivos, automatizar un navegador, llamar a herramientas o completar una tarea sin obtener acceso amplio a la máquina anfitriona o a la red de producción. Es el límite entre el razonamiento del modelo y los efectos secundarios en el mundo real.

Ese límite importa porque los agentes modernos hacen más que escribir texto. Un agente de codificación puede clonar un repositorio, instalar dependencias, ejecutar pruebas, abrir puertos de vista previa y crear una solicitud de extracción. Un agente de navegador o datos puede ejecutar scripts, mantener el estado, descargar archivos y capturar capturas de pantalla. Esas acciones necesitan un entorno de ejecución, y el entorno de ejecución necesita controles.

Para una evaluación, separa cuatro capas:

Capa	Qué decide	Por qué es importante
Marco del agente	Cómo el modelo planifica, llama a herramientas y reacciona a los resultados	Un buen marco no crea automáticamente un entorno de ejecución seguro
Entorno de ejecución del sandbox	Dónde se ejecutan comandos, archivos, sesiones de navegador y procesos	Este es el principal límite de aislamiento y ciclo de vida
Plano de políticas	Qué puede leer, obtener, instalar, exponer o retener el sandbox	Determina si el sandbox coincide con tu modelo de riesgo
Plano de revisión	Qué registros, diferencias, artefactos y aprobaciones están disponibles después de la ejecución	Determina si un humano puede verificar lo que sucedió

Las opciones de código abierto y autoalojadas pueden brindar a los equipos más control sobre esas capas. También trasladan más responsabilidad al equipo que las opera.

¿Cuándo tiene sentido el autoalojamiento?

El autoalojamiento puede ser razonable cuando tu equipo necesita control directo sobre la ubicación del despliegue, las rutas de red, las imágenes base, las reglas de retención, los sistemas de registro o la revisión de seguridad interna.

Es menos atractivo cuando el requisito real es simplemente “permitir que un agente ejecute código de forma segura”. En ese caso, un sandbox administrado puede ser más fácil de operar porque el proveedor se encarga del aprovisionamiento, la escalabilidad, las actualizaciones del entorno de ejecución, la disponibilidad y partes de la experiencia del desarrollador.

Utiliza el autoalojamiento cuando al menos una de estas condiciones sea cierta:

• Tu política requiere ejecución dentro de una cuenta de nube, VPC, región o red privada específica.
• Tus agentes necesitan imágenes base personalizadas, espejos de paquetes internos, sistemas fuente privados o destinos de navegador internos.
• Tu equipo de seguridad quiere inspeccionar la pila de aislamiento, la ruta de salida, el modelo de retención y los registros.
• Tienes la capacidad de ingeniería para parchear componentes del entorno de ejecución, monitorear señales de abuso, rotar secretos y depurar fallos.

Evita el autoalojamiento por defecto cuando no puedas cubrir el trabajo operativo. Los sandboxes parecen simples durante las demostraciones porque un solo contenedor o VM puede ejecutar un comando. La producción es diferente: necesitas límites de concurrencia, cuotas de recursos, limpieza de imágenes, estrategia de caché de paquetes, política de red, alcance de secretos, telemetría, respuesta a incidentes y una ruta de actualización clara.

Opciones de sandbox de código abierto para evaluar

El panorama del código abierto se mueve rápidamente, por lo que trata esto como una orientación fechada, no como una matriz de características permanente. Al 24 de junio de 2026, estos proyectos y herramientas son ejemplos útiles para inspeccionar al comparar rutas de sandbox de agentes autoalojados o de código abierto.

Opción	Qué inspeccionar primero	Pregunta sobre autoalojamiento
E2B	Componentes de sandbox/entorno de ejecución de código abierto, SDK, plantillas y posicionamiento del sandbox basado en Firecracker	¿Qué piezas son de código abierto, qué modos de despliegue se soportan hoy y qué trabajo operativo queda para tu equipo?
Daytona	Infraestructura de espacio de trabajo y sandbox para casos de uso de desarrollo y agentes de IA, con repositorios de código abierto y rutas de documentación autoalojadas	¿Su modelo de espacio de trabajo, superficie de API y arquitectura de despliegue coinciden con tu carga de trabajo de agente y política de seguridad?
OpenHands	Plataforma de agente con una arquitectura de entorno de ejecución documentada que utiliza entornos sandbox para ejecutar acciones del agente	¿Estás adoptando la plataforma de agente completa o solo tomando prestado el patrón de entorno de ejecución?
SWE-ReX	Interfaz de entorno de ejecución de código abierto utilizada en la investigación y evaluación de agentes de ingeniería de software	¿Su abstracción se ajusta a tus necesidades de producción o es útil principalmente para arneses de evaluación controlados?
Modal Sandbox	API de sandbox administrado en lugar de un entorno de ejecución autoalojado de código abierto	Útil como punto de comparación para la ergonomía de la API, la ejecución de procesos, el sistema de archivos y el comportamiento de tiempo de espera, no como una opción autoalojada

No elijas solo de una tabla. Para cada proyecto, lee la documentación actual, inspecciona las últimas notas de la versión y ejecuta una pequeña prueba de concepto con tu propia carga de trabajo. La evaluación debe responder: qué puede ejecutarse, qué está aislado, qué persiste, qué puede alcanzar la red, qué puede ver los secretos y qué evidencia queda después de la tarea.

Límite de aislamiento: contenedores, microVMs y VMs completas

La primera pregunta no es “¿es seguro?” La pregunta útil es “¿cuál es el límite de aislamiento?”

Los contenedores son atractivos porque son rápidos, familiares y fáciles de construir alrededor de imágenes Docker. Pueden ser adecuados para trabajos internos de confianza, tareas similares a CI, análisis de corta duración y flujos de trabajo de desarrollo donde el modelo de amenazas es moderado. Pero los contenedores comparten el kernel del anfitrión, por lo que los equipos que manejan código no confiable o cargas de trabajo multiinquilino deben evaluar la exposición del kernel, los perfiles seccomp/AppArmor, los espacios de nombres de usuario, los volúmenes montados, el modo privilegiado y la respuesta a escapes.

Las microVMs, como el aislamiento estilo Firecracker, agregan un límite de VM más fuerte mientras mantienen el inicio y la densidad más cercanos a los flujos de trabajo de contenedores que a las VMs tradicionales. Son comunes en las discusiones sobre sandboxes de agentes porque pueden dar a cada sesión un kernel separado y un límite de recursos más estricto. Eso no elimina la necesidad de política de red, controles de secretos, parches o endurecimiento del anfitrión; solo aclara la capa de aislamiento del entorno de ejecución.

Las VMs completas pueden ser adecuadas para entornos empresariales más estrictos, automatización de escritorio o flujos de trabajo que necesitan una superficie de sistema operativo más amplia. La compensación es un inicio más pesado, gestión de imágenes y planificación de capacidad.

Haz estas preguntas antes de autoalojar:

Verificación	Qué verificar
Límite del kernel	¿El sandbox comparte un kernel con otras cargas de trabajo, o cada sesión tiene un kernel separado?
Límite del inquilino	¿Pueden dos sesiones de clientes compartir recursos a nivel de anfitrión, volúmenes, cachés, perfiles de navegador o espacios de nombres de red?
Modelo de privilegios	¿El sandbox ejecuta contenedores privilegiados, usuarios root, sockets Docker montados o rutas del anfitrión?
Postura de escape	¿Cómo se parchean y despliegan las vulnerabilidades del kernel, el entorno de ejecución, el contenedor y el hipervisor?
Controles de recursos	¿Se aplican CPU, memoria, disco, conteo de procesos, archivos abiertos y duración del entorno de ejecución por sesión?
Canales laterales	¿Tu modelo de riesgo requiere mitigación para CPU, caché, disco o comportamiento de vecino ruidoso compartidos?

Si un proyecto se describe a sí mismo como “aislado”, sigue leyendo hasta que conozcas el mecanismo.

Estado, archivos y ciclo de vida del espacio de trabajo

El trabajo del agente es con estado incluso cuando el sandbox es efímero. El agente puede crear archivos, instalar paquetes, mantener un perfil de navegador, ejecutar procesos en segundo plano o pausar mientras un humano revisa un artefacto. Tu sandbox necesita un modelo de espacio de trabajo claro.

Comienza con el ciclo de vida:

1. Crear un sandbox a partir de una imagen base o plantilla.
2. Montar o clonar el espacio de trabajo permitido.
3. Ejecutar comandos de configuración bajo política.
4. Permitir que el agente ejecute comandos, acciones del navegador y operaciones de archivos.
5. Extraer salidas: diferencias, registros, capturas de pantalla, informes o archivos descargados.
6. Detener, pausar, guardar instantánea, archivar o destruir el sandbox.

El punto crítico es que la persistencia debe ser intencional. Los espacios de trabajo persistentes son útiles para agentes de larga duración, tareas de codificación de múltiples pasos y revisión con intervención humana. También son donde las credenciales obsoletas, las dependencias en caché, las cookies del navegador, los datos generados y el trabajo parcial pueden filtrarse entre sesiones si la limpieza es débil.

Antes de autoalojar, define:

• Si cada tarea del agente obtiene un sistema de archivos nuevo.
• Si los cachés de paquetes se comparten, se limitan o se reconstruyen.
• Si los perfiles del navegador persisten entre ejecuciones.
• Si las cargas de usuario se copian, montan o transmiten.
• Si las instantáneas incluyen secretos, tokens, cookies o registros internos.
• Durante cuánto tiempo se retienen los registros y artefactos.
• Quién puede reabrir una sesión pausada.

Un buen sandbox hace que el ciclo de vida predeterminado sea aburrido. Debes poder explicar qué existe antes de que comience la tarea, qué cambia durante la tarea y qué queda después de la limpieza.

Red, paquetes y política de tráfico de salida

El acceso a la red es donde muchos diseños de sandbox se vuelven vagos. Los agentes a menudo necesitan internet, pero “acceso a internet” no es un permiso único.

Un agente de codificación puede necesitar registros de paquetes, documentación pública, remotos Git y una URL de vista previa. Un agente de navegador puede necesitar una aplicación de prueba, una API de prueba y almacenamiento de capturas de pantalla. Un agente de datos puede necesitar almacenamiento de objetos, una réplica de base de datos o una API SaaS restringida. Esos son permisos diferentes con diferentes riesgos.

Usa categorías:

Tipo de salida	Necesidad típica	Pregunta de política
Registros de paquetes	npm, pip, apt, cargo, dependencias de modelo/herramienta	¿Los registros están en lista blanca, en caché, escaneados y registrados?
Web pública	Búsqueda de documentación, tareas de navegador, recolección de datos públicos	¿Se permite la navegación arbitraria, se proxy, se limita la velocidad y se audita?
Acceso Git	Clonar repos, empujar ramas, obtener submódulos	¿Los tokens son de solo lectura cuando es posible y están limitados a la tarea?
APIs internas	Servicios de staging, aplicaciones de prueba, espejos de paquetes privados	¿El acceso está limitado por entorno, servicio, ruta y credencial?
Entrada de vista previa	Revisión humana de aplicaciones web locales o informes generados	¿Qué puerto se expone, a quién, durante cuánto tiempo y con qué autenticación?
Webhooks	Callbacks del agente, eventos de CI, integración de herramientas externas	¿Puede el sandbox enviar callbacks salientes a hosts arbitrarios?

La política de paquetes merece atención especial. Muchas tareas del agente fallan sin instalaciones de dependencias, pero las instalaciones de paquetes traen scripts posteriores a la instalación, binarios nativos, riesgo de compromiso del registro, riesgo de typosquatting y largas vidas de caché. Prefiere instalaciones basadas en archivos de bloqueo, registros aprobados, tokens de corta duración y registros de instalación.

Para sistemas autoalojados, también decide quién es dueño de los registros DNS, la configuración del proxy, los almacenes de certificados de confianza y la respuesta a incidentes de red.

Secretos, registros y pistas de auditoría

Un sandbox de agente no debe convertirse en un lugar donde las credenciales en bruto sean fáciles de imprimir, copiar o exfiltrar para el modelo.

El patrón más seguro es el acceso limitado a la tarea. Dale al sandbox la credencial mínima necesaria para el trabajo y elimínala cuando el trabajo termine. Una tarea de codificación puede necesitar un token de repositorio de solo lectura y un token de solicitud de extracción. Una tarea de navegador puede necesitar una cuenta de prueba, no un usuario de producción. Una tarea de datos puede necesitar una URL firmada temporal, no una credencial de nube permanente.

Evita secretos en archivos que el agente pueda leer casualmente. Las variables de entorno son convenientes, pero muchos comandos de depuración imprimen el estado del entorno. Si la plataforma admite acciones intermediadas, úsalas: permite que el sandbox realice una operación estrecha sin exponer la credencial en bruto al bucle del modelo.

El registro debe ser lo suficientemente sólido para la revisión y la respuesta a incidentes:

• Comandos solicitados, aprobados, denegados y ejecutados.
• Directorio de trabajo, código de salida, stdout, stderr, tiempo de espera y uso de recursos.
• Artefactos de archivo producidos por la tarea.
• Destinos de red con la granularidad que admita tu política.
• Nombres de paquetes, versiones, registros y salida de instalación.
• Decisiones de redacción de secretos y fallos de redacción.
• Aprobaciones humanas para acciones riesgosas.

El objetivo no es ahogar a los revisores en registros. El objetivo es reconstruir lo que sucedió cuando un agente produce una salida sorprendente, una dependencia cambia o se sospecha que un token está expuesto.

Restablecimiento, instantáneas y riesgo multiinquilino

El comportamiento de restablecimiento es una característica de producción, no un script de limpieza al final de una demostración.

Los sandboxes efímeros son más simples de razonar: crear, ejecutar, extraer artefactos, destruir. Funcionan bien para ejecución de código corta, acciones de navegador únicas y trabajos de evaluación. Los sandboxes persistentes ayudan con flujos de trabajo más largos, pero necesitan controles de propiedad, caducidad y revisión.

Las instantáneas y plantillas se sitúan entre esos modelos. Pueden acelerar el inicio al preservar un entorno preparado, pero también preservan todo lo que hay dentro de la instantánea. Verifica si incluyen:

• Paquetes instalados y cachés.
• Historial del shell o estado del proceso.
• Cookies del navegador, almacenamiento local y descargas.
• Archivos temporales y salidas generadas.
• Credenciales o archivos de configuración.
• Registros de tareas anteriores.

Para sistemas multiinquilino, pregunta cómo el programador coloca las cargas de trabajo, si los cachés se comparten, cómo se borran los discos y cómo se monitorean los recursos a nivel de anfitrión. También pregunta qué sucede durante los fallos. Un sandbox que se bloquea, agota el tiempo de espera o pierde su controlador aún necesita limpieza y manejo de artefactos.

Acceso del desarrollador y rutas de depuración

Los sandboxes autoalojados necesitan una historia práctica de depuración. Cuando un agente falla, los desarrolladores necesitan saber si el problema es el modelo, la llamada a la herramienta, el entorno de ejecución, la imagen, el espejo de paquetes, la ruta de red o la aplicación de destino.

Las rutas de depuración útiles incluyen:

• Una forma de reproducir comandos desde la misma imagen base.
• Registros estructurados para la ejecución de comandos y llamadas a herramientas.
• Artefactos descargables y capturas de pantalla.
• Errores explícitos de tiempo de espera y límite de recursos.
• Una forma controlada para que un desarrollador se conecte a una sesión en vivo cuando la política lo permita.
• Plantillas o imágenes versionadas para que los fallos se puedan vincular a una versión del entorno.
• Separación clara entre la salida visible para el usuario y los registros internos del entorno de ejecución.

Ten cuidado con el acceso de emergencia. El acceso amplio al shell en sandboxes en vivo puede violar los mismos supuestos de aislamiento que el sandbox fue construido para hacer cumplir. Define quién puede conectarse, qué pueden ver, si los secretos se redactan y cómo se registra el acceso.

Dónde encaja Novita Agent Sandbox

Novita Agent Sandbox es un entorno de ejecución de agente administrado para ejecución de código, automatización de navegador, flujos de trabajo de estilo de uso de computadora, análisis de datos, evaluaciones y flujos de trabajo de agente de larga duración. La documentación de Novita Agent Sandbox describe un entorno de sandbox con estado con rutas de SDK y CLI para el ciclo de vida, comandos, archivos, sesiones de navegador y primitivas de flujo de trabajo relacionadas.

Eso hace que Novita sea adecuado para evaluar cuando tu equipo quiere infraestructura de ejecución de agente sin asumir toda la carga de operaciones autoalojadas desde el primer día.

Mantén el límite claro:

• Usa entornos de ejecución de código abierto o autoalojados cuando el control de despliegue, la personalización a nivel de fuente o la propiedad de la infraestructura interna sean la prioridad.
• Usa un sandbox administrado cuando la adopción más rápida, las operaciones de entorno de ejecución gestionadas por el proveedor y un flujo de trabajo basado en API sean más importantes que poseer cada capa.
• En cualquier caso, evalúa el aislamiento, la salida, las instalaciones de paquetes, los secretos, los registros, la persistencia y las puertas de revisión según tu propia política.

No trates ningún nombre de proveedor como una garantía de seguridad. Trátalo como una elección de entorno de ejecución que aún necesita revisión de arquitectura.

Lista de verificación para autoalojamiento

Usa esta lista de verificación antes de llevar un sandbox de agente de IA de código abierto a producción.

Área	Pregunta mínima antes de producción
Aislamiento	¿El límite es contenedor, microVM, VM completa u otra cosa, y es suficiente para la carga de trabajo?
Espacio de trabajo	¿Cada tarea comienza desde un estado de sistema de archivos conocido y se puede restablecer?
Persistencia	¿Las pausas, reanudaciones, instantáneas y retención son explícitas en lugar de accidentales?
Red	¿Las descargas de paquetes, la navegación, las llamadas API, Git, los webhooks y la entrada de vista previa están controlados por separado?
Paquetes	¿Los archivos de bloqueo, los registros, los scripts posteriores a la instalación, los binarios nativos y los cachés están gobernados?
Secretos	¿Las credenciales están limitadas a la tarea, redactadas, rotadas y no disponibles para comandos no relacionados?
Registros	¿Puede un revisor reconstruir comandos, salidas, cambios de archivos, rutas de red y aprobaciones?
Multiinquilino	¿Se comprenden el uso compartido del anfitrión, el uso compartido de caché, la limpieza de discos, las cuotas y el comportamiento de vecino ruidoso?
Depuración	¿Pueden los ingenieros reproducir fallos sin eludir el modelo de seguridad?
Operaciones	¿Quién parchea imágenes, entornos de ejecución, kernels, dependencias y controladores de sandbox?
Controles de abuso	¿Se aplican tiempos de espera, límites de recursos, límites de velocidad y rutas de eliminación?
Ruta de salida	¿Se pueden exportar y revisar los artefactos incluso si el sandbox se bloquea o agota el tiempo de espera?

Si varias respuestas no están claras, mantén el proyecto en un carril de prototipo. Un sandbox que no puede explicar sus límites no está listo para ejecutar trabajo de agente no confiable a escala.

Preguntas frecuentes

¿Cuál es el mejor sandbox de agente de IA de código abierto?

No existe un único mejor sandbox de agente de IA de código abierto para todos los equipos. La elección correcta depende de tu requisito de aislamiento, modelo de despliegue, carga de trabajo del agente, política de salida, necesidades de persistencia y capacidad de operaciones. Compara opciones ejecutando tu propia tarea dentro de cada entorno de ejecución candidato.

¿Es Docker suficiente para un sandbox de agente de IA?

Docker puede ser suficiente para automatización interna de confianza, desarrollo local y trabajos similares a CI, pero puede no ser suficiente para código no confiable o cargas de trabajo multiinquilino estrictas. Verifica el uso compartido del kernel, los privilegios, los volúmenes montados, el acceso a la red, los secretos y la respuesta a escapes antes de confiar solo en contenedores.

¿Son las microVMs más seguras que los contenedores para cargas de trabajo de agentes?

Las microVMs pueden proporcionar un límite de aislamiento más fuerte porque cada sandbox puede ejecutarse con un kernel separado. Eso no resuelve automáticamente la salida, los paquetes, los secretos, el registro, los parches o las operaciones multiinquilino. Trata las microVMs como una parte de la arquitectura, no como todo el modelo de seguridad.

¿Qué debo probar antes de autoalojar un sandbox de agente?

Prueba una carga de trabajo real que clone o monte archivos, instale dependencias, ejecute comandos, maneje secretos, alcance destinos de red aprobados, produzca artefactos, agote el tiempo de espera y se restablezca. También prueba las rutas de fallo: fallo de instalación de paquetes, bloqueo del navegador, denegación de red, límite de recursos y limpieza del sandbox después de un error del controlador.

¿Cuándo debo usar un sandbox administrado en lugar de autoalojar?

Usa un sandbox administrado cuando tu equipo quiera la API de ejecución de agente y los artefactos de revisión sin tener que encargarse del parcheo del entorno de ejecución, la escalabilidad, la planificación de capacidad y las operaciones de infraestructura. Autoaloja cuando el control de despliegue o la personalización a nivel de fuente sea lo suficientemente importante como para justificar ese trabajo.

Artículos recomendados

• Ejecuta Codex o un agente de codificación en un sandbox seguro
• Cómo los sandboxes de agentes impulsan una innovación de IA segura y escalable
• Construyendo un agente de codificación con Novita Agent Sandbox