Review de OpenSandbox: ¿Deberías alojar tu propia sandbox para agentes de IA?
OpenSandbox es uno de los control planes open source más completos para equipos que quieren ejecutar código, navegadores o escritorios remotos de agentes de IA en infraestructura propia. Reúne API de ciclo de vida, cinco SDK, CLI, servidor MCP, backends Docker y Kubernetes, política de red, broker de credenciales y aislamiento opcional con gVisor, Kata o Firecracker. Apache 2.0 elimina la licencia de software, no el trabajo de plataforma.
Nuestro veredicto tras revisar repositorio, documentación, releases y roadmap el 16 de agosto de 2026: incluye OpenSandbox en tu lista corta cuando el self-hosting, la elección de runtime y una API portable justifiquen operar la frontera de seguridad. Elige un servicio gestionado si importan más la velocidad de lanzamiento y un responsable externo. El quick start local con Docker no demuestra seguridad multi-tenant en producción.
Esta review responde una pregunta de compra sobre un producto concreto. Para controles de contención, usa nuestra checklist de 12 controles para sandboxes de evaluación. Para el stack de host, consulta la guía de infraestructura Linux para agentes de IA. Así evitamos confundir una review de plataforma con un estándar general de seguridad.
¿Necesitas una arquitectura de sandbox verificable antes de tocar sistemas de clientes?
Revisar la frontera del agente¿Qué es OpenSandbox?
OpenSandbox es una plataforma self-hosted para gestionar el ciclo de vida y la ejecución de sandboxes para aplicaciones de IA. El repositorio actual de OpenSandbox es público con Apache 2.0 y ofrece SDK para Python, JavaScript o TypeScript, Java o Kotlin, C# o .NET y Go. Sus ejemplos incluyen Claude Code, Gemini CLI, Codex CLI, Qwen Code y Kimi CLI, además de Chromium, Playwright, escritorios VNC y VS Code Web.
La antigua URL alibaba/OpenSandbox redirige ahora a opensandbox-group. Varios paquetes conservan Alibaba en el nombre. Las estrellas de GitHub sirven para descubrir un proyecto, no garantizan seguridad ni soporte.
| Capa | OpenSandbox aporta | Tu equipo sigue operando |
|---|---|---|
| Cliente | Cinco SDK, CLI osb, herramientas MCP y contratos OpenAPI | Orquestación, reintentos, aprobaciones y lógica de negocio |
| Control plane | Creación, estado, pausa, reanudación, caducidad, snapshots y endpoints | Autenticación, alta disponibilidad, upgrades, cuotas y política por tenant |
| Runtime | Integraciones con Docker y Kubernetes | Hosts, cluster, registry, runtime seguro y capacidad |
| Workload | Servicios de comandos, archivos y code interpreter | Hardening de imágenes, dependencias, parches y workloads permitidos |
| Red y secretos | Ingress, política de egress y Credential Vault opcional | Default deny, confianza de certificados, alcance de secretos y monitorización |
La documentación oficial de arquitectura dibuja estas fronteras. Es su mejor decisión de diseño: las aplicaciones dependen de contratos públicos y los detalles de Docker, Kubernetes, ejecución y egress quedan detrás de interfaces de proveedor.
¿Qué acierta el post viral sobre OpenSandbox?
Acierta al señalar una superficie muy amplia. No es solo un wrapper Python de docker run.
- Código, archivos y procesos: el daemon transmite comandos, gestiona jobs, archivos y métricas.
- Navegadores y escritorios: hay ejemplos oficiales de Playwright, Chromium con VNC, escritorio completo y VS Code Web.
- Agentes de código: se documentan Codex CLI, Claude Code, Gemini CLI y otros harnesses dentro de sandboxes.
- Clientes portables: cinco SDK base y OpenAPI reducen la dependencia de un lenguaje.
- Local y cluster: la misma superficie de ciclo de vida apunta a Docker o Kubernetes.
- MCP: el servidor expone herramientas de ciclo de vida, comandos y archivos de texto.
El matiz clave queda comprimido en una viñeta: gVisor, Kata y Firecracker no están activos automáticamente. El operador los elige, instala y prueba, con requisitos y fallos distintos.
¿OpenSandbox está realmente aislado?
Puede estarlo, pero el nivel de aislamiento depende del despliegue. OpenSandbox admite runc, gVisor, Kata Containers o Kata con Firecracker. La guía oficial de runtimes seguros exige que el administrador instale y configure primero el runtime. El servidor verifica su disponibilidad al arrancar y aplica la elección.
| Despliegue | Buen uso | Precaución principal |
|---|---|---|
Docker local con runc | Experimentos de confianza | Comparte kernel y no es la frontera más fuerte para código hostil multi-tenant |
| Docker con gVisor | Pilotos single-host con más aislamiento | Requiere instalación, pruebas de syscalls y hardening del host |
| Kubernetes con gVisor | Workloads escalados compatibles | Cluster, RuntimeClass, políticas, upgrades y observabilidad siguen siendo tuyos |
| Kubernetes con Kata | Workloads que necesitan un kernel invitado | Más complejidad de infraestructura, imágenes y capacidad |
| Kubernetes con Kata y Firecracker | Código de alto riesgo que justifica microVM | No es el quick start de Docker ni sustituye egress, identidad y separación del control plane |
Ningún runtime vuelve seguro un API key excesivo, un control plane escribible o una red abierta. La contención depende de toda la frontera.
¿Credential Vault mantiene las claves fuera de la sandbox?
Sí, para HTTPS compatible y si se configura bien. El SDK del host escribe la credencial real en el sidecar de egress. El workload recibe un valor falso o vacío. Cuando existe un binding exacto, el sidecar inyecta el header real y oculta secretos en sus respuestas.
La guía de Credential Vault documenta los requisitos: dns+nft, Credential Proxy, política de red y default deny. Rechaza el modo DNS-only porque una IP directa podría saltarse la política. Los sidecars transparentes de service mesh en el mismo namespace de red no son compatibles actualmente. Conviene limitar bindings por esquema, host, método y ruta.
Es una ventaja real frente a poner una clave reutilizable en el entorno del agente. Aun así, tu equipo protege ese broker. Prueba IP directas, DNS alternativo, redirects, rutas codificadas, certificados, logs y bindings ambiguos.
¿Qué tendrá que operar tu equipo?
- Control plane: autenticación, disponibilidad, versiones, copias de estado y parada de emergencia.
- Flota de runtime: hosts Docker o nodos Kubernetes, runtimes seguros, parches, imágenes y capacidad.
- Red: autenticación ingress, egress default deny, DNS, metadata, redes privadas y excepciones.
- Supply chain: imágenes aprobadas, digests, SBOM, vulnerabilidades, mirrors y rebuilds.
- Observabilidad: logs externos de ciclo de vida, comandos, archivos, red, identidad, coste y acciones de operador.
- Datos: persistencia, snapshots, borrado, ubicación y retención forense.
- Incidentes: cuotas, límites, autoridad de parada, revocación y pruebas de contención.
OpenSandbox documenta multi-tenancy en Kubernetes con namespace y API keys por tenant. Docker no lo admite. La revisión debe cubrir controllers de cluster, registry compartido, runtime de nodos, telemetría y rutas entre namespaces.
¿OpenSandbox está listo para producción?
Está listo para un piloto serio, no para producción sin revisión. El repositorio está activo, la arquitectura es explícita y existen paquetes e imágenes oficiales. Los componentes evolucionan por separado y el roadmap no planea una API v1 estable hasta que maduren la semántica del ciclo de vida, el comportamiento de runtimes y la compatibilidad de SDK.
| Pregunta | Evidencia antes del lanzamiento |
|---|---|
| ¿Puede escapar el agente? | Tests versionados contra runtime, kernel, imagen y nodo reales |
| ¿Llega a destinos no permitidos? | Tests de DNS, IP directa, IPv4, IPv6, redirects, metadata y redes privadas |
| ¿Recupera secretos? | Credenciales canary y exfiltración desde entorno, archivos, logs, procesos y errores |
| ¿Un tenant afecta a otro? | Tests cross-namespace, registry, nodos, cuotas y control plane |
| ¿Puede reconstruirse un incidente? | Trace externo inmutable con identidad, comandos, red, archivos y lifecycle |
| ¿Son seguros los upgrades? | Suite de compatibilidad para versiones fijadas de todos los componentes |
El proyecto publica un proceso de verificación de releases para código, imágenes y paquetes. Fija imágenes por digest y verifica el artefacto real. La procedencia firmada mejora la evidencia, pero no prueba una configuración segura.
¿OpenSandbox o una sandbox gestionada?
| Elige OpenSandbox si | Elige managed si |
|---|---|
| El workload debe vivir en tu cloud, cluster u on-prem | Necesitas una API funcional esta semana |
| Debes elegir gVisor, Kata o Firecracker | Quieres que un proveedor opere hosts, aislamiento y capacidad |
| Cinco SDK u OpenAPI reducen riesgo de integración | Un único SDK maduro cubre tu stack |
| Ubicación de datos y red justifican propiedad | Las regiones y controles del proveedor bastan |
| La escala puede justificar un equipo de plataforma | El uso es incierto y prefieres coste variable |
| Puedes probar y parchear la frontera continuamente | Necesitas soporte contractual y un responsable de incidentes |
Apache 2.0 significa cero licencia de OpenSandbox, no coste cero. Compara ingeniería, reserva de cluster, overhead, registry, logs, parches, guardias y evidencia con las tarifas managed. Usa el coste por acción aceptada del agente, no solo el minuto de sandbox.
Plan de piloto de 30 días
- Días 1 a 3: define un caso reversible, datos, herramientas, destinos, credenciales y resultados inaceptables.
- Días 4 a 7: valida SDK, comandos, archivos, navegador o escritorio con Docker. No lo llames arquitectura de producción.
- Días 8 a 12: prueba el workload real en gVisor o Kata y registra compatibilidad, arranque, recursos y requisitos.
- Días 13 a 17: empieza con egress default deny, añade hosts y rutas mínimos, activa Credential Vault y prueba exfiltración.
- Días 18 a 22: captura eventos inmutables de lifecycle, comandos, archivos, red, identidad, política y coste fuera de la sandbox.
- Días 23 a 26: prueba timeouts, procesos infinitos, disco, paquetes, IP directas, cruce de tenants, claves caducadas y parada.
- Días 27 a 30: compara tareas aceptadas, latencia p95, revisión, infraestructura, operación y riesgos abiertos con managed.
Escala solo si la ventaja self-hosted sobrevive al coste total. El equipo de ingeniería de productos de IA de Wavect puede diseñar la frontera, integrar el workload y construir el harness de validación. El caso Twinsoft AI muestra la disciplina de un producto real. Para decidir antes de implementar, reserva una revisión de arquitectura de IA.
Preguntas frecuentes
¿OpenSandbox es gratis y open source?
¿OpenSandbox es un proyecto de Alibaba?
¿Soporta Codex, Claude Code y Gemini CLI?
¿OpenSandbox usa Firecracker?
¿Sustituye a Kubernetes?
¿Está listo para producción enterprise?
Fuentes primarias y límites de la investigación
Esta review usa fuentes públicas revisadas el 16 de agosto de 2026. No medimos cold starts, no hicimos un test de escape independiente ni validamos un contrato comercial de soporte. Revisa de nuevo el comportamiento de cada versión antes de comprar.
- Repositorio de OpenSandbox; licencia, SDK, integraciones y alcance.
- Arquitectura; fronteras del sistema.
- Runtimes seguros; gVisor, Kata y Firecracker.
- Credential Vault; inyección y requisitos.
- Multi-Tenancy; namespaces, API keys y límite de Docker.
- Roadmap; foco y madurez de API.
- Verificación de releases; firmas, attestations y digests.
Reflexiones finales
OpenSandbox es infraestructura real para agentes. Su valor es el control, no la desaparición de la responsabilidad.
Elígelo cuando la elección de runtime, el self-hosting y las API portables creen una ventaja medible. Después demuestra toda la frontera con tests de runtime, egress, credenciales, tenants e incidentes antes de acercar un agente autónomo a sistemas valiosos.
¿Eliges entre infraestructura self-hosted y managed?
Planificar el piloto