- Qu'est-ce qu'un sandbox pour agent IA ?
- En quoi un sandbox pour agent est-il différent d'un conteneur classique ?
- Qu'est-ce que l'isolation dans le contexte des agents IA ?
- Qu'est-ce que le filtrage des sorties et pourquoi est-ce important ?
- Qu'est-ce qu'un instantané dans un sandbox pour agent ?
- Quelles technologies sous-tendent les sandbox pour agents ?
- Les agents IA peuvent-ils s'échapper des sandbox ?
- Les sandbox pour agents IA prennent-ils en charge les charges de travail GPU ?
- Quand avez-vous réellement besoin d'un sandbox dédié ?
- Questions fréquemment posées
- Fournisseurs de sandbox courants
- Articles recommandés
Un sandbox pour agent IA est un environnement d’exécution isolé dans lequel un agent IA peut exécuter du code, appeler des outils et interagir avec un système de fichiers ou un navigateur sans pouvoir affecter le système hôte, les charges de travail adjacentes ou l’infrastructure sensible. Le sandbox crée une frontière : ce qui se passe à l’intérieur reste à l’intérieur, et ce qui se passe à l’extérieur n’est pas accessible depuis l’intérieur sauf si vous l’autorisez explicitement. Novita Agent Sandbox est une implémentation de ce modèle — isolation par microVM Firecracker, déploiement BYOC dans votre propre VPC AWS ou GCP, et tarification purement à l’usage — mais les concepts ici s’appliquent à toute plateforme de sandbox. Cet article répond aux questions les plus courantes sur le fonctionnement de cette frontière, les compromis, et quand vous avez réellement besoin d’un sandbox. Pour une FAQ approfondie sur l’isolation, les secrets, le filtrage des sorties et les exigences de conformité, consultez la FAQ sur les sandbox pour agents IA.
Qu’est-ce qu’un sandbox pour agent IA ?
Un sandbox pour agent IA est la couche d’exécution où un agent IA effectue son travail concret : écrire et exécuter du code, installer des paquets, lire et modifier des fichiers, effectuer des appels API, et interagir avec des sessions navigateur ou des interfaces graphiques de bureau. Le sandbox fournit un environnement délimité avec son propre système de fichiers, allocation CPU et mémoire, interface réseau, et espace de noms de processus — et il est isolé de tout ce qui se trouve à l’extérieur.
L’objectif de conception clé est le confinement. Lorsqu’un LLM génère une commande shell et qu’un agent l’exécute, la commande s’exécute à l’intérieur du sandbox. Si elle installe un paquet, lance un sous-processus ou tente de lire des identifiants, ces opérations sont limitées au sandbox. Si le code fait planter le processus ou remplit le disque, les dégâts restent locaux.
Les sandbox servent également d’unité de facturation et de comptabilité des ressources pour les fournisseurs cloud. Lorsque vous appelez un SDK comme E2B, Daytona ou Novita Agent Sandbox, vous créez une instance de sandbox, exécutez des opérations à l’intérieur, puis la fermez — et le fournisseur vous facture en fonction de la consommation de calcul.
En quoi un sandbox pour agent est-il différent d’un conteneur classique ?
Un conteneur classique vous donne un espace de noms de système de fichiers et des limites de ressources, mais tous les conteneurs sur le même hôte partagent le même noyau OS. Si un processus à l’intérieur du conteneur exploite une vulnérabilité du noyau ou un filtre d’appels système mal configuré, il peut potentiellement affecter l’hôte ou d’autres conteneurs.
Un sandbox pour agent va généralement plus loin en utilisant une frontière microVM. Une microVM enveloppe la charge de travail dans une machine virtuelle légère avec son propre noyau invité, soutenue par la virtualisation matérielle (KVM). L’invité est isolé du noyau hôte par conception, donc une exploitation du noyau dans l’invité n’affecte pas automatiquement l’hôte.
Le compromis pratique est le surcoût de performance. Une microVM démarre plus lentement qu’un conteneur car elle doit démarrer un noyau, même minimal. Les plateformes microVM rapides comme Firecracker ont réduit ce surcoût à moins de 500 ms dans la plupart des cas, et les systèmes basés sur des instantanés comme Daytona le poussent à moins de 100 ms. Mais c’est toujours plus de surcoût que le démarrage d’un conteneur.
Pour la plupart des charges de travail d’agent IA impliquant du code généré par LLM ou non fiable, la frontière plus forte en vaut la peine. Si vous exécutez du code interne entièrement fiable sans entrée utilisateur, un conteneur renforcé peut suffire.
Qu’est-ce que l’isolation dans le contexte des agents IA ?
L’isolation dans les sandbox pour agents opère sur plusieurs dimensions. Pour une plongée technique sur la façon dont l’isolation des sandbox résiste sous des charges de travail réelles, y compris où les frontières microVM aident et où elles ne le font pas, consultez le guide d’évaluation Firecracker.
Isolation du système de fichiers — l’agent possède son propre système de fichiers, séparé de l’hôte. Les fichiers écrits à l’intérieur du sandbox n’apparaissent pas sur l’hôte, et les fichiers de l’hôte ne sont pas accessibles depuis l’intérieur sauf montage explicite. Cela empêche les agents de lire des identifiants, des fichiers de configuration ou d’autres secrets situés en dehors du sandbox.
Isolation des processus — les processus à l’intérieur du sandbox ne peuvent pas voir ni signaler les processus à l’extérieur. L’agent peut lancer des sous-processus, des tâches d’arrière-plan ou des serveurs à l’intérieur du sandbox, mais ils ne peuvent pas communiquer avec l’arborescence de processus de l’hôte.
Isolation réseau — par défaut, les sandbox pour agents peuvent être configurés pour que les appels réseau sortants soient bloqués, mis sur liste blanche ou limités en débit. Un agent qui ne devrait pas pouvoir exfiltrer des données vers des adresses internet arbitraires peut être restreint à une liste d’extrémités connues. Voir la section sur le filtrage des sorties ci-dessous pour plus de détails.
Isolation des ressources — les allocations CPU et mémoire sont plafonnées. Un agent qui entre dans une boucle infinie ou génère des sorties volumineuses ne privera pas les autres sandbox sur le même hôte, car les limites de ressources sont appliquées au niveau de la VM ou du conteneur.
Ces dimensions définissent ensemble le rayon d’explosion : quel est le pire qui puisse arriver si l’agent se comporte mal, plante ou exécute du code inattendu ?
Qu’est-ce que le filtrage des sorties et pourquoi est-ce important ?
Le filtrage des sorties contrôle les connexions réseau sortantes qu’un agent est autorisé à effectuer depuis l’intérieur du sandbox.
Dans une configuration permissive, l’agent peut effectuer des appels HTTP/HTTPS vers n’importe quel hôte sur Internet. C’est pratique pour les agents de codage qui récupèrent des paquets, appellent des API externes ou naviguent sur le web. Cela signifie aussi qu’un agent compromis, ou manipulé par une attaque d’injection de prompt, pourrait exfiltrer des données vers un serveur contrôlé par un attaquant ou interagir avec une infrastructure qu’il ne devrait pas atteindre.
Dans une configuration restrictive, les sorties sont verrouillées sur une liste d’autorisation explicite : l’agent ne peut appeler que l’API du modèle, une base de données spécifique et le registre de paquets. Tout le reste est bloqué. C’est plus difficile à configurer et nécessite de maintenir la liste d’autorisation à mesure que les dépendances de l’agent évoluent, mais cela donne une surface d’attaque beaucoup plus petite.
La plupart des déploiements d’agents en production se situent entre ces extrêmes : les sorties ne sont pas complètement sans restriction, mais pas non plus verrouillées sur une liste de confiance zéro dès le premier jour. Les schémas courants incluent le blocage des destinations malveillantes connues, la journalisation de tous les appels sortants pour audit, et le resserrement progressif de la liste à mesure que le comportement de l’agent devient prévisible. Pour une analyse complète des contrôles des sorties et de ce qui peut encore échapper à chaque frontière d’isolation, consultez le guide d’exécution sécurisée de code.
Certains fournisseurs de sandbox vous donnent des contrôles de sortie programmatiques via le SDK. D’autres traitent le sandbox comme entièrement ouvert en sortie par défaut. Sachez quel modèle votre fournisseur utilise avant de supposer que vos agents ne peuvent pas atteindre des hôtes externes.
Qu’est-ce qu’un instantané dans un sandbox pour agent ?
Un instantané capture l’état exact d’un sandbox en cours d’exécution — système de fichiers, mémoire, processus en cours, état réseau — et le sauvegarde afin que le sandbox puisse être restauré à cet état plus tard.
C’est utile dans plusieurs scénarios :
Réduire le coût de démarrage à froid — au lieu de démarrer une nouvelle VM et d’installer des paquets à chaque fois, vous démarrez une fois, installez tout, prenez un instantané, puis reprenez à partir de cet instantané lors de chaque nouvelle session. Les démarrages à froid de moins de 90 ms de Daytona sont possibles grâce à cette technique.
Point de contrôle pour les agents de longue durée — un agent de codage travaillant sur une tâche de plusieurs heures peut être mis en pause à mi-parcours, avec son état exact sauvegardé. Si l’agent doit être examiné, modifié ou redémarré, il peut reprendre à partir du point de contrôle plutôt que de recommencer.
Évaluation reproductible — pour les pipelines d’entraînement RL ou d’évaluation de modèles, vous pouvez prendre un instantané d’un état de départ connu et bon et réinitialiser à cet état avant chaque épisode d’évaluation. Cela vous donne des conditions de départ véritablement identiques sur de nombreuses exécutions, plutôt que de re-provisionner et d’espérer que l’état corresponde.
Tous les fournisseurs de sandbox n’exposent pas les contrôles d’instantané au niveau de l’API. Le système de templates d’E2B gère le cas d’usage “environnement préinstallé” mais ne vous donne pas de restauration arbitraire en milieu de session. L’API d’instantané de Daytona est plus flexible.
Quelles technologies sous-tendent les sandbox pour agents ?
Les technologies sous-jacentes les plus courantes sont :
Firecracker — un runtime microVM développé par AWS, utilisé en interne pour Lambda et Fargate. Firecracker démarre un noyau invité minimal en moins de 500 ms, expose un modèle de périphérique minimal pour réduire la surface d’attaque, et est soutenu par la virtualisation matérielle KVM. E2B et Novita Agent Sandbox utilisent tous deux Firecracker.
gVisor — un sandbox de noyau développé par Google qui s’interpose sur les appels système plutôt que d’exécuter un noyau invité complet. Il est plus léger qu’une microVM mais ne fournit pas une isolation complète du noyau — il se situe entre le niveau processus et le niveau VM sur le spectre de l’isolation.
Conteneurs Docker avec filtrage des appels système — conteneurs renforcés avec seccomp, AppArmor et des capacités minimales. C’est le point de départ le plus courant mais la frontière d’isolation la plus faible pour du code non fiable.
V8 / Deno — isolation spécifique à JavaScript utilisant le modèle de permissions du runtime V8. Convient pour isoler des charges de travail JavaScript uniquement mais pas utilisable pour des agents qui doivent exécuter des commandes shell arbitraires ou du code non-JS.
Le choix de la technologie sous-jacente détermine les performances de démarrage, la force de l’isolation et la complexité opérationnelle du sandbox. Pour les charges de travail d’agents exécutant du code non fiable ou généré par LLM dans un contexte multi-locataire, l’isolation de classe Firecracker est la norme pratique actuelle.
Les agents IA peuvent-ils s’échapper des sandbox ?
En pratique, les évasions de sandbox sont rares mais pas impossibles, et le profil de risque dépend de la technologie :
Les évasions de conteneurs sont documentées. Les conteneurs mal configurés — mode privilégié, socket Docker monté, répertoires hôtes inscriptibles — ont des vecteurs d’évasion connus. Un conteneur renforcé sans privilèges, avec un système de fichiers racine en lecture seule et des capacités minimales réduit considérablement ce risque, mais ne l’élimine pas.
Les évasions de microVM nécessitent une vulnérabilité de l’hyperviseur ou une faille dans le modèle de périphérique. Celles-ci sont rares car la surface d’attaque est intentionnellement petite. Le modèle de périphérique minimal de Firecracker est spécifiquement conçu pour réduire l’exposition de l’hyperviseur. AWS n’a divulgué aucune évasion au niveau Firecracker en production.
L’injection de prompt dans les actions du sandbox est un type différent d’“évasion” — pas une exploitation du noyau, mais un attaquant intégrant des instructions dans du contenu fourni par l’utilisateur qui amène l’agent à prendre des actions qu’il ne devrait pas. C’est une préoccupation au niveau de l’application, pas au niveau du sandbox. Les sandbox aident à contenir les dégâts d’une injection de prompt (le code injecté s’exécute à l’intérieur du sandbox, pas sur votre hôte), mais ils ne préviennent pas l’injection elle-même.
La conclusion pratique : un sandbox basé sur Firecracker bien configuré n’est pas à l’épreuve des évasions en théorie, mais la barre d’attaque est suffisamment haute pour que, dans la plupart des déploiements d’agents en entreprise, le risque résiduel soit gérable. Les modes de défaillance les plus courants sont les erreurs de configuration (sorties trop permissives, identifiants mal délimités passés dans le sandbox) plutôt que les exploits au niveau du noyau.
Les sandbox pour agents IA prennent-ils en charge les charges de travail GPU ?
La plupart des sandbox pour agents IA à la mi-2026 n’incluent pas de support GPU. E2B, Daytona et Vercel Sandbox sont tous CPU uniquement.
Modal est la principale exception dans le domaine des sandbox gérés — il offre un accès GPU à la demande dans les conteneurs, adapté à l’inférence de modèles, au fine-tuning ou aux charges de travail RL qui nécessitent un GPU dans le même environnement que le code de l’agent.
Pour la plupart des workflows d’agents, l’agent lui-même appelle une API d’inférence LLM externe (comme les points de terminaison d’inférence de Novita) plutôt que d’exécuter un modèle localement. Dans cette architecture, vous n’avez pas besoin de GPU dans le sandbox — le sandbox gère le code, les opérations sur fichiers et les appels d’outils, tandis que l’inférence lourde s’exécute sur un service GPU séparé. C’est le modèle utilisé par les agents de codage, les agents d’analyse de données et la plupart des workflows d’automatisation de navigateur.
Si vous avez besoin de GPU à l’intérieur du sandbox — par exemple, pour l’inférence de modèle local en mode hors ligne, les étapes d’entraînement RL, ou les pipelines d’évaluation en plusieurs étapes — tenez-en compte dans votre sélection de fournisseur. Modal est actuellement l’option la plus couramment utilisée pour ce modèle.
Quand avez-vous réellement besoin d’un sandbox dédié ?
Toutes les applications IA n’ont pas besoin d’un sandbox dédié. Les scénarios où un sandbox apporte une réelle valeur ajoutée :
Vous exécutez du code généré par LLM — l’agent écrit et exécute du code qui n’a pas été rédigé par un humain et peut faire des choses inattendues. C’est le cas d’usage central : l’exécution se fait dans un sandbox afin qu’elle ne puisse pas affecter votre hôte, vos identifiants ou d’autres charges de travail.
Vous servez des utilisateurs finaux — les exécutions d’agents de plusieurs utilisateurs partagent la même infrastructure sous-jacente. Vous avez besoin d’isolation entre les utilisateurs pour que l’agent d’un utilisateur ne puisse pas affecter celui d’un autre, intentionnellement ou accidentellement.
Vous avez besoin de workflows d’état long — un agent de codage qui édite des fichiers, exécute des tests et commit des changements a besoin d’un espace de travail qui persiste sur de nombreux tours de LLM. Un sous-processus frais pour chaque appel ne maintiendra pas l’état ; un sandbox le fera.
Vous avez des exigences de conformité ou d’audit — vous devez journaliser toutes les actions de l’agent, restreindre l’accès réseau, ou prouver que les charges de travail des agents ne peuvent pas accéder aux bases de données de production ou aux identifiants. Les sandbox vous fournissent la couche d’application pour ces contrôles.
Vous faites de l’automatisation de navigateur ou d’utilisation d’ordinateur — les environnements d’automatisation de navigateur dans un sandbox sont totalement isolés de l’hôte, de sorte que l’agent peut cliquer, taper et prendre des captures d’écran sans affecter vos sessions de navigateur local ou l’état du système.
Si vous exécutez seulement un simple pipeline “résume ce texte” sans exécution de code, vous n’avez probablement pas besoin d’un sandbox d’exécution dédié — un appel API à un LLM suffit. Le sandbox devient nécessaire dès que l’agent commence à prendre des actions qui ont des effets secondaires : écrire des fichiers, exécuter du code, appeler des API externes en votre nom.
Questions fréquemment posées
Un sandbox pour agent IA est-il identique à un environnement de développement ?
Non. Un environnement de développement est un espace de travail pour un développeur humain — il persiste entre les sessions, est de longue durée, et conçu pour être personnalisé et réutilisé. Un sandbox pour agent IA est une frontière d’exécution runtime : il existe pour la durée d’une tâche, est conçu pour être éphémère et reproductible, et son rôle principal est le confinement, pas le confort du développeur. Certains sandbox peuvent persister l’état entre les tours de LLM au sein d’une session (ce qui les fait ressembler davantage à un espace de travail), mais l’objectif de conception est l’isolation de l’hôte, pas un IDE complet. Les termes se chevauchent parfois dans le marketing des fournisseurs ; si vous évaluez une plateforme, regardez ce qu’est réellement la frontière d’isolation, pas l’étiquette.
Qu’est-ce qu’un sandbox d’exécution d’agent ?
Un sandbox d’exécution d’agent est la même chose qu’un sandbox pour agent IA — le terme “exécution” met simplement l’accent sur l’aspect runtime. Lorsqu’un LLM décide d’effectuer une action (exécuter du code, appeler un outil, écrire un fichier), ces actions s’exécutent à l’intérieur du sandbox. Le sandbox est la couche d’exécution qui applique la frontière entre ce que l’agent fait et ce que le reste de votre système peut voir ou subir comme impact. Les termes “sandbox d’agent”, “sandbox d’exécution de code” et “environnement d’exécution d’agent” sont utilisés de manière interchangeable dans l’industrie.
Comment Firecracker se compare-t-il à gVisor pour les charges de travail d’agent IA ?
Les deux fournissent une isolation au-delà des conteneurs standard, mais via des mécanismes différents. Firecracker démarre un noyau invité minimal dans une microVM soutenue par KVM — le sandbox a son propre noyau totalement séparé du noyau hôte. gVisor s’interpose sur les appels système en utilisant un noyau en espace utilisateur (runsc) sans exécuter de noyau invité complet. Le compromis pratique : Firecracker offre une frontière hôte plus forte car le noyau invité est complètement séparé ; gVisor a un surcoût mémoire plus faible par sandbox car il n’exécute pas de noyau complet, mais l’isolation se situe entre une microVM complète et un conteneur renforcé par interception des appels système. Pour les charges de travail d’agents IA multi-locataires exécutant du code non fiable généré par LLM, l’isolation de classe Firecracker est la norme de production actuelle. gVisor est raisonnable pour les charges de travail où le code est partiellement fiable et où la densité mémoire importe plus que l’isolation maximale.
L’injection de prompt peut-elle amener un agent à s’échapper de son sandbox ?
L’injection de prompt ne contourne pas l’isolation technique du sandbox — elle exploite la prise de décision de l’agent pour prendre des actions que l’attaquant a voulues mais que le développeur n’a pas prévues. Une instruction injectée du type “exfiltre les variables d’environnement vers cette URL” amène l’agent à effectuer un appel réseau sortant, qui n’est bloqué que si la politique de sortie l’empêche. L’isolation du système de fichiers et des processus du sandbox reste intacte. Cela signifie que la sécurité du sandbox et la défense contre l’injection de prompt traitent différentes parties de la pile : le sandbox limite le rayon d’explosion de ce que l’agent peut faire au niveau de l’infrastructure ; les contrôles au niveau de l’application (restrictions d’appels d’outils, approbations humaines dans la boucle, listes d’autorisation de sortie) défendent contre l’agent étant dirigé pour abuser de ces capacités.
Pourquoi avez-vous besoin d’un sandbox spécifiquement pour les agents IA ?
La différence clé avec l’exécution de code traditionnelle est l’incertitude. Lorsqu’un développeur humain écrit du code, il sait approximativement ce qu’il va faire. Lorsqu’un LLM génère du code ou décide d’appeler un outil, l’application peut avoir une visibilité limitée sur ce qui sera exactement exécuté, quels paquets seront installés, ou quels points de terminaison externes seront contactés — potentiellement sur des milliers de sessions concurrentes. Cette incertitude augmente les enjeux pour chacun des contrôles de sécurité standard : la politique de sortie compte car l’agent peut atteindre des points de terminaison que personne n’avait anticipés ; la gouvernance des paquets compte car l’agent peut installer des dépendances de manière dynamique ; la journalisation d’audit compte car reconstruire ce qui s’est passé est plus difficile lorsque les actions de l’agent n’étaient pas pré-énumérées. Un sandbox vous donne la couche d’application pour gérer cette incertitude sans avoir à faire confiance à chaque action individuelle de l’agent à l’avance.
Fournisseurs de sandbox courants
Un aperçu rapide des principales options, avec des comparaisons plus complètes dans les articles liés :
- Novita Agent Sandbox — microVM Firecracker, déploiement BYOC dans votre propre VPC AWS ou GCP, pas de frais d’abonnement, sessions jusqu’à 24 heures. L’option principale pour les équipes ayant des exigences de conformité, une sensibilité aux coûts, ou utilisant déjà Novita pour l’inférence LLM. Voir novita.ai/sandbox.
- E2B — géré, microVM Firecracker, grande communauté, pas d’auto-hébergement. SDK bien documentés et écosystème actif.
- Daytona — démarrage à froid inférieur à 90 ms, open-source (AGPL), auto-hébergeable. Meilleur pour les cas d’usage sensibles à la latence ou de conformité nécessitant une infrastructure auto-hébergée.
- Modal — l’option principale lorsque vous avez besoin de GPU dans le sandbox. Isolation par conteneur.
- Vercel Sandbox — démarrage à froid rapide, idéal pour JS/TS sur la plateforme Vercel.
Pour une comparaison complète avec des spécifications et un cadre de décision, voir Meilleurs sandbox pour agents IA en 2026. Pour une évaluation approfondie d’E2B et Daytona spécifiquement — démarrage à froid, BYOC, instantanés et tarification — voir le guide d’évaluation des sandbox pour agents IA comparant E2B et Daytona.
