CubeSandbox pour Agents IA: Explication de l'Isolation

Si votre agent IA peut écrire du code, il peut écrire du mauvais code. S'il peut appeler des outils, il peut appeler le mauvais outil avec les mauvais arguments. La solution n'est pas une invite plus intelligente. C'est une frontière d'isolation entre la sortie du modèle et la machine qui l'exécute. CubeSandbox est l'un des systèmes conçus précisément pour cette frontière, et il est utile de comprendre ce qu'il fait, comment il se compare aux autres approches, et où il s'inscrit lorsque vos agents commencent à toucher de vraies API et de vraies données.

En bref

CubeSandbox est un service de bac à sable (sandbox) open-source, isolé matériellement, de Tencent Cloud, destiné à l'exécution de code d'agents IA. Chaque bac à sable dispose de son propre noyau de système d'exploitation invité via KVM, démarre en environ 60 ms et utilise moins de 5 Mo de surdébit mémoire. Il est sous licence Apache 2.0 et est compatible « drop-in » avec le SDK E2B.

Introduction

Les systèmes agentiques écrivent et exécutent désormais du code en production. Un agent de codage génère un script Python et l'exécute. Un agent de recherche gratte une page, l'analyse et transmet le résultat à une autre étape. Un agent de données charge un CSV et exécute des transformations décidées par le modèle à l'exécution. Aucun de ces codes n'a été révisé par un humain avant d'être exécuté. C'est le problème fondamental que résout le sandboxing d'agents : vous devez exécuter des instructions non fiables, générées par le modèle, sans leur donner accès à votre hôte, votre système de fichiers, vos identifiants ou votre réseau.

Ceci est d'autant plus important que les agents gagnent en autonomie. Un modèle qui se trompe sur une requête SQL est ennuyeux. Un modèle qui se trompe sur rm -rf ou qui suit une instruction injectée dans une page web scrappée est un incident de sécurité. Le sandboxing trace une ligne dure : l'agent peut faire ce qu'il veut dans un environnement isolé et jetable, et rien de ce qu'il fait ne s'échappe.

Il y a un deuxième problème, plus discret. Les agents ne se contentent pas d'exécuter du code ; ils appellent des API et des outils. Avant de faire confiance à un agent pour accéder à votre API de paiement ou à vos services internes depuis un bac à sable, vous devez savoir si ces API se comportent correctement et si l'agent les appelle comme vous l'attendez. C'est là que les outils d'API trouvent leur place aux côtés de l'isolation d'exécution. Une plateforme comme Apidog vous permet de simuler et de tester les points d'accès qu'un agent appellera, afin de valider le contrat avant qu'un système autonome ne commence à l'utiliser dans une exécution en bac à sable. Si vous réfléchissez déjà à l'architecture d'agent, notre guide sur l'architecture d'IA agentique explique comment ces couches d'exécution et d'outils s'articulent.

Le reste de cet article explique ce qu'est CubeSandbox, pourquoi les agents ont besoin d'un bac à sable, comment les modèles d'isolation diffèrent, et comment cela se connecte au test des API dont vos agents dépendent.

Qu'est-ce que CubeSandbox ?

CubeSandbox est un système de bac à sable de sécurité pour l'exécution de code d'agents IA, open-sourcé par Tencent Cloud sous la licence Apache 2.0 en avril 2026. Son slogan GitHub le décrit clairement : « Bac à sable instantané, concurrent, sécurisé et léger pour les agents IA. » Ce n'est pas seulement un SDK. C'est la pile complète de « sandbox-as-a-service », écrite principalement en Rust, que vous pouvez déployer vous-même.

L'architecture est construite sur RustVMM et KVM, la même couche de virtualisation du noyau Linux utilisée par de nombreux hyperviseurs cloud. Selon la documentation du projet et l'annonce officielle, le système est divisé en plusieurs composants :

• CubeAPI : une passerelle REST qui reproduit l'interface du bac à sable E2B.
• CubeMaster : l'orchestrateur de cluster qui planifie les bacs à sable sur les nœuds.
• CubeHypervisor et CubeShim : la couche de virtualisation KVM qui démarre et gère chaque microVM.
• Cubelet et CubeProxy : des agents au niveau des nœuds qui exécutent et acheminent vers les bacs à sable.
• CubeVS : une couche réseau basée sur eBPF qui applique l'isolation réseau inter-bacs à sable au niveau du noyau.

La caractéristique principale est que chaque bac à sable dispose de son propre noyau de système d'exploitation invité dédié. Il s'agit d'un modèle d'isolation différent et plus robuste qu'un conteneur, qui partage le noyau hôte. Les chiffres publiés par Tencent indiquent un démarrage à froid d'environ 60 ms en concurrence simple (moyenne de 67 ms avec un P95 autour de 90 ms pour 50 créations concurrentes), moins de 5 Mo de surdébit mémoire par instance, et la capacité d'exécuter des milliers de bacs à sable sur un seul hôte de grande taille. Les documents de presse citent un serveur à 96 vCPU prenant en charge plus de 2 000 bacs à sable concurrents. Tencent affirme que CubeSandbox a été exécuté à l'échelle au sein de sa propre infrastructure et que MiniMax l'a utilisé pour un entraînement à grande échelle par apprentissage par renforcement agentique dans des environnements hétérogènes.

Certaines fonctionnalités avancées, telles que la restauration instantanée au niveau des événements pour la création de points de contrôle et la restauration de l'état du bac à sable, sont décrites comme étant encore en développement. Considérez les éléments prospectifs comme une feuille de route, non comme des garanties livrées, et vérifiez le dépôt pour le statut actuel. La méthodologie de référence publique au-delà des chiffres du fournisseur est limitée, alors validez les affirmations de performance par rapport à votre propre charge de travail.

Pour les détails canoniques, la source de vérité est le dépôt GitHub de CubeSandbox et le site de documentation officiel.

Pourquoi les agents IA ont besoin d'un bac à sable

Il est utile d'être concret quant aux menaces, car le terme « sécurité » est trop vague pour servir de base à la conception. Il existe trois modes de défaillance qui poussent les équipes vers le sandboxing.

Code généré risqué. Un modèle produit du code qu'il croit correct. Parfois, il ne l'est pas. Il supprime le mauvais répertoire, épuise la mémoire dans une boucle serrée, ou écrit un fichier là où il ne devrait pas. Rien de tout cela n'est malveillant ; c'est juste erroné, et un code erroné avec un accès à l'hôte est dangereux. L'agent n'a aucune notion de rayon d'action destructeur, à moins que vous ne lui en donniez une.

Appels d'outils non fiables. Les agents appellent des outils et des API en fonction de ce que le modèle décide à l'exécution. Si le modèle est dirigé par une injection de prompt enfouie dans un document, une page web ou une réponse d'outil, il peut appeler un outil destructeur, passer des arguments contrôlés par un attaquant, ou enchaîner les appels d'une manière que vous n'aviez jamais prévue. Le modèle n'est pas un acteur de confiance ici ; c'est un interprète de tout texte qui atteint sa fenêtre contextuelle. Nous approfondissons ce sujet dans notre article sur les agents IA en tant que nouveaux consommateurs d'API, qui explique pourquoi les hypothèses de confiance traditionnelles des API sont rompues avec les appelants autonomes.

Exfiltration de données. C'est celle que les gens sous-estiment. Un agent ayant un accès réseau et un accès à des secrets peut être transformé en canal d'exfiltration. Une instruction empoisonnée demande à l'agent de lire une variable d'environnement contenant une clé API et de l'envoyer par POST à un point d'accès externe. Sans filtrage sortant et isolation des identifiants, la frontière du bac à sable n'a pas de sens car les données sortent par la porte d'entrée. C'est pourquoi CubeSandbox associe l'isolation au niveau du noyau à un filtrage sortant basé sur eBPF via CubeVS ; l'isolation du processus ne suffit pas si le réseau est grand ouvert.

Le fil conducteur commun : vous ne pouvez pas supposer que l'agent se comportera bien, car son comportement est en partie contrôlé par les données non fiables qu'il a ingérées. Un bac à sable vous permet d'arrêter de raisonner sur la fiabilité du modèle et de commencer à raisonner sur une limite qui tient, quoi qu'il arrive. Pour une vue pratique de l'exploration de ces comportements avant qu'ils n'atteignent la production, consultez comment tester les agents IA qui appellent des API.

Comment fonctionnent les bacs à sable d'agents : les modèles d'isolation

Tous les bacs à sable n'isolent pas de la même manière, et les différences sont importantes tant pour la sécurité que pour les performances. Il existe quatre grandes approches que vous rencontrerez dans l'écosystème des agents.

Isolation au niveau du processus. Exécutez le code en tant que processus de système d'exploitation restreint avec des filtres seccomp, des capacités abandonnées, des espaces de noms et des cgroups. C'est l'option la plus légère et la plus faible. Elle partage le noyau de l'hôte, donc un exploit du noyau signifie une compromission de l'hôte. Bien pour du code auquel vous faites majoritairement confiance ; insuffisant pour une sortie de modèle arbitraire.

Conteneurs. Les conteneurs de style Docker ajoutent des espaces de noms et des limites de ressources et sont familiers en termes d'exploitation. Mais les conteneurs partagent le noyau hôte par conception. Les vulnérabilités d'évasion de conteneur sont une classe de bugs réelle et récurrente, et « le code non fiable dans un conteneur à noyau partagé » est un point faible connu. De nombreuses équipes commencent ici parce que c'est facile, puis atteignent le plafond d'isolation.

MicroVMs. Une microVM démarre un noyau invité minimal à l'intérieur d'une virtualisation matérielle (KVM). Le code de l'agent s'exécute sur son propre noyau, donc un exploit au niveau du noyau est contenu dans une VM jetable, et non dans l'hôte. Firecracker a popularisé ce modèle pour les charges de travail sans serveur, et CubeSandbox se situe dans cette catégorie, utilisant RustVMM et KVM avec un noyau invité par bac à sable. Le compromis historique était le temps de démarrage ; les microVM étaient plus lentes à démarrer que les conteneurs. Les implémentations modernes s'attaquent à cela avec la prise d'instantanés et la pré-provisionnement des ressources, ce qui permet à CubeSandbox de signaler des démarrages en moins de 100 ms.

Noyaux d'application. gVisor emprunte un chemin différent : il intercepte les appels système dans l'espace utilisateur et implémente lui-même une interface de type Linux, de sorte que la charge de travail ne communique jamais directement avec le noyau hôte. C'est une couche d'isolation robuste sans VM complète, avec quelques compromis de compatibilité d'appels système et de performances.

Voici comment les approches se comparent selon les dimensions importantes pour les agents :

Il n'y a pas de solution unique gagnante. Le bon choix dépend de la confiance que vous accordez au code, de la rapidité des démarrages à froid dont vous avez besoin, de la possibilité d'exécuter KVM, et de la question de savoir si vous souhaitez opérer l'infrastructure vous-même ou la consommer en tant que service.

CubeSandbox dans le paysage

Le positionnement de CubeSandbox est spécifique : une isolation au niveau matériel avec des démarrages à froid suffisamment rapides pour ressembler à un conteneur, déployé comme quelque chose que vous exécutez plutôt qu'un service que vous louez. Cela le place en comparaison conceptuelle directe avec trois points de référence.

Face aux conteneurs. Un conteneur partage le noyau hôte ; CubeSandbox donne à chaque bac à sable le sien. Pour le code arbitraire généré par un agent, c'est l'argument de sécurité. Le coût est que vous avez besoin d'un hôte Linux x86_64 compatible KVM (un serveur bare-metal, une VM cloud qui prend en charge la virtualisation imbriquée, ou WSL 2 pour le travail local). Si votre plateforme ne peut pas exposer KVM, l'isolation basée sur les microVM n'est pas disponible pour vous et une approche en espace utilisateur comme gVisor ou une API hébergée peut mieux convenir.

Face à Firecracker. Firecracker est la microVM bien connue pour le sans serveur et est elle-même un bloc de construction, pas un produit de bac à sable d'agent. CubeSandbox est également basé sur KVM/RustVMM mais se situe plus haut dans la pile : un orchestrateur, une passerelle API compatible E2B et une isolation réseau eBPF, de sorte que vous déployez un service de bac à sable d'agent plutôt que d'en assembler un. Si vous voulez des primitives, Firecracker. Si vous voulez un service de bac à sable avec une API adaptée aux agents, CubeSandbox vise cela.

Face à E2B et aux bacs à sable hébergés. E2B fournit des bacs à sable isolés en tant que service géré ; vous appelez une API et l'infrastructure est le problème de quelqu'un d'autre. Le choix de conception notable de CubeSandbox est la compatibilité avec le SDK E2B. La documentation le décrit comme un remplacement direct : pointez E2B_API_URL vers votre instance Cube auto-hébergée et le code existant continue de fonctionner. Cela fait que la vraie décision est moins « quel bac à sable » et plus « service géré versus infrastructure auto-hébergée », avec la résidence des données, le coût à l'échelle et la propriété opérationnelle comme facteurs décisifs. Il prend également en charge nativement le SDK Python d'OpenAI selon l'annonce de Tencent.

Le résumé honnête : CubeSandbox est une entrée crédible dans l'espace des bacs à sable d'agents avec une thèse claire (isolation forte, démarrages rapides, auto-hébergé, compatible E2B). Il est également nouveau et largement documenté par son fournisseur, de sorte que les benchmarks indépendants sont rares. Prototypez-le par rapport à votre charge de travail et mesurez le démarrage à froid, la densité et le comportement d'isolation avant de vous engager.

Comment cela se connecte au test des API et des outils que vos agents appellent

L'isolation à l'exécution répond à la question « et si le code est mauvais ? ». Elle ne répond pas à « et si l'API appelée par l'agent est mauvaise, ou si l'agent l'appelle incorrectement ? ». Ce sont des problèmes différents, et vous devez couvrir les deux.

Imaginez un agent en bac à sable qui réserve des voyages. Le code s'exécute en toute sécurité à l'intérieur de CubeSandbox. Mais l'agent appelle toujours une API de vol, une API de paiement et un service d'itinéraire interne. Si l'une de ces API renvoie une réponse mal formée, l'agent peut boucler, halluciner une récupération ou transmettre des données incorrectes en aval. S'il appelle l'API de paiement avec la mauvaise clé d'idempotence, l'isolation ne vous sauvera pas ; l'argent continuera à être déplacé. Le bac à sable protège l'hôte de l'agent. Il ne protège pas vos systèmes d'un agent confus effectuant de vrais appels à de vrais services.

Ainsi, le flux de travail qui tient réellement la route comporte deux couches fonctionnant ensemble :

1. Isoler l'exécution afin que le code généré par le modèle et les invocations d'outils ne puissent pas nuire à l'hôte ou exfiltrer des données. C'est la couche CubeSandbox.
2. Valider le contrat de chaque API et outil que l'agent peut atteindre, avant et pendant les exécutions en bac à sable. C'est la couche d'outils API.

Pour la deuxième couche, simulez les dépendances afin que l'agent communique avec un substitut contrôlé pendant que vous testez le comportement, puis testez les points d'accès réels pour la conformité au schéma, la gestion des erreurs, l'authentification et les cas limites. Avec Apidog, vous pouvez construire un serveur de simulation qui renvoie des réponses déterministes et conformes au schéma, y diriger l'agent en bac à sable, et observer comment l'agent réagit aux chemins de succès et d'échec sans toucher à la production. Lorsque vous êtes prêt, exécutez les mêmes scénarios par rapport à l'API en direct pour confirmer que le contrat est respecté. Notre guide sur le test en bac à sable couvre la pratique générale des tests contre des environnements isolés et contrôlés, ce qui s'applique directement ici.

Cet appariement est important car les agents amplifient la dérive de contrat. Un humain remarque quand une réponse d'API semble anormale. Un agent, souvent, ne le fait pas ; il ingère la réponse et agit en conséquence. Des contrats d'API stricts, exercés avec des mocks et des tests, empêchent un appelant autonome de transformer une seule mauvaise réponse en une cascade. Si vos agents parlent le protocole de contexte de modèle, tester les serveurs MCP avec Apidog étend la même discipline à la couche d'outils. Et si vous concevez des API pour des consommateurs agents, concevoir des API pour les agents IA couvre les modèles de contrat qui rendent les appels autonomes prévisibles.

Cas d'utilisation concrets

Quelques modèles où l'approche « isolation plus contrat » démontre sa valeur :

• Agents de codage et interpréteurs de code. Un modèle écrit et exécute du code pour répondre à une question, transformer des données ou générer un graphique. C'est le cas d'utilisation canonique du bac à sable et celui que les API compatibles E2B ciblent directement. Le noyau par bac à sable de CubeSandbox est important ici car le code est entièrement arbitraire et change à chaque exécution.
• Plateformes d'agents multi-locataires. Si les agents de nombreux clients exécutent du code sur une infrastructure partagée, l'isolation au niveau du conteneur entre les locataires est risquée. L'isolation matérielle par bac à sable vous donne une frontière de locataire qui tient même si l'agent d'un locataire est hostile. La densité rapportée (des milliers de bacs à sable par hôte) est ce qui rend cela viable au lieu d'une VM par locataire.
• Apprentissage par renforcement agentique et boucles d'entraînement. Entraîner des agents avec l'apprentissage par renforcement signifie exécuter un nombre énorme de déploiements de courte durée et non fiables. Tencent cite MiniMax utilisant CubeSandbox exactement pour cela dans des environnements hétérogènes. Un démarrage à froid rapide et un faible surdébit par instance font la différence entre une exécution d'entraînement réalisable et une qui ne l'est pas.
• Agents de recherche et de données utilisant des outils. Un agent récupère du contenu externe, l'analyse et appelle des API en aval. Le contenu récupéré n'est pas fiable (risque d'injection de prompt), donc l'analyse et le code généré doivent être placés dans un bac à sable, tandis que les API en aval doivent d'abord être testées avec des mocks. C'est là que l'association de l'isolation avec les tests de contrat d'API est la plus rentable.
• Exécution de plugins ou d'extensions non fiables. Si les utilisateurs peuvent fournir des outils ou du code que votre agent exécute, vous exécutez par définition du code tiers non fiable. Une limite de microVM par exécution est la posture appropriée, le même raisonnement que celui utilisé par les plateformes sans serveur lors de l'adoption de Firecracker.

Conclusion

Le sandboxing d'agents a cessé d'être facultatif dès l'instant où les agents ont commencé à exécuter du code et à appeler des outils sans révision humaine. CubeSandbox est une réponse concrète et ouverte à la moitié du problème liée à l'isolation.

Points clés à retenir :

• CubeSandbox est réel et spécifique : le bac à sable open-source de Tencent Cloud sous licence Apache 2.0 pour les agents IA, construit sur RustVMM et KVM, avec des noyaux invités par bac à sable.
• Le modèle d'isolation est le point clé : un noyau dédié par bac à sable est plus robuste que l'isolation par conteneur pour le code arbitraire généré par le modèle, avec des démarrages à froid rapportés inférieurs à 100 ms et un surdébit de moins de 5 Mo.
• La compatibilité E2B réduit le coût de transition : si vous utilisez E2B, le chemin de remplacement « drop-in » documenté recadre le choix entre service géré et infrastructure auto-hébergée, et non comme une réécriture.
• Considérez les chiffres du fournisseur comme un point de départ : les affirmations de performance et de densité proviennent largement de Tencent ; effectuez des benchmarks par rapport à votre propre charge de travail et vérifiez le dépôt pour savoir quelles fonctionnalités ont été livrées par rapport à celles qui sont en développement.
• L'isolation est nécessaire mais pas suffisante : un bac à sable protège votre hôte de l'agent ; il ne protège pas vos API d'un agent confus qui les appelle.
• Associez l'isolation à l'exécution aux tests de contrat d'API : simulez et testez chaque point d'accès que l'agent peut atteindre afin qu'une seule mauvaise réponse ne provoque pas une cascade.

Si vos agents appellent des API que vous possédez ou dont vous dépendez, configurez la couche de contrat en parallèle de la couche d'isolation. Téléchargez Apidog pour simuler les services que vos agents en bac à sable sollicitent et les tester pour la conformité au schéma, l'authentification et le comportement en cas d'erreur avant qu'un système autonome ne les utilise en production.

bouton