- Pourquoi Sandboxer les Agents IA
- Modèles d'Isolation du Sandbox
- Egress du 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
- Secrets et Gestion des Identifiants
- Journaux d'Audit et Observabilité
- Conformité et Revue de Sécurité
- Tarification du Sandbox et Facteurs de Coût
- Auto-Hébergement vs. Sandbox Géré pour Agents IA
- Exécution Sécurisée de Code Non Fiable
- Articles Recommandés
Cette FAQ sur le sandbox pour agents IA répond aux questions pratiques de sécurité que les développeurs se posent avant d’exécuter du code généré par un agent : comment fonctionne l’isolation, quel accès réseau les agents ont, où vont les fichiers et l’état de session, et comment gérer les secrets, les journaux d’audit, la conformité et les coûts. Si vous débutez avec les sandbox, commencez par Qu’est-ce qu’un Sandbox pour Agent IA ? pour les bases sur les modèles d’isolation, l’egress et les instantanés. Si vous choisissez un fournisseur, consultez Meilleurs Sandbox pour Agents IA en 2026 ou le guide d’évaluation E2B vs. Daytona.
Pourquoi Sandboxer les Agents IA
Pourquoi les équipes utilisent-elles un sandbox dédié pour les agents IA ?
Les agents IA diffèrent des logiciels traditionnels sur un point critique : le code qu’ils exécutent n’est pas écrit par un humain et révisé 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. Un 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 malveillant ou manipulé peut affecter le système hôte, les charges de travail adjacentes ou l’infrastructure externe. Avec un 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 à son sujet, 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. Un sandbox est la couche d’infrastructure standard pour cette phase d’exécution : il fournit le calcul, le système de fichiers et l’environnement réseau dont l’agent a besoin, tout en maintenant cet environnement isolé de tout le reste. Le cycle « le modèle raisonne → la couche d’exécution s’exécute → les résultats sont 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 de l’espace de noms du système de fichiers et du 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 fuite au niveau du noyau via une vulnérabilité partagée pourrait affecter les charges de travail adjacentes. Un sandbox dédié pour agents 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 qu même une exploitation au niveau du noyau dans l’invité n’affecte pas l’hôte. Le compromis pratique est un léger surcoût de démarrage à froid (généralement moins de 500 ms pour les plates-formes basées sur Firecracker). Voir la section sur les modèles d’isolation pour une comparaison complète.
Modèles d’Isolation du Sandbox
Que signifie « isolation » dans un 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 dé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 des 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 d’espace de noms du système de fichiers et du réseau ; et l’isolation par microVM enveloppe la charge de travail dans une machine virtuelle légère avec son propre noyau invité. Chaque étape vers le haut de 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’un 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 vous offrent des images reproductibles et de bons contrôles de 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 les tâches à faible risque et de courte durée exécutant du code fiable ou quasi-fiable, les conteneurs sont souvent adéquats lorsqu’ils sont correctement durcis — pas de mode privilégié, capacités minimales, pas de socket Docker monté, système de fichiers racine en lecture seule si possible. Pour le code non fiable généré par l’IA 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). Un sandbox basé sur microVM utilisant une technologie comme Firecracker fournit 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 un sandbox par agent, par utilisateur ou par tâche ?
Cela dépend de la plateforme et de la façon dont l’application est conçue. 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 un 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 de l’isolation par session.
Egress du Sandbox et Politique Réseau
Un agent IA peut-il effectuer des appels réseau sortants depuis un sandbox ?
Cela dépend de la politique d’egress du sandbox. Par défaut, de nombreux sandbox autorisent les connexions sortantes, ce qui est pratique pour la recherche web, les appels API et l’installation de paquets. Pour les charges de travail de production exécutant du code non fiable, un egress ouvert par défaut est un risque : un agent compromis ou malveillant peut exfiltrer des données, atteindre des services de métadonnées internes ou extraire du code inattendu d’URL arbitraires. Une posture de production plus robuste est un egress refusé par défaut avec une liste d’autorisation explicite des destinations permises. Quelle que soit la politique que vous choisissez, 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 un sandbox ?
Le DNS est une lacune courante dans la politique d’egress : une liste d’autorisation pour les destinations HTTP ne restreint pas automatiquement la résolution DNS. Un agent qui peut 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 secondaire même lorsque HTTP est bloqué. Pour une politique d’egress 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 d’autorisation, 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 d’egress globale.
Comment les téléchargements de paquets sont-ils contrôlés lors de sessions à accès réseau restreint ?
Les installations de paquets sont des opérations réseau. Si l’egress est restreint à une liste d’autorisation, celle-ci doit inclure les registres de paquets dont l’agent a légitimement besoin, ou le sandbox doit fournir un cache « pull-through » au sein du réseau de confiance. Le cache « pull-through » a l’avantage supplémentaire de servir de point d’inspection : vous pouvez voir quels paquets sont téléchargés, détecter les dépendances inattendues et réduire l’egress redondant. Certaines équipes utilisent des modèles de sandbox pré-configurés pour les charges de travail où la reproductibilité prime sur la flexibilité, ce qui élimine complètement les téléchargements de paquets à l’exécution. Voir la section Installations de Paquets pour plus d’informations sur la gouvernance 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 accéder au système de fichiers hôte, aux espaces de travail des autres locataires, aux secrets du serveur d’application ou aux 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 en lecture-écriture séparé 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’un sandbox ?
Il ne devrait pas l’être. Un sandbox correctement configuré — 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’un sandbox est un échec 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 le 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 des évasions par lien symbolique ou des astuces d’extraction d’archive 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 à la fin de la session. C’est la valeur par défaut correcte pour la complétion de code, les exécutions d’évaluation et toute tâche où la reproductibilité prime sur la continuité. Pour les espaces de travail persistants (agents de codage longue durée, sessions de développement itératif), les fichiers peuvent survivre entre les 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 à résoudre sont : à qui appartient un espace de travail conservé, quand est-il nettoyé et l’espace de travail d’un utilisateur peut-il fuir vers celui d’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 unique. Les sessions avec état préservent les fichiers, les paquets installés, l’historique du shell et l’état de l’environnement entre plusieurs appels d’exécution, ce qui est nécessaire pour les agents de codage en plusieurs étapes, l’analyse de données interactive et les flux de travail longs. 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 plus minutieuse des locataires.
Combien de temps l’état persiste-t-il dans un sandbox géré ?
La durée de la session varie selon la plateforme et le forfait. 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 persistant vers un instantané ou un stockage externe. Les flux de travail d’agents de longue durée — sessions qui peuvent faire une pause 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 des temps d’inactivité tout en préservant l’état. Vérifiez la durée maximale de session 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 les 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. Ceci 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 dans le 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 du 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 de référence cohérente et gouvernée. Les instantanés sont utiles pour préserver un travail partiel ou pour démarrer à chaud des tâches itératives. 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 un sandbox : elles extraient du code externe dans l’environnement d’exécution à l’exécution, peuvent inclure des scripts post-installation qui exécutent des commandes arbitraires et peuvent introduire des risques liés à 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 liste d’autorisation de registres (ne télécharger qu’à partir de registres ou miroirs de paquets approuvés), de caches « pull-through » (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 d’un mode hors ligne optionnel (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 un Accès Contrôlé aux Paquets pour un exemple d’implémentation pratique.
Secrets et Gestion des Identifiants
Comment les secrets et identifiants sont-ils gérés dans un 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’anti-modèle 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 d’exécution qui fournit des valeurs uniquement à un processus explicitement autorisé offre une isolation plus forte qu’une variable d’environnement plate accessible à tous les processus.
Le modèle peut-il voir les variables d’environnement injectées dans le 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 dans le 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 du démontage de la session. Si la plateforme préserve l’état entre les sessions (instantanés, volumes persistants), vérifiez que les identifiants écrits dans 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 le démontage 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 un sandbox ?
Les enregistrements d’audit utiles du sandbox incluent la création et le démontage 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 second stockage de secrets. Les fichiers clients bruts, 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 rétention 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 Revue de Sécurité
Quelle revue de conformité est nécessaire avant d’utiliser un 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 le sandbox (et ces données sont-elles soumises au RGPD, à HIPAA, à SOC 2 ou à d’autres cadres), où le sandbox est-il hébergé 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 revues de sécurité demanderont également si le code généré pourrait atteindre des bases de données de production, des surfaces d’administration internes ou des 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’un sandbox pour agent IA ?
Une liste de vérification pratique pour la revue 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 ?
- Egress : Quelle est la politique d’egress par défaut ? Les destinations sortantes peuvent-elles être mises sur liste d’autorisation ? 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 du démontage 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-ils hébergés ? 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 : Un sandbox peut-il atteindre des services de métadonnées internes, des API privées ou les ressources d’autres locataires ? Comment le mouvement latéral est-il empêché ?
Formulez ces questions comme des éléments à évaluer, pas comme 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, demandez à votre équipe de sécurité d’effectuer la revue 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 BYOC ou le déploiement VPC plutôt qu’un service géré partagé. Exécuter des sandbox dans 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 l’egress du sandbox peut être régi 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 de Novita Agent Sandbox.
Tarification du Sandbox et Facteurs de Coût
Qu’est-ce qui détermine les coûts du sandbox ?
Les coûts du sandbox sont généralement une combinaison du temps de calcul (vCPU et mémoire facturés à la seconde ou à la minute), des frais généraux de session (frais de démarrage par session sur certaines plateformes), du stockage persistant au-delà du niveau gratuit inclus et du transfert de données sortant (egress). Le poids relatif de chacun dépend de votre charge de travail : un interpréteur de code à sessions courtes est principalement du calcul ; un agent d’automatisation de navigateur qui télécharge de gros fichiers peut générer un egress important ; un espace de travail de codage persistant accumulera du stockage. La gestion des temps d’inactivité est un différenciateur majeur — les plateformes avec pause automatique cessent de facturer lorsqu’un sandbox attend une réponse LLM, ce qui peut réduire considérablement les coûts pour les flux de travail interactifs. Voir Modèles de Tarification des Sandbox pour Agents IA : Par Session, Calcul, Stockage et Egress pour une ventilation détaillée de chaque axe de tarification.
Comment le temps de session, le calcul et l’egress 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 d’egress aux tarifs typiques. Mais l’interaction est importante 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 d’egress qui éclipseront le coût de calcul. Un agent de navigateur 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 tarifé à 0,0000098 $/s. (Source : page de tarification de Novita AI, vérifié dans la documentation publiée. Vérifiez toujours les tarifs en vigueur avant la planification budgétaire.)
Auto-Hébergement vs. Sandbox Géré pour Agents IA
Quand les équipes devraient-elles s’auto-héberger plutôt que d’utiliser un sandbox géré ?
L’auto-hébergement (exécuter 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éjà d’une capacité d’ingénierie de plateforme 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 travail conséquent. Voir Firecracker pour les Sandbox d’Agents IA pour ce à quoi ressemble le périmètre opérationnel.
Quand un sandbox géré est-il plus pertinent ?
Pour la plupart des équipes construisant des agents de codage, des outils d’analyse de données, des flux de travail d’automatisation de navigateur ou des pipelines d’évaluation, un sandbox géré est la voie la plus rapide vers la production. La plateforme gère le provisionnement de l’infrastructure, le durcissement de la sécurité, les mises à jour d’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 aspects internes du sandbox. La comparaison des coûts ne se limite pas aux tarifs de calcul cloud : tenez compte du temps d’ingénierie nécessaire 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 géré vs. auto-hébergé.
Quelles questions les équipes devraient-elles poser lors de l’évaluation des fournisseurs de sandbox gérés ?
Questions d’évaluation pratiques au-delà de la tarification principale :
- Quel est le modèle d’isolation par session (microVM, conteneur, processus) ?
- Quelle est la politique d’egress 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écution Sécurisée de Code Non Fiable
Comment exécuter du code généré par l’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 exécution via un 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 une politique d’egress explicite — refus par défaut avec une liste d’autorisation 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é-configurées pour les charges de travail reproductibles ; (4) journalisez au niveau du noyau ou de l’hyperviseur plutôt que de faire confiance aux journaux de la couche application ; (5) définissez des limites de ressources — CPU, mémoire, disque et délai d’expiration absolu — afin qu’un agent incontrôlable ne puisse pas affecter les sessions adjacentes. Voir Quelle est la Sécurité du Sandbox IA pour l’Exécution de Code ? pour une liste de vérification complète.
Existe-t-il un sandbox open source pour agents IA ?
Oui. Daytona est open source sous licence AGPL et prend en charge le déploiement auto-hébergé. Le SDK de base d’E2B est open source, bien que l’infrastructure d’exécution gérée ne le soit pas. Si vous souhaitez construire votre propre sandbox à partir de zéro, l’approche la plus courante est Firecracker (développé par AWS, sous licence Apache 2.0) en tant qu’environnement d’exécution microVM, combiné à votre propre gestion d’images, orchestration et contrôle du cycle de vie. L’auto-hébergement implique d’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 ce à 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, un sandbox est provisionné et renvoyé 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 du sandbox. Les questions clés pour toute plateforme gérée sont : quel modèle d’isolation elle utilise, quelle politique d’egress est configurable, si le déploiement BYOC ou VPC est disponible et à quoi ressemble la tarification à la seconde pour votre charge de travail prévue. Voir Meilleurs Sandbox pour Agents IA en 2026 pour une comparaison structurée.
Qu’est-ce qu’un sandbox pour agent IA à usage professionnel (entreprise) ?
Les exigences des sandbox pour agents IA en entreprise dépassent généralement 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 (le sandbox s’exécute dans votre compte cloud, pas dans un locataire tiers partagé) ; la certification SOC 2 ou ISO 27001 ; une politique d’egress configurable et l’exportation des journaux d’audit vers un SIEM ; une limitation 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 sont exécutées. 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 produit avant de prendre des décisions architecturales.
