Donner un shell à un agent transforme une erreur de raisonnement en action sur des fichiers, un réseau et des secrets. Les clouds proposent désormais des environnements isolés pour ce code, mais le mot « sandbox » recouvre au moins trois produits : un interpréteur géré, une session conteneur personnalisable et un poste Linux persistant pour agent.
Comparer seulement le nom de la technologie d’isolation produit de faux équivalents. La grille suivante s’appuie sur les documentations disponibles au 3 septembre 2026. Les préversions, quotas, régions et tarifs doivent être revérifiés avant tout choix.
Sommaire
Quatre offres, quatre centres de gravité
| Offre | Unité d’isolation et état | Runtime | Réseau et identité | Usage naturel |
|---|---|---|---|---|
| AWS AgentCore Code Interpreter | MicroVM dédiée par session ; fichiers disponibles pendant la session puis environnement supprimé | Python, JavaScript et TypeScript préinstallés ; commandes et fichiers | Modes Sandbox, réseau public ou VPC ; rôle IAM d’exécution | Calcul, transformation de données et code généré dans un outil géré |
| Azure Container Apps dynamic sessions | Sandbox Hyper-V par session, détruite après le délai d’inactivité | Interpréteur fourni ou image conteneur personnalisée | Sortie réseau bloquée par défaut et configurable ; endpoint protégé par Entra et RBAC | Pool préchauffé de tâches courtes, y compris runtimes spécialisés |
| Google Agent Platform Code Execution | Environnement géré isolé ; un même sandbox peut conserver l’état au cours d’une tâche | Code Execution avec runtimes gérés ; configuration du langage et du calcul selon l’API | IAM ; contrôles d’entreprise documentés, dont VPC Service Controls et CMEK | Exécution intégrée aux workflows Agent Platform et ADK |
| Cloudflare Sandbox SDK | Conteneur Linux isolé dans sa propre VM, identifié par un Durable Object ; état tant que l’environnement vit | Linux complet, commandes, fichiers, processus et services | Pile réseau séparée ; l’application Worker garde la responsabilité de l’autorisation et de l’exposition | Agents de code, IDE et traitements sur l’infrastructure Cloudflare |
AWS et l’interpréteur Azure conviennent lorsqu’une API d’exécution suffit. Les conteneurs personnalisés Azure et Cloudflare visent davantage un environnement que l’on façonne. Google relie son sandbox aux services d’Agent Platform. Aucun de ces choix ne dispense de concevoir la politique autour de l’agent.
AWS : un outil géré dans AgentCore
AgentCore Code Interpreter crée une microVM isolée par session avec CPU, mémoire et système de fichiers dédiés. La documentation indique un timeout de 15 minutes par défaut, configurable jusqu’à huit heures. L’état et les fichiers vivent durant la session ; la microVM est terminée et sa mémoire assainie à la fin.
Le point fort est le choix de connectivité. Le mode Sandbox limite les sorties et conserve notamment un accès S3 ; le mode Public ouvre Internet ; le mode VPC rejoint des ressources privées. Un rôle IAM définit les ressources AWS accessibles. Cette souplesse est aussi un risque : choisir Public et un rôle large annule une bonne partie de l’intérêt du cloisonnement.
Azure : des sessions préchauffées et éphémères
Azure Container Apps dynamic sessions maintient un pool d’environnements prêts à être alloués. Chaque session est isolée par Hyper-V. On peut choisir l’interpréteur géré ou fournir une image conteneur avec ses propres dépendances et son propre protocole.
Les sorties réseau sont désactivées par défaut et peuvent être configurées au niveau du pool. L’accès à l’API requiert un jeton Entra et le rôle d’exécution du pool. Quand le délai de refroidissement expire, la session est détruite avec son état. Cette sémantique est adaptée aux calculs courts ; une application qui veut reprendre longtemps doit externaliser ses artefacts.
Google : le sandbox comme service d’Agent Platform
Agent Platform sépare le runtime de l’agent, les sessions, la mémoire et Code Execution. L’outil ADK de Code Execution maintient un sandbox unique pendant la tâche : les fichiers et résultats d’une opération sont donc visibles par les suivantes. Des environnements gérés plus larges permettent également de réutiliser un identifiant de sandbox, d’injecter des sources et de définir des règles réseau.
La gamme évolue vite et plusieurs fonctions sont en préversion. Il faut vérifier l’API exacte — Gemini managed agents ou Google Cloud Agent Platform — au lieu de transférer les limites de l’une vers l’autre. Côté entreprise, Google documente VPC Service Controls, le chiffrement par clé client et la résidence des données pour Code Execution.
Cloudflare : un environnement Linux piloté depuis Workers
Le Sandbox SDK combine un Worker, un Durable Object et un conteneur Linux. La documentation précise que chaque sandbox s’exécute dans sa propre VM, avec systèmes de fichiers, processus, réseau et quotas séparés. L’API sait exécuter des commandes, manipuler des fichiers, conserver des processus en arrière-plan et exposer des services.
Cette liberté rapproche le produit d’un poste de travail d’agent. Elle agrandit aussi la surface à gouverner : validation des commandes, identité du demandeur, séparation d’un sandbox par utilisateur ou tâche, politique de sortie et protection des URL de prévisualisation. En septembre 2026, la documentation distingue le paquet stable actuel d’une version 1.0 encore en préversion ; le choix de version doit être explicite.
La grille d’achat qui révèle les écarts
- Menace : code accidentel, code utilisateur hostile ou agent compromis ?
- Isolation : quelle frontière sépare deux locataires, et qui administre l’hôte ?
- État : que reste-t-il après une requête, un arrêt, une reprise et une suppression ?
- Réseau : la sortie est-elle refusée par défaut, filtrable par destination et observable ?
- Identité : le sandbox reçoit-il un jeton court et limité à la tâche ?
- Secrets : peuvent-ils être injectés sans apparaître dans le prompt, les logs ou le système de fichiers durable ?
- Contrôle : peut-on interrompre une tâche, borner CPU, mémoire, disque, durée et dépense ?
- Preuves : obtient-on l’auteur, le code exécuté, les appels réseau, les fichiers produits et la décision de politique ?
- Disponibilité : la fonction est-elle stable, accessible dans la région et couverte par le support attendu ?
Un test commun avant de choisir
Exécutons le même scénario sur chaque candidat : charger un dépôt et un fichier de données, installer une dépendance autorisée, lancer un test, produire un artefact, tenter trois sorties réseau interdites, dépasser une limite de ressources, interrompre la tâche puis vérifier la suppression. Mesurons le temps de démarrage, le taux d’échec, la fidélité des traces, le coût complet du pool inactif et actif, ainsi que l’effort de reprise.
Les prix statiques vieillissent trop vite pour départager ces offres dans un article. Le modèle de coût doit toutefois faire partie du test : durée facturée minimale, capacité préchauffée, stockage, trafic sortant, journaux et services d’identité. La meilleure sandbox est celle qui satisfait le modèle de menace avec un coût et une charge d’exploitation mesurés, pas celle dont la fiche produit promet l’isolation la plus spectaculaire.
Sources
- AWS — AgentCore Code Interpreter
- AWS — ressources et modes réseau de Code Interpreter
- Microsoft — Azure Container Apps dynamic sessions
- Microsoft — cycle de vie, réseau et sécurité des sessions
- Google ADK — Agent Runtime Code Execution
- Google Cloud — Agent Platform et Code Execution
- Google — environnements des managed agents
- Cloudflare — Sandbox SDK
- Cloudflare — modèle de sécurité du Sandbox SDK
