Les agents IA deviennent plus utiles lorsqu’ils peuvent executer du code, installer des packages, naviguer sur le web et modifier des fichiers. Ces capacites transforment aussi chaque commande generee en frontiere de securite.
TencentCloud/CubeSandbox est un service Apache-2.0 concu pour cette frontiere. Il lance des microVM KVM avec kernel invite dedie, expose des API compatibles E2B et ajoute scheduling de cluster, isolation reseau, egress controle, snapshots, templates et console web.
Le projet cherche a combiner vitesse et densite des conteneurs avec une isolation materielle plus forte. Ses benchmarks bare-metal annoncent moins de 60ms au demarrage sans concurrence et moins de 5Mo d’overhead pour les specifications testees jusqu’a 32Go. Ce sont des mesures contextuelles, pas des garanties universelles.
Ce que fournit CubeSandbox
CubeSandbox est une plateforme auto-hebergee pour les agents qui ont besoin de compute jetable ou stateful. Elle propose :
- microVM KVM construites avec des composants RustVMM
- API REST concurrente avec compatibilite SDK E2B
- deploiements mono-noeud et multi-noeuds
- conversion d’images OCI en templates et Template Store
- console web pour noeuds, templates, sandboxes, logs et versions
- AutoPause et AutoResume
- snapshots, clonage et rollback CubeCoW
- isolation reseau par sandbox avec eBPF
- allowlists de domaines, injection de secrets et audit egress
- chemins x86_64 KVM et support ARM64 plus recent annonce par le projet
La compatibilite E2B facilite la migration, mais la roadmap mentionne encore des ecarts. Validez les methodes SDK et semantiques de cycle de vie utilisees avant de parler de remplacement universel.
Du plan de controle a l’execution
L’agent contacte CubeAPI, passerelle REST en Rust. CubeMaster conserve l’etat du cluster et affecte la requete. Sur le noeud, Cubelet gere le cycle du sandbox; CubeHypervisor et CubeShim relient les microVM KVM a l’interface containerd Shim v2.
CubeProxy route le trafic compatible E2B. CubeVS, switch virtuel eBPF, applique la politique reseau. CubeEgress, base sur OpenResty, ajoute filtrage L7, injection de credentials et audit.
Cette separation est importante : « executer ce code » implique admission, placement, boot, reseau, processus, observation et nettoyage, avec des modes d’echec differents.
Pourquoi l’isolation microVM compte
Les conteneurs partagent normalement le kernel hote. Namespaces, capabilities, seccomp et controles obligatoires peuvent creer une barriere forte, mais l’exposition kernel reste partagee. CubeSandbox donne a chaque sandbox son propre kernel invite dans une microVM KVM.
La virtualisation materielle ne constitue pas toute la securite. Provenance des templates, failles hyperviseur, configuration hote, authentification, secrets, reseau, logs, mises a jour et nettoyage restent essentiels. Il faut parler d’architecture d’isolation renforcee, pas d’execution « impossible a casser ».
Reseau et credentials
Le code agent doit souvent appeler des API externes. Placer des cles durables dans le sandbox les expose au code genere, a l’injection de prompt, aux logs et snapshots.
CubeEgress conserve les secrets dans un vault et les injecte au proxy sortant. Les allowlists limitent les destinations, CubeVS rend le contournement plus difficile et les logs enregistrent les acces. La version 0.5 ajoute tokens de trafic par sandbox et durcissement policy-routing.
Les operateurs doivent toujours proteger le vault, reduire les allowlists, faire tourner les cles, authentifier les API et tester les contournements DNS ou protocolaires.
Snapshots, clones et branches d’agents
CubeCoW produit des checkpoints copy-on-write. Un workflow sauvegarde un etat sain, experimente, revient apres echec ou clone plusieurs branches paralleles.
Cela correspond aux evaluations reproductibles, rollouts RL, solutions concurrentes, sessions navigateur et assistants durables. AutoPause/AutoResume suspend les sandboxes inactifs et les reveille a la prochaine requete.
Les snapshots peuvent contenir code, tokens, artefacts ou donnees personnelles. Retention, chiffrement, suppression, acces et audit doivent etre definis avant le passage a l’echelle.
Comprendre les performances annoncees
Le projet rapporte un cold start moyen sous 60ms sur bare metal sans concurrence et moins de 5Mo de memoire de base pour les tailles testees jusqu’a 32Go. A 50 creations concurrentes, il indique 67ms de moyenne, P95 90ms et P99 137ms.
Le contexte est decisif. Virtualisation cloud, KVM imbrique, stockage, templates, reseau, contention, taille invite et caches modifient les resultats. Reproduisez les tests sur l’infrastructure cible avec les memes operations et niveaux de concurrence que la production.
Deploiement et premiere utilisation
La documentation propose bare metal comme chemin recommande, PVM pour des VM cloud ordinaires, Terraform pour le cluster et une VM QEMU de developpement sans KVM. Le quick start insiste encore sur Linux avec KVM; verifiez les exigences propres a ARM64.
Apres installation, la console web est disponible ici :
http://<ip-du-noeud-controle>:12088
Verifiez la capacite, installez ou construisez un template READY, puis creez un sandbox et consultez ses logs. En production, ajoutez TLS, authentification, acces admin restreint, monitoring, sauvegarde du plan de controle et tests d’upgrade.
Ou CubeSandbox trouve sa place
CubeSandbox convient aux coding agents, browser automation, analyses de donnees, evaluations, environnements RL, assistants numeriques et systemes executant du code genere non fiable a forte concurrence.
Il est moins pertinent lorsqu’un conteneur durci suffit, que la virtualisation materielle manque ou qu’un service entierement gere est prefere. La complexite operationnelle doit etre comparee aussi serieusement que la vitesse.
La roadmap annonce Kubernetes natif, volumes persistants, reprise cross-node, compatibilite E2B approfondie, separation control/data plane, recovery et scheduling enrichi. Ce sont des directions futures tant qu’elles ne sont pas livrees et validees.
Conclusion
CubeSandbox assemble des primitives coherentes pour les agents : isolation microVM, templates rapides, scheduling, politique reseau, injection de secrets hors sandbox, snapshots et acces SDK familier.
Sa contribution principale est architecturale. L’execution sure d’un agent n’est pas seulement le lancement d’un conteneur; c’est un systeme de cycle de vie et de politiques. CubeSandbox rend ces couches visibles, tout en laissant aux operateurs la validation des performances et le durcissement selon leur menace.