Options de bac à sable pour agents IA open source : à vérifier avant l'auto-hébergement

Les équipes qui évaluent les bacs à sable pour agents IA open source doivent d’abord vérifier la véritable frontière d’isolation, le modèle de persistance de l’espace de travail, les contrôles d’egress et de packages, la gestion des secrets, l’auditabilité et l’effort opérationnel nécessaire pour les exécuter en toute sécurité. Le bon choix dépend moins de la recherche d’un gagnant universel que de l’adéquation d’un modèle de bac à sable à votre modèle de menace, à votre charge de travail d’agent, à vos exigences de conformité et à votre capacité d’ingénierie.

Qu’est-ce qu’un bac à sable pour agent IA ?

Un bac à sable pour agent IA est un environnement d’exécution dans lequel un agent peut exécuter du code, inspecter des fichiers, automatiser un navigateur, appeler des outils ou accomplir une tâche sans obtenir un accès étendu à la machine hôte ou au réseau de production. C’est la frontière entre le raisonnement du modèle et les effets secondaires dans le monde réel.

Cette frontière est importante car les agents modernes font plus qu’écrire du texte. Un agent de codage peut cloner un dépôt, installer des dépendances, exécuter des tests, ouvrir des ports de prévisualisation et rédiger une pull request. Un agent de navigation ou de données peut exécuter des scripts, conserver un état, télécharger des fichiers et capturer des captures d’écran. Ces actions nécessitent un environnement d’exécution, et cet environnement a besoin de contrôles.

Pour une évaluation, séparez quatre couches :

Couche	Ce qu’elle détermine	Pourquoi c’est important
Framework agent	Comment le modèle planifie, appelle des outils et réagit aux résultats	Un bon framework ne crée pas automatiquement un environnement d’exécution sûr
Environnement d’exécution du bac à sable	Où s’exécutent les commandes, fichiers, sessions de navigateur et processus	C’est la principale frontière d’isolation et de cycle de vie
Plan de politique	Ce que le bac à sable peut lire, récupérer, installer, exposer ou conserver	Détermine si le bac à sable correspond à votre modèle de risque
Plan de révision	Quels journaux, diffs, artefacts et approbations sont disponibles après l’exécution	Détermine si un humain peut vérifier ce qui s’est passé

Les options auto-hébergées et open source peuvent donner aux équipes plus de contrôle sur ces couches. Elles transfèrent également plus de responsabilité à l’équipe qui les exploite.

Quand l’auto-hébergement a-t-il un sens ?

L’auto-hébergement peut être raisonnable lorsque votre équipe a besoin d’un contrôle direct sur l’emplacement de déploiement, les chemins réseau, les images de base, les règles de rétention, les systèmes de journalisation ou la révision de sécurité interne.

Il est moins attractif lorsque le véritable besoin est simplement « laisser un agent exécuter du code en toute sécurité ». Dans ce cas, un bac à sable géré peut être plus simple à exploiter car le fournisseur gère le provisionnement, la mise à l’échelle, les mises à jour de l’environnement d’exécution, la disponibilité et certaines parties de l’expérience développeur.

Utilisez l’auto-hébergement si au moins une de ces conditions est vraie :

• Votre politique exige une exécution dans un compte cloud, un VPC, une région ou un réseau privé spécifique.
• Vos agents ont besoin d’images de base personnalisées, de miroirs de packages internes, de systèmes sources privés ou de cibles de navigateur internes.
• Votre équipe de sécurité souhaite inspecter la pile d’isolation, le chemin d’egress, le modèle de rétention et les journaux.
• Vous avez la capacité d’ingénierie nécessaire pour corriger les composants de l’environnement d’exécution, surveiller les signaux d’abus, faire tourner les secrets et déboguer les échecs.

Évitez l’auto-hébergement par défaut lorsque vous ne pouvez pas assurer le travail opérationnel. Les bacs à sable semblent simples lors des démos car un seul conteneur ou VM peut exécuter une commande. La production est différente : vous avez besoin de limites de concurrence, de quotas de ressources, de nettoyage d’images, de stratégie de cache de packages, de politique réseau, de délimitation des secrets, de télémétrie, de réponse aux incidents et d’une feuille de route de mise à niveau claire.

Options de bac à sable open source à évaluer

Le paysage open source évolue rapidement, traitez donc ceci comme une orientation datée plutôt qu’une matrice de fonctionnalités permanente. Au 24 juin 2026, ces projets et outils sont des exemples utiles à inspecter lorsque vous comparez les voies de bac à sable pour agents auto-hébergées ou open source.

Option	Quoi inspecter en premier	Question d’auto-hébergement
E2B	Composants de bac à sable open source, SDK, templates et positionnement du bac à sable basé sur Firecracker	Quelles parties sont open source, quels modes de déploiement sont supportés aujourd’hui, et quel travail opérationnel reste pour votre équipe ?
Daytona	Infrastructure d’espace de travail et de bac à sable pour les cas d’utilisation de développement et d’agents IA, avec des dépôts open source et des chemins de documentation auto-hébergés	Son modèle d’espace de travail, sa surface API et son architecture de déploiement correspondent-ils à votre charge de travail d’agent et à votre politique de sécurité ?
OpenHands	Plateforme d’agent avec une architecture d’exécution documentée utilisant des environnements bacs à sable pour exécuter les actions de l’agent	Adoptez-vous la plateforme d’agent complète ou seulement le modèle d’environnement d’exécution ?
SWE-ReX	Interface d’exécution open source utilisée dans la recherche et les évaluations d’agents en génie logiciel	Son abstraction correspond-elle à vos besoins de production ou est-elle principalement utile pour des bancs d’essai d’évaluation contrôlés ?
Modal Sandbox	API de bac à sable géré plutôt qu’un environnement d’exécution open source auto-hébergé	Utile comme point de comparaison pour l’ergonomie de l’API, l’exécution des processus, le système de fichiers et le comportement de timeout, mais pas comme option auto-hébergée

Ne choisissez pas uniquement à partir d’un tableau. Pour chaque projet, lisez la documentation actuelle, examinez les dernières notes de version et exécutez une petite preuve de concept avec votre propre charge de travail. L’évaluation doit répondre : qu’est-ce qui peut s’exécuter, qu’est-ce qui est isolé, qu’est-ce qui persiste, qu’est-ce qui peut atteindre le réseau, qu’est-ce qui peut voir les secrets, et quelles preuves restent après la tâche ?

Frontière d’isolation : conteneurs, microVMs et VMs complètes

La première question n’est pas « est-ce sécurisé ? » La question utile est « quelle est la frontière d’isolation ? »

Les conteneurs sont attractifs car ils sont rapides, familiers et faciles à construire autour d’images Docker. Ils peuvent convenir aux tâches internes de confiance, aux tâches de type CI, à l’analyse de courte durée et aux workflows de développement où le modèle de menace est modéré. Mais les conteneurs partagent le noyau de l’hôte, donc les équipes qui gèrent du code non fiable ou des charges de travail multi-locataires doivent évaluer l’exposition du noyau, les profils seccomp/AppArmor, les espaces de noms utilisateur, les volumes montés, le mode privilégié et la réponse aux échappements.

Les microVMs, comme l’isolation de style Firecracker, ajoutent une frontière VM plus forte tout en maintenant le démarrage et la densité plus proches des workflows de conteneurs que des VMs traditionnelles. Elles sont courantes dans les discussions sur les bacs à sable pour agents car elles peuvent donner à chaque session un noyau séparé et une frontière de ressources plus stricte. Cela ne supprime pas le besoin de politique réseau, de contrôles de secrets, de correctifs ou de durcissement de l’hôte ; cela clarifie seulement la couche d’isolation de l’environnement d’exécution.

Les VMs complètes peuvent convenir aux environnements d’entreprise plus stricts, à l’automatisation de bureau ou aux workflows qui nécessitent une surface OS plus large. Le compromis est un démarrage plus lourd, une gestion d’images et une planification de capacité.

Posez ces questions avant l’auto-hébergement :

Vérification	Quoi vérifier
Frontière de noyau	Le bac à sable partage-t-il un noyau avec d’autres charges de travail, ou chaque session obtient-elle un noyau séparé ?
Frontière de locataire	Deux sessions client peuvent-elles partager des ressources au niveau de l’hôte, des volumes, des caches, des profils de navigateur ou des espaces de noms réseau ?
Modèle de privilège	Le bac à sable exécute-t-il des conteneurs privilégiés, des utilisateurs root, des sockets Docker montés ou des chemins hôtes ?
Posture d’échappement	Comment les vulnérabilités du noyau, de l’environnement d’exécution, du conteneur et de l’hyperviseur sont-elles corrigées et déployées ?
Contrôles des ressources	Le CPU, la mémoire, le disque, le nombre de processus, les fichiers ouverts et la durée d’exécution sont-ils appliqués par session ?
Canaux latéraux	Votre modèle de risque nécessite-t-il une atténuation pour le CPU partagé, le cache, le disque ou le comportement de voisin bruyant ?

Si un projet se décrit comme « isolé », continuez à lire jusqu’à ce que vous connaissiez le mécanisme.

État, fichiers et cycle de vie de l’espace de travail

Le travail de l’agent est avec état même lorsque le bac à sable est éphémère. L’agent peut créer des fichiers, installer des packages, conserver un profil de navigateur, exécuter des processus en arrière-plan ou faire une pause pendant qu’un humain examine un artefact. Votre bac à sable a besoin d’un modèle d’espace de travail clair.

Commencez par le cycle de vie :

1. Créez un bac à sable à partir d’une image de base ou d’un template.
2. Montez ou clonez l’espace de travail autorisé.
3. Exécutez les commandes de configuration selon la politique.
4. Laissez l’agent exécuter des commandes, des actions de navigateur et des opérations sur les fichiers.
5. Extrayez les sorties : diffs, journaux, captures d’écran, rapports ou fichiers téléchargés.
6. Arrêtez, mettez en pause, prenez un snapshot, archivez ou détruisez le bac à sable.

Le point critique est que la persistance doit être intentionnelle. Les espaces de travail persistants sont utiles pour les agents de longue durée, les tâches de codage en plusieurs étapes et la révision humaine dans la boucle. Ils sont aussi l’endroit où des identifiants obsolètes, des dépendances mises en cache, des cookies de navigateur, des données générées et un travail partiel peuvent fuir entre les sessions si le nettoyage est faible.

Avant l’auto-hébergement, définissez :

• Si chaque tâche d’agent obtient un système de fichiers frais.
• Si les caches de packages sont partagés, délimités ou reconstruits.
• Si les profils de navigateur persistent entre les exécutions.
• Si les téléchargements des utilisateurs sont copiés, montés ou diffusés en continu.
• Si les snapshots incluent des secrets, des jetons, des cookies ou des journaux internes.
• Combien de temps les journaux et les artefacts sont conservés.
• Qui peut rouvrir une session en pause.

Un bon bac à sable rend le cycle de vie par défaut ennuyeux. Vous devriez être capable d’expliquer ce qui existe avant le début de la tâche, ce qui change pendant la tâche et ce qui reste après le nettoyage.

Réseau, packages et politique d’egress

L’accès réseau est l’endroit où de nombreuses conceptions de bac à sable deviennent vagues. Les agents ont souvent besoin d’Internet, mais « accès Internet » n’est pas une seule permission.

Un agent de codage peut avoir besoin de registres de packages, de documentation publique, de dépôts Git et d’une URL de prévisualisation. Un agent de navigateur peut avoir besoin d’une application de test, d’une API de staging et d’un stockage de captures d’écran. Un agent de données peut avoir besoin de stockage d’objets, d’une réplique de base de données ou d’une API SaaS restreinte. Ce sont des permissions différentes avec des risques différents.

Utilisez des catégories :

Type d’egress	Besoin typique	Question de politique
Registres de packages	npm, pip, apt, cargo, dépendances de modèles/outils	Les registres sont-ils en liste blanche, mis en cache, scannés et journalisés ?
Web public	Consultation de documentation, tâches de navigateur, collecte de données publiques	La navigation arbitraire est-elle autorisée, proxyée, limitée en débit et auditable ?
Accès Git	Cloner des dépôts, pousser des branches, récupérer des sous-modules	Les jetons sont-ils en lecture seule lorsque possible et délimités à la tâche ?
API internes	Services de staging, applications de test, miroirs de packages privés	L’accès est-il limité par environnement, service, route et identifiant ?
Entrée de prévisualisation	Révision humaine d’applications web locales ou de rapports générés	Quel port est exposé, à qui, pour combien de temps et avec quelle authentification ?
Webhooks	Callbacks d’agent, événements CI, intégration d’outils externes	Le bac à sable peut-il envoyer des callbacks sortants vers des hôtes arbitraires ?

La politique de packages mérite une attention particulière. De nombreuses tâches d’agent échouent sans installation de dépendances, mais les installations de packages apportent des scripts post-installation, des binaires natifs, des risques de compromission de registre, des risques de typosquatting et des durées de vie de cache longues. Préférez les installations basées sur des fichiers lock, les registres approuvés, les jetons à courte durée de vie et les journaux d’installation.

Pour les systèmes auto-hébergés, décidez également qui possède les logs DNS, la configuration du proxy, les magasins de certificats de confiance et la réponse aux incidents réseau.

Secrets, journaux et pistes d’audit

Un bac à sable pour agent ne doit pas devenir un endroit où les identifiants bruts sont faciles à imprimer, copier ou exfiltrer pour le modèle.

Le modèle le plus sûr est l’accès délimité à la tâche. Donnez au bac à sable l’identifiant minimum nécessaire pour le travail et supprimez-le lorsque le travail se termine. Une tâche de codage peut nécessiter un jeton de dépôt en lecture seule et un jeton de pull request. Une tâche de navigateur peut nécessiter un compte de test, pas un utilisateur de production. Une tâche de données peut nécessiter une URL signée temporaire, pas un identifiant cloud permanent.

Évitez les secrets dans les fichiers que l’agent peut lire facilement. Les variables d’environnement sont pratiques, mais de nombreuses commandes de débogage impriment l’état de l’environnement. Si la plateforme supporte les actions mandatées, utilisez-les : laissez le bac à sable effectuer une opération étroite sans exposer l’identifiant brut à la boucle du modèle.

La journalisation doit être suffisamment solide pour la révision et la réponse aux incidents :

• Commandes demandées, approuvées, refusées et exécutées.
• Répertoire de travail, code de sortie, stdout, stderr, timeout et utilisation des ressources.
• Artefacts de fichiers produits par la tâche.
• Destinations réseau au niveau de granularité que votre politique supporte.
• Noms de packages, versions, registres et sortie d’installation.
• Décisions de masquage des secrets et échecs de masquage.
• Approbations humaines pour les actions risquées.

Le but n’est pas de noyer les réviseurs dans les journaux. Le but est de reconstruire ce qui s’est passé lorsqu’un agent produit une sortie surprenante, qu’une dépendance change ou qu’un jeton est soupçonné d’exposition.

Réinitialisation, snapshots et risque multi-locataire

Le comportement de réinitialisation est une fonctionnalité de production, pas un script de nettoyage à la fin d’une démo.

Les bacs à sable éphémères sont plus simples à raisonner : créer, exécuter, extraire des artefacts, détruire. Ils fonctionnent bien pour l’exécution de code courte, les actions de navigateur ponctuelles et les travaux d’évaluation. Les bacs à sable persistants aident pour les workflows plus longs, mais ils nécessitent des contrôles de propriété, d’expiration et de révision.

Les snapshots et les templates se situent entre ces modèles. Ils peuvent accélérer le démarrage en préservant un environnement préparé, mais ils préservent également tout ce qui se trouve à l’intérieur du snapshot. Vérifiez s’ils incluent :

• Packages installés et caches.
• Historique du shell ou état des processus.
• Cookies de navigateur, stockage local et téléchargements.
• Fichiers temporaires et sorties générées.
• Identifiants ou fichiers de configuration.
• Journaux des tâches précédentes.

Pour les systèmes multi-locataires, demandez comment le planificateur place les charges de travail, si les caches sont partagés, comment les disques sont effacés et comment les ressources au niveau de l’hôte sont surveillées. Demandez également ce qui se passe en cas de panne. Un bac à sable qui plante, expire ou perd son contrôleur a toujours besoin d’un nettoyage et d’une gestion des artefacts.

Accès développeur et chemins de débogage

Les bacs à sable auto-hébergés ont besoin d’une histoire de débogage pratique. Lorsqu’un agent échoue, les développeurs doivent savoir si le problème vient du modèle, de l’appel d’outil, de l’environnement d’exécution, de l’image, du miroir de packages, du chemin réseau ou de l’application cible.

Les chemins de débogage utiles incluent :

• Un moyen de rejouer les commandes à partir de la même image de base.
• Des journaux structurés pour l’exécution des commandes et les appels d’outils.
• Des artefacts et captures d’écran téléchargeables.
• Des erreurs explicites de timeout et de limite de ressources.
• Un moyen contrôlé pour un développeur de se connecter à une session en direct lorsque la politique le permet.
• Des templates ou images versionnés afin que les échecs puissent être liés à une version d’environnement.
• Une séparation claire entre la sortie visible par l’utilisateur et les journaux internes de l’environnement d’exécution.

Soyez prudent avec l’accès d’urgence. Un accès shell large à des bacs à sable en direct peut violer les mêmes hypothèses d’isolation que le bac à sable était conçu pour appliquer. Définissez qui peut se connecter, ce qu’ils peuvent voir, si les secrets sont masqués et comment l’accès est journalisé.

Où se situe Novita Agent Sandbox

Novita Agent Sandbox est un environnement d’exécution d’agent géré pour l’exécution de code, l’automatisation de navigateur, les workflows de type computer-use, l’analyse de données, les évaluations et les workflows d’agent de longue durée. La documentation de Novita Agent Sandbox décrit un environnement de bac à sable avec état avec des chemins SDK et CLI pour le cycle de vie, les commandes, les fichiers, les sessions de navigateur et les primitives de workflow associées.

Cela fait de Novita une solution à évaluer lorsque votre équipe souhaite une infrastructure d’exécution d’agent sans assumer l’ensemble des opérations auto-hébergées dès le premier jour.

Gardez la frontière claire :

• Utilisez des environnements d’exécution open source ou auto-hébergés lorsque le contrôle du déploiement, la personnalisation au niveau du code source ou la propriété de l’infrastructure interne sont prioritaires.
• Utilisez un bac à sable géré lorsque l’adoption plus rapide, les opérations d’environnement d’exécution gérées par le fournisseur et un workflow axé sur l’API sont plus importants que la possession de chaque couche.
• Dans les deux cas, évaluez l’isolation, l’egress, les installations de packages, les secrets, les journaux, la persistance et les portes de révision par rapport à votre propre politique.

Ne traitez aucun nom de fournisseur comme une garantie de sécurité. Traitez-le comme un choix d’environnement d’exécution qui nécessite toujours une révision architecturale.

Liste de contrôle pour l’auto-hébergement

Utilisez cette liste de contrôle avant de mettre en production un bac à sable pour agent IA open source.

Domaine	Question minimale avant la production
Isolation	La frontière est-elle un conteneur, une microVM, une VM complète ou autre chose, et est-ce suffisant pour la charge de travail ?
Espace de travail	Chaque tâche démarre-t-elle à partir d’un état de système de fichiers connu et peut-elle être réinitialisée ?
Persistance	La pause, la reprise, les snapshots et la rétention sont-ils explicites plutôt qu’accidentels ?
Réseau	Les récupérations de packages, la navigation, les appels API, Git, les webhooks et l’entrée de prévisualisation sont-ils contrôlés séparément ?
Packages	Les fichiers lock, les registres, les scripts post-installation, les binaires natifs et les caches sont-ils régis ?
Secrets	Les identifiants sont-ils délimités à la tâche, masqués, tournés et indisponibles pour les commandes non liées ?
Journaux	Un réviseur peut-il reconstruire les commandes, les sorties, les modifications de fichiers, les chemins réseau et les approbations ?
Multi-location	Le partage d’hôte, le partage de cache, le nettoyage de disque, les quotas et le comportement de voisin bruyant sont-ils compris ?
Débogage	Les ingénieurs peuvent-ils reproduire les échecs sans contourner le modèle de sécurité ?
Opérations	Qui corrige les images, les environnements d’exécution, les noyaux, les dépendances et les contrôleurs de bac à sable ?
Contrôles d’abus	Les timeouts, les limites de ressources, les limites de débit et les chemins d’arrêt sont-ils appliqués ?
Chemin de sortie	Les artefacts peuvent-ils être exportés et examinés même si le bac à sable plante ou expire ?

Si plusieurs réponses ne sont pas claires, gardez le projet dans une piste de prototype. Un bac à sable qui ne peut pas expliquer ses frontières n’est pas prêt à exécuter du travail d’agent non fiable à grande échelle.

FAQ

Quel est le meilleur bac à sable pour agent IA open source ?

Il n’existe pas de meilleur bac à sable pour agent IA open source unique pour chaque équipe. Le bon choix dépend de votre besoin d’isolation, de votre modèle de déploiement, de la charge de travail de l’agent, de votre politique d’egress, de vos besoins de persistance et de votre capacité opérationnelle. Comparez les options en exécutant votre propre tâche dans chaque environnement d’exécution candidat.

Docker est-il suffisant pour un bac à sable pour agent IA ?

Docker peut être suffisant pour l’automatisation interne de confiance, le développement local et les tâches de type CI, mais il peut ne pas être suffisant pour du code non fiable ou des charges de travail multi-locataires strictes. Vérifiez le partage de noyau, les privilèges, les volumes montés, l’accès réseau, les secrets et la réponse aux échappements avant de vous fier uniquement aux conteneurs.

Les microVMs sont-elles plus sûres que les conteneurs pour les charges de travail d’agent ?

Les microVMs peuvent fournir une frontière d’isolation plus forte car chaque bac à sable peut fonctionner avec un noyau séparé. Cela ne résout pas automatiquement l’egress, les packages, les secrets, la journalisation, les correctifs ou les opérations multi-locataires. Considérez les microVMs comme une partie de l’architecture, pas le modèle de sécurité complet.

Que dois-je tester avant d’auto-héberger un bac à sable pour agent ?

Testez une charge de travail réelle qui clone ou monte des fichiers, installe des dépendances, exécute des commandes, gère des secrets, atteint des cibles réseau approuvées, produit des artefacts, expire et se réinitialise. Testez également les chemins d’échec : échec d’installation de package, plantage du navigateur, refus réseau, limite de ressources et nettoyage du bac à sable après une erreur de contrôleur.

Quand dois-je utiliser un bac à sable géré plutôt que l’auto-hébergement ?

Utilisez un bac à sable géré lorsque votre équipe souhaite l’API d’exécution d’agent et les artefacts de révision sans posséder les correctifs de l’environnement d’exécution, la mise à l’échelle, la planification de capacité et les opérations d’infrastructure. Auto-hébergez lorsque le contrôle du déploiement ou la personnalisation au niveau du code source est suffisamment important pour justifier ce travail.

Articles recommandés

• Exécutez Codex ou un agent de codage dans un bac à sable sécurisé
• Comment les bacs à sable pour agents propulsent une innovation IA sécurisée et évolutive
• Construire un agent de codage avec le bac à sable pour agents de Novita