- Qu'est-ce qu'un sandbox d'agent IA ?
- En quoi un sandbox d'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 du trafic sortant et pourquoi est-ce important ?
- Comment les secrets et les identifiants sont-ils délimités dans un sandbox d'agent ? {#secrets-and-credentials}
- Comment fonctionnent les journaux d'audit dans les sandbox d'agent IA ? {#audit-logs}
- Qu'est-ce que la création d'instantanés dans un sandbox d'agent ?
- Quelles technologies alimentent les sandbox d'agent ?
- Les agents IA peuvent-ils s'échapper des sandbox ?
- Les sandbox d'agent IA prennent-ils en charge les charges de travail GPU ?
- Quand avez-vous réellement besoin d'un sandbox dédié ?
- Quelle est la différence entre un interpréteur de code et un runtime d'agent ? {#code-interpreter-vs-agent-runtime}
- Comment exécuter du code généré par IA en toute sécurité ? {#run-ai-generated-code-safely}
- Questions fréquentes
- Fournisseurs de sandbox courants
- Articles recommandés
Un sandbox d’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 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 à faire et quand vous en avez réellement besoin. Pour des questions plus approfondies sur l’isolation, les secrets, le trafic sortant et les exigences de conformité, consultez la FAQ sur les sandbox d’agent IA.
Qu’est-ce qu’un sandbox d’agent IA ?
Un sandbox d’agent IA est la couche d’exécution où un agent IA effectue son travail réel : écrire et exécuter du code, installer des paquets, lire et modifier des fichiers, effectuer des appels API et interagir avec des sessions de 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 principal 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. S’il 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 facture en fonction de la quantité de calcul que vous avez consommée.
En quoi un sandbox d’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 d’agent va généralement une couche 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, de sorte qu’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 plates-formes 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 en dessous de 100 ms. Mais cela reste un surcoût par rapport au 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 totalement fiable sans entrée générée par l’utilisateur, un conteneur renforcé peut suffire.
Qu’est-ce que l’isolation dans le contexte des agents IA ?
L’isolation dans les sandbox d’agent opère sur plusieurs dimensions. Pour une analyse technique approfondie de la façon dont l’isolation des sandbox se comporte 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 a 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 les identifiants, fichiers de configuration ou autres secrets qui se trouvent en dehors du sandbox.
Isolation des processus — les processus à l’intérieur du sandbox ne peuvent pas voir ou signaler les processus à l’extérieur. L’agent peut lancer des sous-processus, des tâches en 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 d’agent peuvent être configurés pour que les appels réseau sortants soient bloqués, autorisés 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 connue de points de terminaison. Voir la section sur le filtrage du trafic sortant 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 du trafic sortant et pourquoi est-ce important ?
Le filtrage du trafic sortant 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 également qu’un agent compromis, ou un agent qui a été manipulé par une attaque par injection d’invite, 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, le trafic sortant est verrouillé sur une liste blanche 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 rejeté. C’est plus difficile à mettre en place et nécessite de maintenir la liste blanche à mesure que les dépendances de votre agent changent, mais cela vous donne une surface d’attaque beaucoup plus petite.
La plupart des déploiements d’agents en production se situent entre ces extrêmes : le trafic sortant n’est pas totalement libre, mais il n’est pas non plus verrouillé sur une liste de confiance zéro dès le premier jour. Les modèles courants incluent le blocage des destinations connues comme malveillantes, 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 de trafic sortant 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 trafic sortant programmatiques via le SDK. D’autres traitent le sandbox comme complètement ouvert vers l’extérieur par défaut. Sachez quel modèle votre fournisseur utilise avant de supposer que vos agents ne peuvent pas atteindre des hôtes externes.
Comment les secrets et les identifiants sont-ils délimités dans un sandbox d’agent ? {#secrets-and-credentials}
Les secrets passés dans un sandbox doivent être délimités uniquement à ce dont cette exécution spécifique de l’agent a besoin — et passés en tant que variables d’environnement ou jetons de courte durée plutôt que comme des identifiants à longue durée de vie écrits sur le disque. La frontière du sandbox limite le rayon d’explosion, mais elle n’empêche pas automatiquement un agent de lire et de transmettre tout identifiant auquel il peut accéder dans l’environnement.
Le principe fondamental est le moindre privilège : transmettez l’identifiant le plus restreint qui fonctionne, pas une clé cloud racine ou un compte de service avec des autorisations étendues. Les modèles courants :
Variables d’environnement au moment du lancement — injectez un secret dans l’environnement du sandbox au démarrage. Il est disponible pour le code de l’agent mais ne persiste pas dans les instantanés du système de fichiers et n’apparaît pas dans les journaux par défaut. Préférez les jetons de courte durée aux clés API statiques.
Blocage au niveau DNS — certaines configurations de déploiement permettent de restreindre les noms DNS qui peuvent être résolus depuis l’intérieur du sandbox. Cela empêche un agent de contacter un point de terminaison d’exfiltration d’identifiants même s’il a accès au réseau, en bloquant la résolution au niveau DNS plutôt que par adresse IP individuelle.
Comptes de service délimités avec TTL court — pour les agents qui appellent des API cloud, utilisez des chaînes d’assomption de rôle avec une durée de vie courte. Si l’identifiant fuit, la fenêtre de l’attaquant est limitée par la durée de vie du jeton.
Aucun fichier d’identifiants hôte — évitez de monter les fichiers d’identifiants de l’hôte (comme ~/.aws/credentials) dans le système de fichiers du sandbox. Générez plutôt des identifiants frais de courte durée par session.
Le sandbox fournit la frontière au niveau processus ; vous restez responsable de ce que vous y passez.
Comment fonctionnent les journaux d’audit dans les sandbox d’agent IA ? {#audit-logs}
Les journaux d’audit pour les sandbox d’agent couvrent généralement deux niveaux : les événements au niveau de la plateforme (sandbox créé, démarré, arrêté, expiré) et les événements au niveau de l’application (commandes exécutées, fichiers modifiés, appels API externes effectués). La plupart des fournisseurs gérés émettent les événements de plateforme automatiquement ; la journalisation au niveau de l’application est votre responsabilité d’instrumenter.
Ce qu’il faut capturer pour une couverture d’audit significative :
Événements du cycle de vie du sandbox — horodatage de création, durée de la session, raison de la terminaison (fermeture normale, expiration ou plantage). La plupart des plateformes gérées enregistrent ces événements automatiquement et les exposent via API ou tableau de bord.
Appels réseau sortants — quels hôtes l’agent a contactés, avec horodatages. C’est là que la journalisation du trafic sortant et la journalisation d’audit se chevauchent. Si votre plateforme prend en charge la journalisation du trafic sortant, activez-la et acheminez la sortie vers votre agrégateur de journaux.
Entrée/sortie d’exécution de code — les commandes qu’un agent a exécutées et les résultats qu’il a reçus. C’est au niveau de l’application et doit être capturé dans votre framework d’agent, pas au niveau de l’infrastructure du sandbox.
Mutations du système de fichiers — fichiers écrits, supprimés ou modifiés. Pertinent pour les agents de codage et les pipelines de traitement de données. Certaines plateformes de sandbox exposent des API de diff du système de fichiers à la fin de la session ; d’autres nécessitent une instrumentation dans votre code d’agent.
Pour les cas d’utilisation de conformité (SOC 2, HIPAA, secteurs réglementés), vous avez généralement besoin de journaux de plateforme dans un stockage inviolable, combinés à des journaux d’application de votre framework d’agent. Vérifiez ce que votre fournisseur émet réellement par rapport à ce qui nécessite une activation explicite avant de supposer une couverture.
Qu’est-ce que la création d’instantanés dans un sandbox d’agent ?
La création d’instantanés 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 quelques scénarios :
Réduction du 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é à chaque nouvelle session. Les démarrages à froid en moins de 90 ms de Daytona sont possibles grâce à cette technique.
Point de contrôle pour les agents longs — un agent de codage travaillant sur une tâche de plusieurs heures peut être mis en pause à mi-chemin, 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èle, vous pouvez instantanéer un état de départ connu 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 correspond.
Tous les fournisseurs de sandbox n’exposent pas les contrôles d’instantané au niveau de l’API. Le système de modèles d’E2B gère le cas d’utilisation « 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 alimentent les sandbox d’agent ?
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 intercepte 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 d’isolation.
Conteneurs Docker avec filtrage d’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 le 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 uniquement JavaScript mais pas utilisable pour les 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 d’isolation et la complexité opérationnelle du sandbox. Pour les charges de travail d’agent 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, système de fichiers racine en lecture seule et 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 un défaut dans le modèle de périphérique. Celles-ci sont rares car la surface d’attaque est petite par conception. 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 d’invite 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 un problème au niveau de l’application, pas au niveau du sandbox. Les sandbox aident à contenir les dégâts de l’injection d’invite (le code injecté s’exécute à l’intérieur du sandbox, pas sur votre hôte), mais ils n’empêchent 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, pour 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 la mauvaise configuration (trafic sortant trop permissif, identifiants mal délimités passés dans le sandbox) plutôt que des exploits au niveau du noyau.
Les sandbox d’agent IA prennent-ils en charge les charges de travail GPU ?
La plupart des sandbox d’agent IA à la mi-2026 n’incluent pas de support GPU. E2B, Daytona et Vercel Sandbox sont tous uniquement CPU.
Modal est la principale exception dans l’espace des sandbox gérés — il offre un accès GPU à la demande à l’intérieur des conteneurs, adapté à l’inférence de modèle, au réglage fin 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’agent, 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 les 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 utilisation hors ligne, les étapes d’entraînement RL ou les pipelines d’évaluation multi-é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é créé par un humain et peut faire des choses inattendues. C’est le cas d’utilisation principal : 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 afin que l’agent d’un utilisateur ne puisse pas affecter celui d’un autre, intentionnellement ou accidentellement.
Vous avez besoin de workflows avec état de longue durée — un agent de codage qui édite des fichiers, exécute des tests et valide des modifications a besoin d’un espace de travail qui persiste sur de nombreux tours 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 de l’agent 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 avec 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 locales ou l’état du système.
Si vous exécutez seulement un simple pipeline « résumez 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.
Quelle est la différence entre un interpréteur de code et un runtime d’agent ? {#code-interpreter-vs-agent-runtime}
Un interpréteur de code exécute un seul extrait de code en isolation et renvoie la sortie. Il est sans état par défaut : chaque exécution démarre proprement, le résultat revient et rien ne persiste. Considérez-le comme un noyau Jupyter isolé où les cellules ne partagent pas d’état entre les appels. C’est l’outil approprié pour l’analyse de données, l’évaluation de formules ou l’exécution de code ponctuelle où vous n’avez pas besoin d’état entre les exécutions.
Un runtime d’agent est un environnement d’exécution persistant et avec état conçu pour les workflows multi-étapes. L’agent peut écrire des fichiers, installer des paquets, exécuter des processus en arrière-plan, effectuer des appels réseau et accumuler l’état de l’espace de travail sur de nombreux tours LLM — sans perdre le contexte entre les étapes. Un agent de codage qui édite des fichiers, exécute des tests, lit les sorties d’erreur et itère opère dans un runtime d’agent, pas dans un interpréteur de code.
La distinction est importante pour la conception d’outils :
| Interpréteur de code | Runtime d’agent | |
|---|---|---|
| État entre les appels | Aucun (frais par exécution) | Persistant dans la session |
| Accès au système de fichiers | Généralement isolé par appel | Espace de travail persistant |
| Workflows multi-étapes | Pas conçu pour cela | Cas d’utilisation principal |
| Durée typique de session | Secondes | Minutes à heures |
| Exemples | Noyau Jupyter, cellule de code unique | E2B, Daytona, Novita Agent Sandbox |
En pratique, la ligne s’estompe. E2B et la plupart des plateformes de sandbox gérées peuvent se comporter comme un interpréteur de code (exécuter un extrait, renvoyer la sortie) mais elles fournissent l’infrastructure complète du runtime d’agent en dessous — système de fichiers persistant, gestion des processus, accès réseau. Des plateformes comme l’Interpréteur de code d’OpenAI sont spécialement conçues pour le cas d’utilisation sans état et font des compromis délibérés par rapport à la flexibilité qu’offre un runtime d’agent.
Choisissez un interpréteur de code lorsque vous avez besoin d’un environnement d’exécution rapide et isolé pour une seule tâche sans exigence d’état. Choisissez un runtime d’agent lorsque votre charge de travail implique l’édition itérative de fichiers, des dépendances de paquets installées, des processus de longue durée ou tout workflow qui doit reprendre là où il s’est arrêté.
Comment exécuter du code généré par IA en toute sécurité ? {#run-ai-generated-code-safely}
Exécuter du code généré par IA en toute sécurité en production nécessite les bons contrôles à chaque couche — le sandbox gère la frontière d’exécution, mais il y a aussi des décisions au niveau de l’application que vous devez prendre.
Utilisez l’isolation au niveau microVM, pas les conteneurs, pour le code non fiable. Les sandbox basés sur Firecracker (E2B, Novita Agent Sandbox) placent le code généré par LLM à l’intérieur d’une VM avec son propre noyau. Les évasions de conteneurs sont documentées et ont des vecteurs connus ; les évasions au niveau microVM nécessitent une vulnérabilité de l’hyperviseur et sont rares par conception. Le coût de démarrage à froid vaut la peine pour une frontière plus forte lorsque le code n’a pas été examiné par un humain.
Restreignez le trafic sortant à ce dont l’agent a réellement besoin. Un agent exécutant du code d’analyse de données n’a probablement pas besoin d’atteindre des hôtes internet arbitraires. Verrouillez le trafic sortant sur l’API du modèle, un registre de paquets spécifique et les services externes que la tâche exige explicitement. Dans les déploiements BYOC, cela peut être appliqué au niveau du groupe de sécurité VPC. Dans les déploiements gérés, utilisez les contrôles de trafic sortant du fournisseur s’ils sont disponibles, ou acceptez et journalisez le trafic sortant non restreint comme un risque connu.
Transmettez uniquement des identifiants délimités et de courte durée. Ne donnez pas au sandbox l’accès aux bases de données de production, aux clés cloud racines ou aux comptes de service étendus. Transmettez uniquement ce dont la tâche actuelle a besoin, en utilisant des identifiants avec une courte durée de vie. Si le code généré lit et exfiltre un identifiant, les dégâts sont limités.
Appliquez des délais d’attente et des limites de ressources. Définissez des limites explicites de temps et de mémoire sur l’exécution. Une boucle infinie générée par LLM ou une sortie anormalement volumineuse doit se terminer gracieusement, sans consommer la session indéfiniment ni remplir le disque.
Journalisez le trafic sortant et l’historique des commandes dès le début. Vous ne pouvez pas enquêter sur un comportement inattendu si vous n’avez pas d’enregistrement de ce que l’agent a fait. Activez la journalisation du trafic sortant tôt, même en développement. La journalisation au niveau de l’application des commandes exécutées, des écritures de fichiers et des appels externes est de votre ressort — l’infrastructure du sandbox ne le fait pas automatiquement.
Aucune configuration n’élimine complètement le risque. L’objectif est un risque résiduel connu et délimité : l’agent exécute du code que vous n’avez pas écrit, à l’intérieur d’une frontière d’isolation solide, avec les identifiants et l’accès réseau minimum dont il a besoin, et avec une journalisation suffisante pour détecter et diagnostiquer un comportement inattendu.
Questions fréquentes
Un sandbox d’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 durable et conçu pour être personnalisé et réutilisé. Un sandbox d’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 LLM dans une session (les faisant 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 d’agent IA — le terme « exécution » met simplement l’accent sur l’aspect runtime. Lorsqu’un LLM décide de prendre 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 fait l’agent et ce que le reste de votre système peut voir ou par quoi il peut être affecté. 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 à l’intérieur d’une microVM soutenue par KVM — le sandbox a son propre noyau totalement séparé du noyau hôte. gVisor intercepte les appels système en utilisant un noyau en espace utilisateur (runsc) sans exécuter un noyau invité complet. Le compromis pratique : Firecracker fournit 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 un noyau complet, mais l’isolation se situe entre une microVM complète et un conteneur renforcé avec interception d’appels système. Pour les charges de travail d’agent 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 d’invite peut-elle amener un agent à s’échapper de son sandbox ?
L’injection d’invite 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 voulues. Une instruction injectée comme « exfiltrez 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 trafic sortant 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 d’invite 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, liste blanche de trafic sortant) défendent contre l’agent qui est dirigé pour abuser de ces capacités.
Pourquoi avez-vous besoin d’un sandbox spécifiquement pour les agents IA ?
La différence clé par rapport à 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 simultanées. Cette incertitude augmente les enjeux pour chacun des contrôles de sécurité standard : la politique de trafic sortant importe car l’agent peut atteindre des points de terminaison que personne n’avait anticipés ; la gouvernance des paquets importe car l’agent peut installer des dépendances dynamiquement ; la journalisation d’audit importe car reconstruire ce qui s’est passé est plus difficile lorsque les actions de l’agent n’ont pas été 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 bref aperçu 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 celles qui utilisent 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émarrages à froid en moins de 90 ms, open-source (AGPL), auto-hébergeable. Meilleur pour les cas d’utilisation sensibles à la latence ou de conformité où une infrastructure auto-hébergée est requise.
- Modal — l’option principale lorsque vous avez besoin de GPU à l’intérieur du sandbox. Isolation basée sur des conteneurs.
- Vercel Sandbox — démarrages à froid rapides, meilleur 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 d’agent 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 d’agent IA comparant E2B et Daytona.
