3 min de lecture

CubeSandbox de Tencent : une sandbox IA compatible E2B

CubeSandboxE2BAI sandboxing

Tencent a publié CubeSandbox en open source, un environnement d'exécution de code d'agents IA fondé sur RustVMM et KVM. Il se présente comme un remplaçant compatible avec E2B SDK, sans réécriture de la logique métier, avec isolation matérielle, démarrage à froid sous 60 ms et moins de 5 Mo de surcoût mémoire.

Ce que Tencent a réellement publié

Le point marquant n'est pas une sandbox de plus, mais la tentative de faire de l'API E2B une véritable couche de portabilité. Dans l'annonce open source de CubeSandbox, Tencent AI présente le projet comme un environnement d'exécution sécurisé pour le code d'agents IA, avec une isolation matérielle reposant sur RustVMM et KVM. On dépasse ainsi la frontière classique d'un conteneur : le code non fiable est séparé par virtualisation.

Le détail le plus concret est la compatibilité annoncée avec E2B SDK. Selon Tencent, une application E2B existante peut basculer vers CubeSandbox en modifiant une seule variable d'environnement, sans changer sa logique métier. Le projet propose un SDK Python, un SDK TypeScript, une API REST et une CLI.

Lors de l'annonce, Tencent a également revendiqué un démarrage à froid inférieur à 60 ms et un surcoût mémoire inférieur à 5 Mo. Ces chiffres sont séduisants, surtout pour les boucles d'agents qui créent et détruisent fréquemment des sandboxes. Ils proviennent toutefois de l'éditeur et ne constituent pas une comparaison indépendante avec les alternatives.

OpenSandbox est un autre projet qui revendique la compatibilité E2B. Son objectif est différent : auto-hébergement, Docker et exécution dans un réseau privé lorsque le code ou les données ne doivent pas sortir de l'organisation. Les documents publics d'OpenSandbox ne donnent pas de métriques de démarrage à froid comparables ; une comparaison honnête de vitesse reste donc impossible.

Pourquoi la compatibilité compte davantage qu'un benchmark flatteur

Le changement essentiel n'est pas le chiffre de 60 ms, mais la réduction de la dépendance d'une application d'agents envers un seul moteur d'exécution. Si E2B SDK devient une couche commune, l'équipe peut choisir un moteur de sandbox selon son modèle d'isolation, son lieu de déploiement et ses contraintes opérationnelles, sans réécrire toute la chaîne d'exécution.

Pour les données sensibles, OpenSandbox est un candidat naturel grâce à son modèle auto-hébergé. CubeSandbox est plus intéressant lorsque l'isolation matérielle et le lancement rapide priment sur la simplicité d'une pile de conteneurs. Les développeurs d'agents y gagnent, tandis que les plateformes devront rivaliser sur la fiabilité réelle du runtime plutôt que sur la forme de leur API.

Avant de retenir un démarrage à froid de démonstration, je vérifierais le comportement sous charge parallèle, le nettoyage de l'état entre les sessions et l'exhaustivité de la compatibilité E2B pour les erreurs et délais d'attente. C'est généralement là qu'un remplacement direct rencontre la réalité de l'ingénierie. Si la compatibilité résiste à ces cas limites, le marché disposera enfin d'une interface portable au lieu d'une nouvelle île fermée.

Nous avons précédemment couvert Pydantic Monty, un interpréteur Python sécurisé pour exécuter du code généré par des LLM sans conteneurs. Son approche apporte un contexte utile pour évaluer le modèle de sandboxing de l'infrastructure OpenSandbox de Tencent.