Si su agente de IA puede escribir código, puede escribir código defectuoso. Si puede llamar a herramientas, puede llamar a la herramienta equivocada con los argumentos incorrectos. La solución no es un prompt más inteligente. Es un límite de aislamiento entre la salida del modelo y la máquina que lo ejecuta. CubeSandbox es uno de los sistemas construidos exactamente para ese límite, y vale la pena comprender qué hace, cómo se compara con otros enfoques y dónde encaja cuando sus agentes comienzan a interactuar con APIs y datos reales.
En resumen
CubeSandbox es un servicio de sandbox con aislamiento de hardware de código abierto de Tencent Cloud para ejecutar código de agentes de IA. Cada sandbox obtiene su propio kernel de SO invitado a través de KVM, arranca en aproximadamente 60 ms y usa menos de 5 MB de sobrecarga de memoria. Tiene licencia Apache 2.0 y es compatible directamente con el SDK de E2B.
Introducción
Los sistemas agenticos ahora están escribiendo y ejecutando código en producción. Un agente de codificación genera un script de Python y lo ejecuta. Un agente de investigación raspa una página, la analiza e introduce el resultado en otro paso. Un agente de datos carga un CSV y ejecuta transformaciones que el modelo decidió en tiempo de ejecución. Ninguno de esos códigos fue revisado por un humano antes de ejecutarse. Ese es el problema central que resuelve el sandboxing de agentes: necesita ejecutar instrucciones no confiables generadas por el modelo sin darles acceso a su host, su sistema de archivos, sus credenciales o su red.
Esto es más importante a medida que los agentes ganan autonomía. Un modelo que se equivoca en una consulta SQL es molesto. Un modelo que se equivoca con `rm -rf` o que sigue una instrucción inyectada dentro de una página web raspada es un incidente de seguridad. El sandboxing traza una línea dura: el agente puede hacer lo que quiera dentro de un entorno desechable y aislado, y nada de lo que haga se filtra.
Hay un segundo problema, más silencioso. Los agentes no solo ejecutan código; llaman a APIs y herramientas. Antes de confiar en un agente para acceder a su API de pagos o a sus servicios internos desde dentro de un sandbox, necesita saber que esas APIs se comportan correctamente y que el agente las llama de la manera que usted espera. Ahí es donde las herramientas de API ganan su lugar junto al aislamiento en tiempo de ejecución. Una plataforma como Apidog le permite simular y probar los endpoints que llamará un agente, para que valide el contrato antes de que un sistema autónomo comience a operarlo en una ejecución en sandbox. Si ya está pensando en la arquitectura de agentes, nuestra guía sobre arquitectura de IA agentica cubre cómo se combinan estas capas de ejecución y herramientas.
El resto de este artículo explica qué es CubeSandbox, por qué los agentes necesitan un sandbox, cómo difieren los modelos de aislamiento y cómo esto se conecta con la prueba de las APIs de las que dependen sus agentes.
¿Qué es CubeSandbox?
CubeSandbox es un sistema de sandbox de seguridad para ejecutar código de agentes de IA, de código abierto por Tencent Cloud bajo la licencia Apache 2.0 en abril de 2026. Su lema en GitHub lo describe claramente: "Sandbox instantáneo, concurrente, seguro y ligero para agentes de IA". No es solo un SDK. Es la pila completa de sandbox como servicio, escrita principalmente en Rust, que puede implementar usted mismo.
La arquitectura está construida sobre RustVMM y KVM, la misma capa de virtualización del kernel de Linux utilizada por muchos hipervisores en la nube. Según la documentación del proyecto y el anuncio oficial, el sistema se divide en varios componentes:
- CubeAPI: una puerta de enlace REST que refleja la interfaz de sandbox de E2B.
- CubeMaster: el orquestador de clústeres que programa sandboxes en los nodos.
- CubeHypervisor y CubeShim: la capa de virtualización KVM que arranca y gestiona cada microVM.
- Cubelet y CubeProxy: agentes a nivel de nodo que ejecutan y enrutan a los sandboxes.
- CubeVS: una capa de red impulsada por eBPF que impone el aislamiento de red entre sandboxes a nivel del kernel.
La característica principal es que cada sandbox obtiene su propio kernel de SO invitado dedicado. Ese es un modelo de aislamiento diferente y más fuerte que un contenedor, que comparte el kernel del host. Los números publicados por Tencent indican un arranque en frío de aproximadamente 60 ms a concurrencia única (un promedio de 67 ms con P95 alrededor de 90 ms bajo 50 creaciones concurrentes), menos de 5 MB de sobrecarga de memoria por instancia y la capacidad de ejecutar miles de sandboxes en un solo host grande. Los materiales de prensa citan un servidor de 96 vCPU que soporta más de 2.000 sandboxes concurrentes. Tencent dice que CubeSandbox se ha ejecutado a escala dentro de su propia infraestructura y que MiniMax lo ha utilizado para el entrenamiento de aprendizaje por refuerzo agentico a gran escala en entornos heterogéneos.
Algunas características avanzadas, como la reversión de instantáneas a nivel de evento para la creación de puntos de control y la restauración del estado del sandbox, se describen como todavía en desarrollo. Trate los elementos prospectivos como una hoja de ruta, no como garantías entregadas, y consulte el repositorio para conocer el estado actual. La metodología de evaluación comparativa pública más allá de las propias cifras del proveedor es limitada, así que valide las afirmaciones de rendimiento con su propia carga de trabajo.
Para los detalles canónicos, la fuente de verdad es el repositorio de GitHub de CubeSandbox y el sitio de documentación oficial.
Por qué los agentes de IA necesitan un sandbox
Ayuda ser concreto acerca de las amenazas, porque "seguridad" es demasiado vago para diseñar contra ella. Hay tres modos de fallo que empujan a los equipos hacia el sandboxing.
Código generado riesgoso. Un modelo produce código que cree que es correcto. A veces no lo es. Elimina el directorio equivocado, agota la memoria en un bucle cerrado o escribe un archivo donde no debería. Nada de esto es malicioso; simplemente está mal, y el código incorrecto con acceso al host es peligroso. El agente no tiene concepto de radio de explosión a menos que usted se lo dé.
Llamadas a herramientas no confiables. Los agentes llaman a herramientas y APIs basándose en lo que el modelo decide en tiempo de ejecución. Si el modelo es dirigido por una inyección de prompt oculta en un documento, una página web o una respuesta de herramienta, puede llamar a una herramienta destructiva, pasar argumentos controlados por el atacante o encadenar llamadas de una manera que nunca se pretendió. El modelo no es un actor confiable aquí; es un intérprete de cualquier texto que llegue a su ventana de contexto. Profundizamos en esto en nuestro artículo sobre agentes de IA como los nuevos consumidores de API, que cubre por qué las suposiciones tradicionales de confianza en las API se rompen con los llamadores autónomos.
Exfiltración de datos. Este es el que la gente subestima. Un agente con acceso a la red y acceso a secretos puede convertirse en un canal de exfiltración. Una instrucción envenenada le dice al agente que lea una variable de entorno que contiene una clave API y la envíe a un endpoint externo. Sin filtrado de salida y aislamiento de credenciales, el límite del sandbox no tiene sentido porque los datos salen por la puerta principal. Es por eso que CubeSandbox combina el aislamiento a nivel de kernel con el filtrado de salida basado en eBPF a través de CubeVS; el aislamiento del proceso no es suficiente si la red está completamente abierta.
El hilo conductor: no puede asumir que el agente se comportará, porque el comportamiento del agente está parcialmente controlado por cualquier dato no confiable que haya ingerido. Un sandbox le permite dejar de razonar si el modelo es confiable y comenzar a razonar sobre un límite que se mantiene de todos modos. Para una visión práctica de cómo probar estos comportamientos antes de que lleguen a producción, consulte cómo probar agentes de IA que llaman a APIs.
Cómo funcionan los sandboxes de agentes: los modelos de aislamiento
No todos los sandboxes aíslan de la misma manera, y las diferencias importan tanto para la seguridad como para el rendimiento. Hay cuatro enfoques amplios que verá en el ecosistema de agentes.
Aislamiento a nivel de proceso. Ejecute el código como un proceso de SO restringido con filtros seccomp, capacidades eliminadas, espacios de nombres y cgroups. Esta es la opción más ligera y débil. Comparte el kernel del host, por lo que una explotación del kernel significa un compromiso del host. Bien para código en el que confía en su mayoría; endeble para la salida arbitraria del modelo.
Contenedores. Los contenedores tipo Docker agregan espacios de nombres y límites de recursos y son operativamente familiares. Pero los contenedores comparten el kernel del host por diseño. Las vulnerabilidades de escape de contenedores son una clase de errores real y recurrente, y "código no confiable en un contenedor de kernel compartido" es un punto débil conocido. Muchos equipos comienzan aquí porque es fácil, luego alcanzan el límite de aislamiento.
MicroVMs. Una microVM arranca un kernel invitado mínimo dentro de la virtualización de hardware (KVM). El código del agente se ejecuta contra su propio kernel, por lo que una explotación a nivel de kernel se contiene en una VM desechable, no en el host. Firecracker popularizó este modelo para cargas de trabajo sin servidor, y CubeSandbox se encuentra en esta categoría, utilizando RustVMM y KVM con un kernel invitado por sandbox. El compromiso histórico fue el tiempo de inicio; las microVMs eran más lentas de arrancar que los contenedores. Las implementaciones modernas abordan eso con instantáneas y preaprovisionamiento de recursos, que es la forma en que CubeSandbox reporta inicios de menos de 100 ms.
Kernels de aplicaciones. gVisor toma un camino diferente: intercepta las llamadas al sistema en el espacio de usuario e implementa una interfaz similar a Linux por sí mismo, por lo que la carga de trabajo nunca habla directamente con el kernel del host. Es una capa de aislamiento fuerte sin una VM completa, con algunas compensaciones de compatibilidad de llamadas al sistema y rendimiento.
Así es como se comparan los enfoques en las dimensiones que importan para los agentes:
| Enfoque | Fuerza de aislamiento | Arranque en frío | Sobrecarga | Compartición de kernel | Ejemplos |
|---|---|---|---|---|---|
| Proceso + seccomp | Baja | Instantáneo | Mínima | Kernel del host compartido | Subproceso restringido, nsjail |
| Contenedores | Media | ~decenas de ms | Baja | Kernel del host compartido | Docker, containerd |
| MicroVM | Alta | ~50–150ms | Baja–media | Kernel invitado dedicado | CubeSandbox, Firecracker |
| Kernel de aplicación | Alta | ~decenas de ms | Baja–media | Interceptado en espacio de usuario | gVisor |
| API de sandbox alojada | Alta (gestionada) | Varía | Gestionada para usted | Gestionada para usted | E2B, ofertas alojadas |
No hay un único ganador. La decisión correcta depende de cuánto confíe en el código, qué tan rápido necesite arranques en frío, si puede ejecutar KVM y si desea operar la infraestructura usted mismo o consumirla como un servicio.
CubeSandbox en el panorama
El posicionamiento de CubeSandbox es específico: aislamiento a nivel de hardware con arranques en frío lo suficientemente rápidos como para sentirse como un contenedor, implementado como algo que usted ejecuta en lugar de un servicio que alquila. Eso lo sitúa en una comparación conceptual directa con tres puntos de referencia.
Frente a contenedores. Un contenedor comparte el kernel del host; CubeSandbox le da a cada sandbox el suyo propio. Para código arbitrario generado por agentes, ese es el argumento de seguridad. El costo es que necesita un host Linux x86_64 habilitado para KVM (un servidor bare-metal, una VM en la nube que admita virtualización anidada o WSL 2 para trabajo local). Si su plataforma no puede exponer KVM, el aislamiento basado en microVM no está disponible para usted y un enfoque de espacio de usuario como gVisor o una API alojada puede ser más adecuado.
Frente a Firecracker. Firecracker es la conocida microVM para funciones sin servidor y es en sí misma un bloque de construcción, no un producto de sandbox para agentes. CubeSandbox también se basa en KVM/RustVMM, pero se envía más arriba en la pila: un orquestador, una puerta de enlace API compatible con E2B y aislamiento de red eBPF, por lo que está implementando un servicio de sandbox para agentes en lugar de ensamblar uno. Si desea primitivas, Firecracker. Si desea un servicio de sandbox con una API con forma de agente, CubeSandbox apunta a eso.
Frente a E2B y sandboxes alojados. E2B proporciona sandboxes aislados como un servicio gestionado; usted llama a una API y la infraestructura es problema de otra persona. La notable elección de diseño de CubeSandbox es la compatibilidad con el SDK de E2B. La documentación lo describe como un reemplazo directo: apunte `E2B_API_URL` a su instancia de Cube autoalojada y el código existente seguirá funcionando. Eso hace que la decisión real sea menos "qué sandbox" y más "servicio gestionado versus infraestructura autoalojada", con la residencia de datos, el costo a escala y la propiedad operativa como factores decisivos. También es compatible de forma nativa con el SDK de Python de OpenAI, según el anuncio de Tencent.
El resumen honesto: CubeSandbox es una entrada creíble en el espacio de sandbox de agentes con una tesis clara (aislamiento fuerte, arranques rápidos, autoalojado, compatible con E2B). También es nuevo y está documentado en gran medida por su proveedor, por lo que los benchmarks independientes son escasos. Pruébelo con su carga de trabajo y mida el arranque en frío, la densidad y el comportamiento de aislamiento antes de comprometerse.
Cómo esto se conecta con la prueba de las APIs y herramientas que llaman sus agentes
El aislamiento en tiempo de ejecución responde a "¿qué pasa si el código es malo?". No responde a "¿qué pasa si la API que llama el agente es mala, o el agente la llama mal?". Esos son problemas diferentes, y necesita cubrir ambos.
Imagine un agente en sandbox que reserva viajes. El código se ejecuta de forma segura dentro de CubeSandbox. Pero el agente todavía llama a una API de vuelos, una API de pagos y un servicio interno de itinerarios. Si alguno de ellos devuelve una respuesta mal formada, el agente puede entrar en un bucle, alucinar una recuperación o pasar datos incorrectos aguas abajo. Si llama a la API de pagos con la clave de idempotencia incorrecta, el aislamiento no lo salvará; el dinero todavía se mueve. El sandbox protege al host del agente. No protege sus sistemas de un agente confundido que realiza llamadas reales a servicios reales.
Así que el flujo de trabajo que realmente funciona tiene dos capas trabajando juntas:
- Aislar la ejecución para que el código generado por el modelo y las invocaciones de herramientas no puedan dañar el host ni exfiltrar datos. Esa es la capa de CubeSandbox.
- Validar el contrato de cada API y herramienta a la que el agente puede acceder, antes y durante las ejecuciones en sandbox. Esa es la capa de herramientas de API.
Para la segunda capa, simule las dependencias para que el agente hable con un sustituto controlado mientras prueba el comportamiento, luego pruebe los endpoints reales para la conformidad del esquema, el manejo de errores, la autenticación y los casos extremos. Con Apidog puede construir un servidor simulado que devuelve respuestas deterministas y precisas en el esquema, apuntar el agente en sandbox a él y observar cómo reacciona el agente tanto a las rutas de éxito como a las de error sin tocar la producción. Cuando esté listo, ejecute los mismos escenarios contra la API en vivo para confirmar que el contrato se mantiene. Nuestro recorrido sobre pruebas de sandbox cubre la práctica general de probar contra entornos aislados y controlados, lo que se aplica directamente aquí.
Este emparejamiento es importante porque los agentes amplifican la desviación del contrato. Un humano nota cuando una respuesta de API parece extraña. Un agente a menudo no lo hace; ingiere la respuesta y actúa en consecuencia. Los contratos de API estrictos, ejercidos con simulaciones y pruebas, evitan que un llamante autónomo convierta una sola respuesta incorrecta en una cascada. Si sus agentes hablan el Protocolo de Contexto del Modelo (MCP), probar servidores MCP con Apidog extiende la misma disciplina a la capa de herramientas. Y si está diseñando APIs para consumidores de agentes, diseñar APIs para agentes de IA cubre los patrones de contrato que hacen que las llamadas autónomas sean predecibles.
Casos de uso del mundo real
Algunos patrones donde el enfoque de aislamiento más contrato muestra su valor:
Agentes de codificación e intérpretes de código. Un modelo escribe y ejecuta código para responder una pregunta, transformar datos o generar un gráfico. Este es el caso de uso canónico de sandbox y el que las API compatibles con E2B abordan directamente. El kernel por sandbox de CubeSandbox es importante aquí porque el código es completamente arbitrario y cambia en cada ejecución.
Plataformas de agentes multi-inquilino. Si los agentes de muchos clientes ejecutan código en infraestructura compartida, el aislamiento a nivel de contenedor entre inquilinos es riesgoso. El aislamiento de hardware por sandbox le brinda un límite de inquilinos que se mantiene incluso si el agente de un inquilino es hostil. La densidad reportada (miles de sandboxes por host) es lo que lo hace viable en lugar de una VM por inquilino.
RL agente y bucles de entrenamiento. Entrenar agentes con aprendizaje por refuerzo significa ejecutar una enorme cantidad de lanzamientos no confiables de corta duración. Tencent cita que MiniMax usa CubeSandbox precisamente para esto en entornos heterogéneos. El arranque en frío rápido y la baja sobrecarga por instancia marcan la diferencia entre una ejecución de entrenamiento factible y una que no lo es.
Agentes de investigación y datos que usan herramientas. Un agente obtiene contenido externo, lo analiza y llama a APIs downstream. El contenido obtenido no es confiable (riesgo de inyección de prompt), por lo que el análisis y el código generado pertenecen a un sandbox, mientras que las APIs downstream deben probarse primero con simulaciones. Aquí es donde la combinación de aislamiento con pruebas de contratos de API rinde más.
Ejecución de complementos o extensiones no confiables. Si los usuarios pueden proporcionar herramientas o código que ejecuta su agente, usted está ejecutando código de terceros no confiable por definición. Un límite de microVM por ejecución es la postura adecuada, el mismo razonamiento que usaron las plataformas sin servidor al adoptar Firecracker.
Conclusión
El sandboxing de agentes dejó de ser opcional en el momento en que los agentes comenzaron a ejecutar código y a llamar a herramientas sin revisión humana. CubeSandbox es una respuesta concreta y abierta a la mitad del problema del aislamiento.
Puntos clave:
- CubeSandbox es real y específico: el sandbox de código abierto Apache 2.0 de Tencent Cloud para agentes de IA, construido sobre RustVMM y KVM, con kernels invitados por sandbox.
- El modelo de aislamiento es el punto clave: un kernel dedicado por sandbox es más fuerte que el aislamiento de contenedores para código arbitrario generado por modelos, con arranques en frío reportados por debajo de los 100 ms y menos de 5 MB de sobrecarga.
- La compatibilidad con E2B reduce el costo de cambio: si utiliza E2B, la ruta de sustitución documentada reformula la elección como gestionado versus autoalojado, no como una reescritura.
- Trate los números del proveedor como un punto de partida: las afirmaciones de rendimiento y densidad provienen en gran medida de Tencent; realice sus propias pruebas de referencia con su carga de trabajo y consulte el repositorio para ver qué características se han lanzado y cuáles están en desarrollo.
- El aislamiento es necesario pero no suficiente: un sandbox protege a su host del agente; no protege sus APIs de un agente confundido que las llama.
- Combine el aislamiento en tiempo de ejecución con las pruebas de contrato de API: simule y pruebe cada endpoint al que un agente pueda acceder para que una única respuesta incorrecta no genere una cascada.
Si sus agentes llaman a APIs de su propiedad o de las que dependen, configure la capa de contrato junto con la capa de aislamiento. Descargue Apidog para simular los servicios a los que acceden sus agentes en sandbox y pruébelos para el esquema, la autenticación y el comportamiento de errores antes de que un sistema autónomo los utilice en producción.