- Pourquoi sandboxer les agents IA
- Modèles d'isolation des sandbox
- Sortie de la sandbox et politique réseau
- Accès aux fichiers et système de fichiers hôte
- État de session et persistance
- Installations de paquets et dépendances d'exécution
- Gestion des secrets et des identifiants
- Journaux d'audit et observabilité
- Conformité et révision de sécurité
- Tarification des sandbox et facteurs de coût
- Auto-hébergement vs sandbox pour agent IA gérée
- Exécuter du code non fiable en toute sécurité
- Articles recommandés
Les sandbox pour agents IA isolent le code généré des systèmes hôtes, mais les détails — comment fonctionne l’isolation, quel accès réseau les agents ont, où vont les fichiers, comment les secrets sont gérés — varient considérablement entre les implémentations. Cette FAQ regroupe les questions les plus courantes en une seule référence, avec des pointeurs vers les articles plus approfondis dans chaque domaine. Si vous débutez avec les sandbox, commencez par Qu’est-ce qu’une sandbox pour agent IA ? pour une base sur les modèles d’isolation, la sortie et les instantanés. Si vous choisissez un fournisseur, consultez Meilleures sandbox pour agents IA en 2026 ou le guide d’évaluation E2B vs Daytona.
Pourquoi sandboxer les agents IA
Pourquoi les équipes utilisent-elles une sandbox dédiée pour les agents IA ?
Les agents IA diffèrent des logiciels traditionnels sur un point crucial : le code qu’ils exécutent n’est pas écrit par un humain et revu avant exécution. Un LLM génère des instructions, sélectionne des outils, installe des paquets et effectue des appels API de manière dynamique — souvent d’une manière que le développeur de l’application n’a pas énumérée à l’avance. Une sandbox vous offre une couche d’application de l’exécution qui contient les conséquences de ces actions sans exiger que chaque action possible soit pré-approuvée. Sans sandbox, un agent défaillant ou manipulé peut affecter le système hôte, les charges de travail adjacentes ou l’infrastructure externe. Avec une sandbox, le rayon d’explosion maximal est limité à l’environnement isolé, qui peut être supprimé après la session.
Qu’est-ce que l’exécution de code par un agent IA ?
L’exécution de code par un agent IA est la phase d’exécution où les décisions d’un LLM deviennent des instructions réelles qu’un ordinateur exécute. L’agent reçoit une tâche, raisonne, génère du code ou des appels d’outils, et la couche d’exécution exécute ces actions et renvoie les résultats à l’agent. Une sandbox est la couche d’infrastructure standard pour cette phase d’exécution : elle fournit l’environnement de calcul, de système de fichiers et de réseau dont l’agent a besoin, tout en gardant cet environnement isolé de tout le reste. Le cycle “modèle raisonne → couche d’exécution s’exécute → résultats renvoyés au modèle” se répète jusqu’à ce que l’agent termine la tâche.
En quoi le sandboxing est-il différent du simple fait d’exécuter un agent dans un conteneur ?
Un conteneur ajoute une séparation du système de fichiers et de l’espace de noms réseau, mais tous les conteneurs sur le même hôte partagent le noyau du système d’exploitation. Pour les agents IA exécutant du code généré par LLM à partir d’entrées non fiables, une évasion du niveau noyau via une vulnérabilité partagée pourrait affecter les charges de travail adjacentes. Une sandbox dédiée pour agent IA ajoute généralement une barrière microVM : le code de l’agent s’exécute à l’intérieur d’une machine virtuelle légère avec son propre noyau invité, de sorte que même une exploitation du noyau dans l’invité n’affecte pas l’hôte. Le compromis pratique est un petit surcoût de démarrage à froid (généralement moins de 500 ms pour les plateformes basées sur Firecracker). Voir la section sur les modèles d’isolation pour une comparaison complète.
Modèles d’isolation des sandbox
Que signifie “isolation” dans une sandbox pour agent IA ?
L’isolation signifie que le code, les fichiers, les processus et l’accès réseau de l’agent sont confinés à un environnement limité qui ne peut pas affecter le système hôte ou les autres locataires. En pratique, l’isolation est un spectre : l’isolation au niveau processus utilise des primitives du système d’exploitation (espaces de noms, cgroups, seccomp) pour restreindre les appels système et l’accès aux ressources ; l’isolation par conteneur ajoute une barrière de système de fichiers et d’espace de noms réseau ; et l’isolation microVM encapsule la charge de travail dans une machine virtuelle légère avec son propre noyau invité. Chaque étape dans la pile augmente la force de la barrière au prix d’un certain surcoût de démarrage et d’une complexité opérationnelle. Pour un aperçu complet de toutes les dimensions de l’isolation, voir Qu’est-ce qu’une sandbox pour agent IA ?. Voir Firecracker pour les sandbox d’agents IA pour un cadre d’évaluation détaillé.
Docker est-il suffisant pour exécuter du code généré par un agent ?
Les conteneurs offrent des images reproductibles et de bons contrôles des ressources, mais tous les conteneurs sur le même hôte partagent le noyau de l’hôte. Une vulnérabilité du noyau, ou un appel système qui passe à travers le filtre seccomp, peut affecter d’autres charges de travail. Pour des tâches à faible risque et de courte durée exécutant du code de confiance ou quasi-confiance, les conteneurs sont souvent adéquats lorsqu’ils sont correctement durcis — pas de mode privilégié, capacités minimales, socket Docker non montée, système de fichiers racine en lecture seule si possible. Pour du code généré par IA non fiable qui peut installer des paquets, générer des sous-processus ou appeler des commandes shell arbitraires, une barrière plus forte mérite d’être évaluée. La réponse dépend de votre modèle de menace réel. Voir Sandbox pour code généré par IA : Exigences pour les applications de production pour la liste de vérification à chaque niveau d’isolation.
Quelle est la différence entre l’isolation par conteneur et par microVM ?
La différence clé est la barrière du noyau. Les conteneurs partagent le noyau de l’hôte ; les microVM exécutent chacune un noyau invité à l’intérieur d’une machine virtuelle légère, soutenue par la virtualisation matérielle (KVM). Une sandbox basée sur microVM utilisant une technologie comme Firecracker offre une barrière de type VM sans le surcoût complet d’une VM traditionnelle : la latence de démarrage est conçue pour être rapide, le modèle de périphérique est minimal pour réduire la surface d’attaque, et l’invité est isolé du noyau hôte par conception. L’implication pratique est qu’une exploitation du noyau dans l’invité n’affecte pas automatiquement l’hôte ou les autres invités, alors que dans un modèle de conteneur à noyau partagé, cela pourrait être le cas. Voir Firecracker pour les sandbox d’agents IA pour savoir où la barrière microVM aide et où elle ne résout pas tout le problème.
Existe-t-il une sandbox par agent, par utilisateur ou par tâche ?
Cela dépend de la plateforme et de la conception de l’application. Le modèle le plus sûr pour les applications multi-locataires est un environnement sandbox isolé par exécution d’agent ou par tâche — ce qui signifie que la session de chaque utilisateur a sa propre arborescence de processus, son propre système de fichiers, son propre espace de noms réseau et son propre périmètre d’identifiants. Partager une sandbox entre utilisateurs ou entre tâches non liées est la source la plus courante de fuite d’état dans les applications d’agents en production. Lors de l’évaluation d’une plateforme, vérifiez que les sessions concurrentes sont isolées au niveau du système de fichiers, des processus et du réseau, et pas seulement au niveau du routage API. Voir Sandbox pour code généré par IA : Exigences pour les applications de production pour la liste de vérification d’isolation par session.
Sortie de la sandbox et politique réseau
Un agent IA peut-il effectuer des appels réseau sortants depuis une sandbox ?
Cela dépend de la politique de sortie de la sandbox. Par défaut, de nombreuses sandbox autorisent les connexions sortantes, ce qui est pratique pour la recherche web, les appels API et les installations de paquets. Pour les charges de travail de production exécutant du code non fiable, une sortie ouverte par défaut est un risque : un agent compromis ou défaillant peut exfiltrer des données, atteindre des services de métadonnées internes ou extraire du code inattendu à partir d’URL arbitraires. Une posture de production plus forte est une sortie par défaut refusée avec une liste blanche explicite des destinations autorisées. Quelle que soit la politique choisie, elle doit être explicite et journalisée. Voir Firecracker pour les sandbox d’agents IA pour savoir comment évaluer les contrôles réseau.
Comment le DNS est-il contrôlé dans une sandbox ?
Le DNS est une lacune courante dans la politique de sortie : une liste blanche pour les destinations HTTP ne restreint pas automatiquement la résolution DNS. Un agent capable de résoudre des noms de domaine arbitraires peut déduire la topologie du réseau, sonder des noms internes ou utiliser le DNS comme canal auxiliaire même lorsque HTTP est bloqué. Pour une politique de sortie cohérente, la résolution DNS doit être gérée de manière cohérente — soit en pointant vers un résolveur interne qui respecte la liste blanche, soit en restreignant la résolution aux domaines approuvés. Vérifiez auprès de votre fournisseur de sandbox comment le DNS est limité par rapport à la politique de sortie globale.
Comment les téléchargements de paquets sont-ils contrôlés lors de sessions réseau restreintes ?
Les installations de paquets sont des opérations réseau. Si la sortie est restreinte à une liste blanche, la liste blanche doit inclure les registres de paquets dont l’agent a légitimement besoin, ou la sandbox doit fournir un cache de transit dans le réseau de confiance. Le cache de transit a l’avantage supplémentaire de servir de point d’inspection : vous pouvez voir quels paquets sont extraits, détecter les dépendances inattendues et réduire les sorties redondantes. Certaines équipes utilisent des modèles de sandbox pré-construits pour les charges de travail où la reproductibilité est plus importante que la flexibilité, ce qui élimine complètement les téléchargements de paquets à l’exécution. Voir la section Installations de paquets pour en savoir plus sur la gestion des installations à l’exécution.
Accès aux fichiers et système de fichiers hôte
À quels fichiers un agent sandboxé a-t-il accès ?
Un agent sandboxé ne devrait avoir accès qu’aux fichiers explicitement montés dans son espace de travail. Pour un agent de codage, cela peut être un dépôt extrait et un répertoire de travail pour les artefacts générés. Pour un agent d’analyse de données, cela peut être un fichier CSV téléchargé et un dossier de sortie. L’agent ne devrait pas pouvoir atteindre le système de fichiers hôte, les espaces de travail des autres locataires, les secrets du serveur d’application ou les répertoires système en dehors de ses chemins montés. Une bonne pratique consiste à monter le matériel source en lecture seule et à fournir un répertoire de sortie séparé en lecture-écriture pour les artefacts générés. Voir Sandbox pour serveur MCP : serveurs MCP isolés avec contrôles du système de fichiers, des secrets et du réseau pour savoir comment limiter les montages du système de fichiers par outil.
Le système de fichiers hôte est-il accessible depuis l’intérieur d’une sandbox ?
Il ne devrait pas l’être. Une sandbox correctement configurée — conteneur ou microVM — restreint la vue de l’agent à son propre système de fichiers invité. Accéder au système de fichiers hôte depuis l’intérieur d’une sandbox est une erreur de configuration, pas un comportement attendu. Les erreurs courantes qui brisent cette barrière incluent le montage de répertoires larges (comme le répertoire personnel d’un développeur ou /), l’utilisation du mode privilégié dans les conteneurs, ou le montage du socket Docker dans la sandbox. Lors de l’évaluation d’une plateforme ou de la construction de la vôtre, vérifiez ce qui est monté, quelles sont les permissions du système de fichiers racine, et si les échappements de liens symboliques ou les astuces d’extraction d’archives peuvent atteindre des chemins en dehors de l’espace de travail prévu.
Que deviennent les fichiers après la fin d’une session ?
Pour les sessions éphémères, le répertoire de travail et tous les fichiers générés sont détruits lorsque la session se termine. C’est la valeur par défaut appropriée pour la complétion de code, les exécutions d’évaluation et toute tâche où la reproductibilité est plus importante que la continuité. Pour les espaces de travail persistants (agents de codage de longue durée, sessions de développement itératives), les fichiers peuvent survivre à plusieurs appels d’exécution au sein d’une session et peuvent être conservés après la fin de la session si la plateforme prend en charge la persistance de l’espace de travail ou les instantanés. Les questions clés auxquelles répondre sont : à qui appartient un espace de travail conservé, quand est-il nettoyé, et un espace de travail d’un utilisateur peut-il fuiter vers un autre ? Voir Sandbox pour code généré par IA : Exigences pour les applications de production pour la liste de vérification du modèle de persistance.
État de session et persistance
Une session sandbox est-elle avec état ou éphémère ?
Les deux modèles existent et servent différentes charges de travail. Les sessions éphémères démarrent à partir d’une base de référence propre pour chaque tâche — pas de paquets, fichiers ou historique accumulés. Elles sont plus faciles à raisonner et idéales pour les exécutions d’évaluation ou l’exécution de code ponctuelle. Les sessions avec état préservent les fichiers, les paquets installés, l’historique du shell et l’état de l’environnement à travers plusieurs appels d’exécution, ce qui est nécessaire pour les agents de codage multi-étapes, l’analyse de données interactive et les workflows de longue durée. La plupart des plateformes de production prennent en charge les deux. Le compromis est que les sessions avec état nécessitent des politiques de nettoyage explicites et une isolation des locataires plus soignée.
Combien de temps l’état persiste-t-il dans une sandbox gérée ?
La durée de session varie selon la plateforme et le plan. Certains fournisseurs définissent un délai d’expiration de session par défaut (généralement de 60 minutes à 24 heures), après quoi la session est terminée et l’état est perdu, sauf s’il est persisté vers un instantané ou un stockage externe. Les workflows d’agents de longue durée — des sessions qui peuvent s’interrompre entre les appels LLM pendant des minutes ou des heures — ont besoin d’une plateforme qui prend en charge la pause et la reprise de session ou l’auto-pause pour éviter la facturation du temps d’inactivité tout en préservant l’état. Vérifiez la durée de session maximale et ce qui arrive à l’état en cours lorsqu’un délai d’expiration se produit. Novita Agent Sandbox prend en charge des sessions jusqu’à 24 heures et documente une capacité de Pause/Reprise automatique pour gérer le temps d’inactivité. Voir Novita Sandbox : une alternative rentable à E2B Pro avec une compatibilité transparente pour une comparaison des fonctionnalités.
Les sessions peuvent-elles être mises en pause et reprises ?
Certaines plateformes prennent en charge la pause et la reprise, où la session est suspendue sur le disque et peut être redémarrée plus tard à partir du même état. Cela est utile pour les agents qui attendent des réponses LLM entre les étapes, pour limiter le débit des charges de travail coûteuses, et pour les sessions qui s’étendent sur plusieurs interactions utilisateur au fil du temps. Les points clés à vérifier sont : combien de temps une session en pause peut rester suspendue, ce qui arrive aux connexions réseau maintenues pendant une pause, et si les identifiants injectés au début de la session restent valides après la reprise ou doivent être actualisés.
L’état de la sandbox peut-il être instantané et réutilisé ?
Les modèles et les instantanés sont liés mais distincts. Un modèle est un environnement de base pré-construit — environnements d’exécution, outils, paquets approuvés — à partir duquel les nouvelles sessions démarrent. Un instantané capture l’état actuel d’une session en cours et l’utilise comme point de départ pour les sessions futures. Les modèles réduisent le surcoût de démarrage par session et garantissent que tous les agents démarrent à partir d’une base cohérente et gouvernée. Les instantanés sont utiles pour préserver un travail partiel ou pour démarrer à chaud des travaux itératifs. Les deux nécessitent une gouvernance : qui peut les créer, qui peut les lire, à quel locataire ils appartiennent, et comment ils sont versionnés.
Installations de paquets et dépendances d’exécution
Les agents peuvent-ils installer des paquets à l’exécution ?
La plupart des environnements sandbox autorisent les installations de paquets à l’exécution (pip install, npm install, apt-get, etc.) par défaut car de nombreuses charges de travail d’agents en ont besoin. La question n’est pas de savoir si les installations sont autorisées, mais si chaque installation est gouvernée. Les installations de paquets non gouvernées sont l’une des opérations les plus risquées dans une sandbox : elles extraient du code externe dans l’environnement d’exécution, peuvent inclure des scripts post-installation qui exécutent des commandes arbitraires, et peuvent introduire des risques dans la chaîne d’approvisionnement.
Quelles politiques régissent les installations de paquets à l’exécution ?
Une politique de paquets de production comprend généralement une combinaison de mise sur liste blanche des registres (ne récupérer qu’à partir de registres ou miroirs de paquets approuvés), de caches de transit (inspecter ce qui entre avant de l’exécuter), de journalisation des installations (enregistrer le nom, la version, la source et le résultat du paquet pour chaque installation), et de mode hors ligne facultatif (pré-intégrer les dépendances dans le modèle et interdire les installations à l’exécution pour les pipelines d’évaluation où la reproductibilité est importante). La politique appropriée dépend de la charge de travail : un agent de codage aidant un développeur à déboguer du code peut avoir besoin d’un accès flexible aux paquets ; un pipeline d’évaluation automatisé devrait probablement s’exécuter à partir d’un environnement figé. Voir Construire un analyste de données IA avec Python sandboxé et accès contrôlé aux paquets pour un exemple d’implémentation pratique.
Gestion des secrets et des identifiants
Comment les secrets et les identifiants sont-ils gérés dans une sandbox ?
Les secrets doivent être injectés de manière étroite — uniquement l’identifiant dont une tâche spécifique a besoin, pour la durée de cette session. L’antipattern courant consiste à monter un fichier d’environnement large contenant toutes les clés API dans chaque session ; cela signifie que toute session, si elle est compromise, peut accéder à tous les identifiants de ce fichier. Préférez les jetons de courte durée limités à la tâche, et préférez les mécanismes d’injection (variables d’environnement ou fichiers montés) plutôt que le codage en dur. Pour les identifiants les plus sensibles, une API de secrets à l’exécution qui fournit des valeurs uniquement à un processus explicitement autorisé offre une isolation plus forte qu’une variable d’environnement plate disponible pour tous les processus.
Le modèle peut-il voir les variables d’environnement injectées dans la sandbox ?
Oui, si la variable d’environnement est injectée dans le processus dans lequel le code du modèle s’exécute. Les variables d’environnement sont visibles par tous les processus dans la même session par défaut. Le modèle ne peut pas les lire directement depuis sa fenêtre de contexte, mais le code généré qui s’exécute à l’intérieur de la sandbox peut les lire avec os.environ, process.env, ou équivalent. C’est pourquoi une portée étroite est importante : n’injectez que les identifiants dont la tâche a besoin, et préférez les jetons de courte durée afin qu’un identifiant divulgué ait une fenêtre d’utilité limitée. La rédaction est une responsabilité de l’application : ne journalisez pas la sortie standard complète par défaut si des secrets peuvent apparaître dans les messages d’erreur ou les instructions d’impression.
Que deviennent les secrets à la fin d’une session ?
Les variables d’environnement et les fichiers de secrets montés doivent être nettoyés dans le cadre de la destruction de la session. Si la plateforme préserve l’état entre les sessions (instantanés, volumes persistants), vérifiez que les identifiants écrits sur le système de fichiers ou mis en cache par un fournisseur d’identifiants sont également nettoyés ou remplacés. Des identifiants obsolètes dans un instantané reprenable sont un risque — après la destruction de la session, l’instantané ne devrait pas conserver de jetons qui n’étaient valides que pour la durée de la session d’origine.
Journaux d’audit et observabilité
Quels événements sont journalisés dans une sandbox ?
Les enregistrements d’audit utiles d’une sandbox incluent la création et la destruction de session (ID de session, locataire, version du modèle, allocation de ressources, durée), les événements d’exécution (quel code ou catégorie de commande a été exécuté, heure de début/fin, statut de sortie), les installations de paquets (nom, version, source, résultat), les contacts réseau sortants (domaines, IP, ports), les fichiers lus ou écrits à partir de chemins spécifiques, et le résultat du nettoyage. L’objectif est de rendre le comportement de l’agent reconstructible après coup sans transformer le journal d’audit en un deuxième magasin de secrets. Les fichiers bruts des clients, la sortie complète des commandes et les invites complètes n’ont généralement pas leur place dans les journaux d’audit, à moins que vos contrôles de conservation et d’accès ne soient spécifiquement conçus pour ces données.
Qui peut accéder aux journaux d’audit ?
Les contrôles d’accès sur les journaux d’audit doivent être limités à l’opérateur et, le cas échéant, au locataire. Dans les plateformes multi-locataires, les enregistrements d’audit d’un locataire ne doivent pas être visibles par les autres locataires. Pour les déploiements sensibles à la conformité, la piste d’audit doit être infalsifiable, conservée pendant la période requise et accessible aux réviseurs autorisés (équipe de sécurité, responsable de la conformité) sur demande. Demandez à votre fournisseur de sandbox quelle est la période de conservation des journaux par défaut, si les journaux peuvent être exportés vers votre propre SIEM ou stockage, et quels contrôles d’accès protègent les données des journaux.
Conformité et révision de sécurité
Quelle révision de conformité est nécessaire avant d’utiliser une sandbox en production ?
Les exigences spécifiques dépendent de votre secteur et de votre juridiction, mais les questions standard pour tout système d’agent en production incluent : quelles données entrent dans la sandbox (et ces données sont-elles soumises au RGPD, à la HIPAA, à SOC 2 ou à d’autres cadres), où la sandbox est-elle hébergée et cela satisfait-il aux exigences de résidence des données, quel est le modèle d’isolation et pouvez-vous le documenter pour un auditeur, comment les identifiants sont-ils gérés et remplacés, et à quoi ressemble la piste d’audit ? La plupart des révisions de sécurité demanderont également si le code généré pourrait atteindre les bases de données de production, les surfaces d’administration internes ou les données clients en dehors du périmètre prévu. Ce sont des contrôles architecturaux, pas seulement des certifications de fournisseur.
Quelles questions les équipes de sécurité devraient-elles poser lors de l’évaluation d’une sandbox pour agent IA ?
Une liste de vérification pratique pour la révision de sécurité :
- Isolation : Quelle est la barrière — processus, conteneur ou microVM ? Chaque session d’agent est-elle isolée au niveau du système de fichiers, des processus et du réseau ?
- Sortie : Quelle est la politique de sortie par défaut ? Les destinations sortantes peuvent-elles être mises sur liste blanche ? Comment le DNS est-il contrôlé ?
- Secrets : Comment les identifiants sont-ils injectés ? Sont-ils limités à la tâche ? Sont-ils nettoyés lors de la destruction de la session ?
- Audit : Quels événements sont journalisés ? Qui peut accéder aux journaux ? Quelle est la période de conservation ?
- Résidence des données : Où les sandbox sont-elles hébergées ? Le déploiement peut-il être limité à une région cloud ou un compte spécifique ?
- Posture de conformité : Le fournisseur détient-il des certifications pertinentes (SOC 2, ISO 27001) ? Quel est son modèle de responsabilité partagée ?
- Portée réseau : Une sandbox peut-elle atteindre les services de métadonnées internes, les API privées ou les ressources des autres locataires ? Comment le mouvement latéral est-il empêché ?
Formulez-les comme des questions à évaluer plutôt que des exigences qu’un seul fournisseur satisfait automatiquement. Les affirmations de sécurité et de conformité dans la documentation du fournisseur doivent être vérifiées par rapport aux documents produits actuels, et non prises au pied de la lettre. Pour les équipes ayant des exigences réglementaires ou contractuelles, faites effectuer la révision par votre équipe de sécurité avant le déploiement en production, pas après.
Quand le BYOC (apportez votre propre cloud) ou le déploiement VPC est-il pertinent ?
Les exigences de résidence des données, les politiques de sécurité réseau ou les contraintes réglementaires qui interdisent aux données de quitter un compte cloud spécifique sont les principales raisons pour lesquelles les équipes choisissent le déploiement BYOC ou VPC plutôt qu’un service géré partagé. Exécuter des sandbox à l’intérieur de votre propre VPC AWS ou GCP signifie que l’environnement d’exécution se trouve dans votre périmètre réseau, que les contrôles d’accès de votre compte cloud s’appliquent, et que la sortie de la sandbox peut être régie par vos politiques réseau existantes. Le compromis est la responsabilité opérationnelle : vous gérez l’infrastructure, les correctifs et la mise à l’échelle. Novita Agent Sandbox documente le déploiement BYOC dans des comptes AWS ou GCP comme une fonctionnalité pour les équipes ayant ces exigences. Vérifiez la disponibilité actuelle et les options de configuration dans la documentation Novita Agent Sandbox.
Tarification des sandbox et facteurs de coût
Qu’est-ce qui détermine les coûts des sandbox ?
Les coûts des sandbox sont généralement une combinaison de temps de calcul (vCPU et mémoire facturés à la seconde ou à la minute), de frais généraux de session (frais de démarrage par session sur certaines plateformes), de stockage persistant au-delà du niveau gratuit inclus, et de transfert de données sortant (sortie). Le poids relatif de chacun dépend de votre charge de travail : un interpréteur de code à session courte est principalement du calcul ; un agent d’automatisation de navigateur qui télécharge de gros fichiers peut générer une sortie importante ; un espace de travail de codage persistant accumulera du stockage. La gestion du temps d’inactivité est un différenciateur majeur — les plateformes avec pause automatique cessent de facturer lorsqu’une sandbox attend une réponse LLM, ce qui peut réduire considérablement les coûts pour les workflows interactifs. Voir Modèles de tarification des sandbox pour agents IA : par session, calcul, stockage et sortie pour une ventilation détaillée de chaque axe de tarification.
Comment le temps de session, le calcul et la sortie interagissent-ils dans le coût ?
Pour la plupart des charges de travail, le temps de calcul domine. Une session de codage de 10 minutes sur 1 vCPU coûte plus cher que 1 Go de sortie aux tarifs typiques. Mais l’interaction compte pour des charges de travail spécifiques : un agent de données qui télécharge un grand ensemble de données d’entraînement générera des frais de sortie qui éclipsent le coût de calcul. Un agent de navigation qui maintient les sessions ouvertes entre les tours LLM accumulera du calcul inactif si la pause automatique n’est pas activée. L’approche pratique consiste à estimer chaque dimension par rapport à votre profil de charge de travail réel avant de vous engager sur une plateforme. Novita Agent Sandbox facture à la seconde en fonction de l’utilisation réelle du vCPU et de la mémoire, sans frais de démarrage par session ; à la mi-2026, 1 vCPU est au prix de 0,0000098 $/s. (Source : page de tarification Novita AI, vérifiée dans la documentation publiée. Vérifiez toujours les tarifs actuels avant la planification budgétaire.)
Auto-hébergement vs sandbox pour agent IA gérée
Quand les équipes devraient-elles s’auto-héberger plutôt que d’utiliser une sandbox gérée ?
L’auto-hébergement (exécution de votre propre infrastructure de sandbox, souvent sur Firecracker ou une couche microVM comparable) a du sens lorsque : les exigences de résidence des données ou de politique réseau interdisent l’utilisation d’un service géré tiers, le volume de charge de travail est suffisamment élevé pour que le coût du service géré dépasse le coût opérationnel de l’exécution de votre propre infrastructure, ou l’équipe dispose d’une capacité d’ingénierie de plateforme existante et souhaite un contrôle total sur le modèle d’isolation, la gouvernance des images et la politique réseau. L’auto-hébergement est plus difficile qu’il n’y paraît : la gestion des noyaux, des systèmes de fichiers racine, des images, des instantanés, des limiteurs de débit, des métriques, du nettoyage et de l’isolation multi-locataire est un vrai travail. Voir Firecracker pour les sandbox d’agents IA pour savoir à quoi ressemble le périmètre opérationnel.
Quand une sandbox gérée est-elle plus judicieuse ?
Pour la plupart des équipes construisant des agents de codage, des outils d’analyse de données, des workflows d’automatisation de navigateur ou des pipelines d’évaluation, une sandbox gérée est le chemin le plus rapide vers la production. La plateforme gère le provisionnement de l’infrastructure, le durcissement de la sécurité, les mises à jour des images, la mise à l’échelle et la gestion du cycle de vie. L’équipe se concentre sur l’architecture de l’agent, pas sur les internes de la sandbox. La comparaison des coûts ne concerne pas seulement les tarifs de calcul cloud : tenez compte du temps d’ingénierie pour construire et maintenir la couche d’isolation, du travail de conformité pour la documenter, et de la réponse aux incidents lorsque quelque chose d’inattendu se produit. Pour les équipes sans capacité d’ingénierie de plateforme dédiée, les services gérés atteignent généralement la production plus rapidement et maintiennent un coût total de possession inférieur. Voir Modèles de tarification des sandbox pour agents IA pour un cadre de comparaison du coût total entre géré et auto-hébergé.
Quelles questions les équipes devraient-elles poser lors de l’évaluation des fournisseurs de sandbox gérées ?
Questions d’évaluation pratiques au-delà de la tarification initiale :
- Quel est le modèle d’isolation par session (microVM, conteneur, processus) ?
- Quelle est la politique de sortie par défaut et configurable ?
- Quelles options de gouvernance des installations de paquets existent ?
- Comment les secrets sont-ils injectés et nettoyés ?
- Quelles données de journal d’audit sont disponibles et comment y accéder ?
- Quelles sont les limites de durée de session et de concurrence à votre niveau requis ?
- Le fournisseur prend-il en charge le déploiement BYOC ou VPC ?
- Quel est le comportement de pause/reprise et comment affecte-t-il la facturation ?
- Comment la latence de démarrage se comporte-t-elle à l’échelle (pool chaud, instantané, démarrage à froid) ?
Exécuter du code non fiable en toute sécurité
Comment exécuter du code généré par IA en toute sécurité en production ?
La base est : n’exécutez pas de code généré par LLM sur votre hôte. Acheminez toute l’exécution via une sandbox qui fournit une isolation du système de fichiers, des processus et du réseau. Au-delà, cinq pratiques font une différence significative : (1) définissez la politique de sortie explicitement — refus par défaut avec une liste blanche est plus sûr qu’ouvert par défaut ; (2) limitez étroitement les secrets — n’injectez que les identifiants dont la tâche actuelle a besoin ; (3) gouvernez les installations de paquets — autorisez les installations à partir de registres approuvés, ou utilisez des images pré-construites pour les charges de travail reproductibles ; (4) journalisez au niveau du noyau ou de l’hyperviseur plutôt que de vous fier aux journaux de la couche application ; (5) définissez des limites de ressources — CPU, mémoire, disque et délai d’expiration — afin qu’un agent incontrôlable ne puisse pas affecter les sessions adjacentes. Voir Quelle est la sécurité de la sandbox IA pour l’exécution de code ? pour une liste de vérification complète.
Existe-t-il une sandbox open source pour agent IA ?
Oui. Daytona est open source sous licence AGPL et prend en charge le déploiement auto-hébergé. Le SDK principal d’E2B est open source, bien que l’infrastructure d’exécution gérée ne le soit pas. Si vous voulez construire votre propre sandbox à partir de zéro, l’approche la plus courante est Firecracker (développé par AWS, sous licence Apache 2.0) comme environnement d’exécution microVM, combiné à votre propre gestion d’images, orchestration et contrôle du cycle de vie. L’auto-hébergement signifie assumer le périmètre opérationnel qu’un service géré abstrait : gestion du noyau, gouvernance du système de fichiers racine, limitation du débit, stockage des instantanés, politiques de nettoyage et isolation multi-locataire. Voir Firecracker pour les sandbox d’agents IA pour savoir à quoi ressemble ce périmètre en pratique.
Qu’est-ce qu’une plateforme de sandbox IA gérée ?
Une plateforme de sandbox IA gérée est un service cloud qui fournit une infrastructure de sandbox sous forme d’API : vous appelez le SDK, une sandbox est provisionnée et renvoyée dans un état prêt, et la plateforme gère le calcul, le réseau, la gestion des images et le cycle de vie sous-jacents. Novita Agent Sandbox, E2B et le mode géré de Daytona en sont des exemples. L’alternative est l’auto-hébergement, où vous provisionnez et exploitez vous-même l’infrastructure de sandbox. Les questions clés pour toute plateforme gérée sont : quel modèle d’isolation elle utilise, quelle politique de sortie est configurable, si le déploiement BYOC ou VPC est disponible, et à quoi ressemble la tarification à la seconde pour votre charge de travail attendue. Voir Meilleures sandbox pour agents IA en 2026 pour une comparaison structurée.
Qu’est-ce qu’une sandbox pour agent IA à usage entreprise ?
Les exigences d’une sandbox pour agent IA en entreprise s’étendent généralement au-delà de ce qu’un service géré axé sur les développeurs fournit par défaut. Les exigences courantes incluent : le déploiement BYOC ou VPC (la sandbox s’exécute à l’intérieur de votre compte cloud, pas dans un locataire tiers partagé) ; la certification SOC 2 ou ISO 27001 ; une politique de sortie configurable et l’exportation des journaux d’audit vers un SIEM ; le cadrage des identifiants au niveau de la session avec des jetons de courte durée ; et des contrôles de résidence des données qui restreignent l’endroit où les charges de travail des agents s’exécutent. Novita Agent Sandbox prend en charge le déploiement BYOC dans votre propre VPC AWS ou GCP, ce qui répond aux exigences les plus courantes des entreprises en matière de résidence des données et d’isolation réseau. Vérifiez les certifications de conformité actuelles et les options de configuration disponibles dans la documentation du produit avant de prendre des décisions d’architecture.
