AI sandbox : les 7 meilleurs outils de sécurité en 2026

En 2026, Vercel Sandbox est la meilleure AI sandbox pour la plupart des équipes qui déploient des agents dans le cloud. Mais l’écart déterminant n’est pas celui du prix : pour la charge de référence retenue ici, les solutions managées vont de $55.55 à $288 par mois. Le vrai critère de mise en production consiste à vérifier que le code généré par le modèle dispose à la fois de son propre noyau d’exécution et d’un chemin de sortie qui n’expose jamais les identifiants actifs.

AI sandbox : le classement en un coup d’œil

Les prix et les limites des produits ci-dessous ont été vérifiés le 19 août 2026. Ces sept outils couvrent aussi bien les agents de code locaux que les agents managés dans le cloud, deux usages qui n’obéissent ni au même modèle de risque ni au même modèle de coût.

Ce classement n’est volontairement pas trié du moins cher au plus cher. Northflank affiche la facture cloud managée modélisée la plus basse, à $55.55. Vercel arrive néanmoins en tête : sa barrière Firecracker, sa politique de sortie modifiable à chaud et son courtage d’identifiants offrent un socle plus net à une équipe produit qui veut livrer un agent sans administrer de cluster. Docker prend la deuxième place grâce à une isolation locale particulièrement complète, sans frais fournisseur ; ce n’est toutefois pas un runtime managé destiné aux tâches exposées aux clients.

La règle de décision tient en une phrase : choisissez l’outil le moins cher qui franchit les deux barrières indispensables pour votre charge réelle. La première maintient le code non fiable derrière un noyau distinct, ou une barrière d’appels système d’une solidité comparable. La seconde garde les secrets de production et les autorisations de sortie hors de portée de ce code. Une VM bon marché dans laquelle on place une clé API en clair échoue au test. Une VM bien isolée, mais libre de communiquer avec tout Internet, échoue elle aussi.

Comment ces outils ont-ils été sélectionnés ?

OpenAI recommande désormais aux responsables sécurité d’exécuter les workflows à haut risque sans accès aux systèmes de production sensibles ni à l’Internet ouvert, de tester régulièrement les barrières des sandboxes, de surveiller les actions des agents et de définir précisément leur périmètre autorisé. Les recommandations de l’Agents SDK sont encore plus directes : il faut partir du principe que les injections de prompt et les tentatives d’exfiltration auront lieu, séparer l’orchestration du calcul et tenir les identifiants à l’écart de l’environnement où s’exécute le code généré. Il s’agit de consignes d’exploitation, pas de scénarios théoriques. OpenAI a publié ces recommandations le 10 août.

C’est la base du test des deux barrières appliqué à chacun des verdicts :

1. Barrière d’exécution : chaque tâche hostile dispose-t-elle de son propre noyau, d’une microVM, d’une VM ou d’une isolation documentée des appels système ? Le processus ou le système de fichiers d’un utilisateur peut-il atteindre ceux d’un autre ?
2. Barrière de sortie et d’identifiants : peut-on bloquer le réseau par défaut, n’autoriser que des destinations nommées et injecter les identifiants une fois le trafic sorti de la sandbox ?
3. Barrière de contrôle : les politiques, journaux, quotas et identités peuvent-ils rester hors du code que le modèle est susceptible de réécrire ?
4. Adéquation opérationnelle : le produit est-il local, piloté d’abord par API, conçu pour l’edge, orienté GPU ou constitue-t-il une plateforme complète ? Une bonne barrière dans un mauvais modèle d’exploitation finit inutilisée.
5. Coût récurrent : combien coûte exactement la même charge une fois le crédit promotionnel épuisé ?

Ce comparatif chiffre et analyse les solutions ; il ne prétend pas constituer un test d’intrusion. Chaque prix, limite et fonctionnalité provient d’une page officielle consultée en direct. Pour être retenu, un produit devait fournir assez d’informations de première main pour évaluer à la fois l’isolation et les sorties réseau, et proposer une véritable barrière contre du code hostile plutôt qu’un simple environnement de développement.

La charge normalisée correspond à 10,000 exécutions par mois. Chacune dure 5 minutes, demande 2 vCPU et 4 GiB de mémoire, avec 1 minute de CPU actif puis 4 minutes d’attente consacrées aux fichiers, aux paquets ou au réseau. Cette différence compte : Vercel et Cloudflare facturent le CPU actif séparément de la mémoire provisionnée, tandis que E2B, Daytona, Northflank et Modal facturent le calcul pendant toute la fenêtre d’exécution.

Le travail des agents modernes recouvre deux réalités distinctes. Si l’assistant de code tourne sur un ordinateur portable, comparez-le aux workflows présentés dans Codex vs Claude Code vs Cursor. Si l’agent pilote un navigateur, la session du navigateur entre elle-même dans le périmètre d’isolation, comme l’explique le comparatif des meilleurs navigateurs pour agents IA. Une sandbox ne remplace pas le choix du bon agent ; un agent performant ne dispense pas non plus d’isoler ses outils.

1. Vercel Sandbox : la meilleure AI sandbox pour les équipes cloud

Vercel Sandbox est le meilleur choix global pour une équipe produit qui cherche une API managée, une solide barrière de calcul et des secrets qui n’ont pas à pénétrer dans le code généré.

Chaque sandbox s’exécute dans une microVM Firecracker. Les environnements intégrés couvrent Node.js 22, 24 et 26 ainsi que Python 3.13 ; une image OCI permet d’utiliser un runtime personnalisé. Les sessions Pro et Enterprise peuvent durer jusqu’à 24 heures, contre 45 minutes pour Hobby. Le plafond de ressources passe de 4 vCPU sur Hobby à 8 sur Pro et 32 sur Enterprise. La mémoire étant fixée à 2 GB par vCPU, la charge à 2 vCPU de ce comparatif reçoit exactement 4 GB.

L’avantage de sécurité se révèle après le démarrage de la VM. Le pare-feu réseau de Vercel peut modifier sa politique pendant l’exécution, injecter un identifiant uniquement au moment où une requête sortante quitte la sandbox et faire transiter certaines requêtes par votre propre proxy. On peut ainsi organiser une tâche sûre en deux phases : ouvrir le registre de paquets pendant la préparation, supprimer l’accès large, puis lancer le code généré par le modèle avec une courte liste de destinations. La sandbox obtient les outils nécessaires sans hériter des clés servant à appeler GitHub, une API de modèle ou un stockage objet.

Le point faible relève de la configuration, pas de l’isolation. La documentation du pare-feu Vercel indique que allow-all est le réglage par défaut : une nouvelle sandbox dispose donc d’un accès sans restriction à l’Internet public. Le schéma de configuration de Vercel consiste à installer les paquets avec un accès large, puis à passer sur une liste d’autorisation définie par l’utilisateur avant d’exécuter le code non fiable. Si l’orchestrateur omet cette seconde étape, Firecracker protège toujours l’hôte, mais la sandbox peut exfiltrer tout ce qu’on lui a confié. Le courtage empêche l’invité de copier une clé en clair ; il ne peut pas empêcher le code généré d’abuser de cette clé au moyen d’une requête autorisée pendant que la tâche est active.

La mise à jour d’observabilité du 7 juillet transforme cette politique en contrôle opérationnel. Les équipes peuvent suivre le CPU actif, la mémoire provisionnée, le transfert de données, les sandboxes en cours et les sessions, puis regrouper les métriques par Sandbox Name et Sandbox Session ID. Vercel inclut l’observabilité de Sandbox dans toutes ses offres, avec des requêtes manuelles sur Pro et Enterprise. L’effet budgétaire est concret : étiquetez chaque type de tâche, attribuez-lui ses dépenses et examinez toute session dont les sorties ou la durée s’éloignent de leur profil habituel.

Idéal pour : agents de code managés, interpréteurs de code, générateurs de prévisualisations et exécutions destinées aux clients sur une stack Vercel.
Point fort : Firecracker, politique de sortie à chaud, courtage d’identifiants et proxy de requêtes optionnel réunis dans un seul produit.
Tarifs : Hobby est à $0. Pro coûte $20/mois avec $20 de crédit d’usage inclus, puis $0.128 par heure de CPU actif, $0.0212 par GB-heure de mémoire provisionnée, $0.60 par 1 million de créations, $0.15 par GB de réseau et $0.08 par GB-mois de snapshots. Enterprise est sur devis.
Essai gratuit : Hobby comprend 5 heures de CPU actif, 420 GB-heures de mémoire, 5,000 créations, 20 GB de réseau, 10 sandboxes simultanées et 15 GB de stockage de snapshots. Un essai Pro est proposé.

Déployer Vercel en toute sécurité, étape par étape

1. 1

   Formaliser le modèle de menace

   Listez ce que le code généré peut lire, écrire, appeler et exposer. Par défaut, les identifiants du dépôt, les bases de données de production, les métadonnées cloud et les API d’administration internes doivent rester hors de la sandbox.

2. 2

   Construire une image propre

   Partez d’un runtime intégré ou d’une image OCI limitée aux outils nécessaires à la tâche. N’intégrez aucune donnée client ni aucun identifiant de longue durée dans l’image ou dans un snapshot.

3. 3

   Ouvrir brièvement les sorties de préparation

   N’autorisez que le registre de paquets, l’hôte source ou le dépôt d’artefacts requis pendant la préparation. Si un accès large est provisoirement indispensable, faites du changement de politique une étape explicite de l’orchestration, et non une convention informelle.

4. 4

   Fermer le réseau

   Avant le démarrage du code généré, basculez vers des destinations nommées et refusez tout le reste. Faites passer les appels à haut risque par votre proxy lorsqu’une politique stable l’exige.

5. 5

   Intermédier chaque secret

   N’injectez un identifiant que pour l’hôte et la forme de requête approuvés. Ne copiez jamais la valeur brute dans une variable d’environnement sous prétexte que la microVM est isolée.

6. 6

   Observer puis détruire

   Diffusez les journaux, plafonnez la durée et les ressources, ne conservez que le résultat utile, puis détruisez la sandbox. Planifiez un test qui tente de joindre un hôte bloqué et de récupérer une clé intermédiée.

Verdict : Vercel est le choix par défaut pour réduire au minimum les décisions d’infrastructure sans sacrifier la robustesse de l’isolation. Préférez une autre solution si l’exécution locale, votre propre cloud ou des GPU avancés constituent le besoin le plus contraignant.

2. Docker Sandboxes : le meilleur choix pour les agents de code locaux

Docker Sandboxes est ici la solution locale la plus solide, car il s’agit d’un véritable produit à base de microVM et non d’un conteneur classique simplement rebaptisé de façon rassurante.

La microVM constitue la principale frontière de confiance. Chaque sandbox possède un noyau distinct, son propre Docker Engine et aucun chemin vers le daemon Docker de l’hôte. Les connexions TCP sortantes passent par un proxy côté hôte régi par une politique de refus par défaut ; le trafic UDP et ICMP direct vers l’extérieur est bloqué, et les identifiants d’API peuvent être injectés dans les en-têtes HTTP sans que leur valeur brute soit placée dans la VM. C’est une architecture locale sérieuse pour des sessions autonomes avec Codex, Claude Code, Copilot CLI, OpenCode ou Kiro.

Le prix fournisseur est tout aussi limpide : la CLI sbx coûte $0, ne comporte aucun frais par utilisateur et peut servir à un usage commercial. La gouvernance centralisée de l’organisation — notamment les politiques managées pour le réseau, le système de fichiers et MCP, ainsi que les journaux d’audit — nécessite un abonnement payant distinct. Le coût réel du calcul est reporté sur le portable ou la station de travail. La bonne comparaison n’oppose donc pas les $0 de Docker aux $55.55 de Northflank, mais le matériel local et le temps d’exploitation à un service managé.

La faiblesse apparaît précisément à la jonction entre le travail local et l’hôte. Le mode direct monte le workspace en lecture-écriture : un agent peut alors modifier les hooks Git, la configuration CI, les tâches de l’IDE, les cibles de Makefile, les scripts de paquets et d’autres fichiers qu’un développeur exécutera ensuite hors de la VM. Avec --clone, le dépôt de l’hôte devient accessible en lecture seule et l’agent travaille dans une copie privée ; c’est le choix le plus sûr pour les dépôts inconnus ou les exécutions autonomes. Docker avertit aussi que de larges domaines avec joker peuvent rester dans la liste d’autorisation par défaut, que les skills partagés forment un espace en lecture-écriture commun à plusieurs sandboxes sauf désactivation, et que les serveurs MCP locaux en stdio s’exécutent sur l’hôte plutôt que dans la microVM.

Docker Sandboxes 0.38.0 est sorti le 6 août avec Kit spec v2, une gestion MCP de premier plan, des identifiants OAuth conservés sur l’hôte, des politiques Cedar à l’échelle de l’organisation et un contrôle --deny-network HOST par sandbox. Cette version corrige également CVE-2026-17106. La conséquence n’est pas de brandir la note de version, mais d’adopter une règle de maintenance : les logiciels d’isolation locale doivent suivre un calendrier de mise à jour imposé, et toute nouvelle surface MCP centralisée exige la même analyse de confiance dans l’hôte que les autres passerelles sortant de la VM.

Docker Sandboxes excelle donc sur un poste de développement, mais convient mal comme backend cloud prêt à l’emploi. Il protège la station de travail de la plupart des actions de l’agent ; le workspace, les skills partagés et les intégrations MCP côté hôte restent toutefois des passerelles explicites, à examiner une par une.

Idéal pour : agents de code locaux qui doivent installer des paquets, construire des images Docker et fonctionner sans supervision sans obtenir un accès large à l’hôte.
Point fort : isolation par microVM, réseau intermédié et bloqué par défaut, injection d’identifiants côté hôte, le tout avec $0 de frais fournisseur.
Tarifs : $0 pour la CLI, sans frais par utilisateur ; la gouvernance de l’organisation est proposée sur devis.
Essai gratuit : la CLI principale et les sandboxes locales isolées sont gratuites.

Verdict : utilisez Docker Sandboxes pour les agents locaux, activez le mode clone pour les travaux risqués, réduisez les règles réseau trop larges et considérez chaque serveur MCP de l’hôte comme privilégié. Ne le comparez aux API managées qu’après avoir chiffré le matériel et l’exploitation qu’il remplace.

3. Cloudflare Sandbox SDK : le meilleur choix edge avec politiques intégrées

Cloudflare Sandbox SDK est le choix le plus cohérent lorsque le plan de contrôle réside déjà dans Workers et que l’agent doit disposer d’un accès à Internet étroitement programmé.

Cloudflare Containers exécute chaque sandbox dans une VM distincte, avec isolation du système de fichiers, des processus et du réseau, ainsi que des quotas de ressources propres à chaque sandbox. La page de sécurité est très claire sur l’architecture multitenant : au sein d’une même sandbox, les processus partagent les fichiers, les processus et le réseau localhost ; il faut donc créer une sandbox séparée pour chaque utilisateur. Cette précision vaut davantage qu’une vague promesse d’isolation complète, car elle indique exactement où placer la limite d’identité.

La deuxième barrière prolonge naturellement Workers. L’accès à l’Internet public est autorisé par défaut, mais enableInternet = false inverse la posture : tout est refusé, sauf ce que allowedHosts ou un gestionnaire de sortie autorise. Ce gestionnaire tourne dans le runtime Workers de confiance, hors de la sandbox ; il peut injecter un en-tête d’autorisation et limiter un identifiant à une instance précise. L’invité ne reçoit jamais le véritable token. Quand Internet est désactivé, le trafic non HTTP est refusé et les requêtes DNS ne peuvent utiliser que les serveurs de Cloudflare, ce qui ferme une voie d’exfiltration évidente.

Les deux réserves assumées concernent l’exposition et la maturité. Un tunnel rapide emploie un nom d’hôte aléatoire en trycloudflare.com sans token d’accès distinct : toute personne connaissant l’URL peut le joindre. Une prévisualisation sensible exige donc toujours une authentification applicative. La vue d’ensemble mise à jour le 13 août recommande @cloudflare/sandbox@next pour les nouveaux projets et présente le SDK 1.0 comme une preview. Cela peut convenir à un produit naissant dont le rayon d’impact est limité. Un acheteur réglementé, soumis à une politique de dépendances stables uniquement, devra peut-être attendre ou épingler le paquet stable actuel au prix de fonctionnalités plus restreintes.

Les tailles d’instance fixes de Cloudflare modifient également la comparaison tarifaire. La tâche normalisée demande 2 vCPU et 4 GiB, mais la plus petite instance qui y répond est standard-3, avec 2 vCPU, 8 GiB et 16 GB de disque. Le faible tarif mémoire de la plateforme reste compétitif, même si la moitié de la mémoire provisionnée est inutilisée dans cet exemple.

Idéal pour : agents basés sur Workers, applications edge, terminaux dans le navigateur, contextes de code et charges principalement HTTP avec sorties programmables.
Point fort : la logique des identifiants et des sorties peut rester dans Workers, hors de la sandbox, avec un périmètre défini par destination et par instance.
Tarifs : Workers Free n’inclut ni Containers ni Sandbox SDK. Workers Paid coûte $5/mois et comprend 375 minutes-vCPU, 25 GiB-heures de mémoire et 200 GB-heures de disque. L’usage supplémentaire coûte $0.000020 par seconde-vCPU, $0.0000025 par seconde-GiB et $0.00000007 par seconde-GB de disque.
Essai gratuit : aucun essai Sandbox dédié ; Containers exige Workers Paid.

Verdict : Cloudflare est la meilleure alternative à Vercel lorsque Workers sert déjà de couche de contrôle de confiance et que la politique HTTP constitue le levier principal. Commencez par couper Internet, ajoutez une authentification applicative à chaque tunnel et budgétez les tailles fixes des instances.

4. E2B : la meilleure API de microVM pour des runtimes d’agents portables

E2B est l’option microVM centrée sur les API la plus spécialisée pour les équipes qui veulent une sandbox d’agent indépendante d’une plateforme de déploiement plus vaste.

Chaque sandbox E2B tourne dans une microVM Firecracker avec son propre noyau, sa propre mémoire et son propre cache de pages. La présence d’un noyau distinct est essentielle : une faille du noyau dans un invité doit encore parvenir à s’échapper de Firecracker pour atteindre l’hôte. Le SDK v2.0.0 et les versions ultérieures activent aussi par défaut un accès sécurisé au contrôleur ; les appels à ce dernier doivent présenter le token d’accès renvoyé lors de la création de la sandbox. Il peut être nécessaire de reconstruire d’anciens templates personnalisés pour qu’ils fonctionnent avec cette posture.

L’API propose les primitives réseau attendues : allow_internet_access, allowOut, denyOut et un proxy de sortie. Désactiver l’accès à Internet revient à refuser 0.0.0.0/0. Ces contrôles sont visibles dans la requête de création actuelle, mais les pages produit citées ne présentent pas de courtier d’identifiants de premier plan comparable à ceux de Vercel, Cloudflare, Daytona ou Docker. Si le code généré doit utiliser un token de production, placez un proxy de confiance hors d’E2B et injectez-y l’identifiant, plutôt que de le transmettre dans une variable d’environnement de l’invité.

E2B devient plus séduisant lorsque la maîtrise du déploiement représente l’exigence principale. Le BYOC Enterprise prend actuellement en charge AWS et GCP ; l’entreprise indique que les templates, snapshots, journaux du runtime et flux sensibles restent dans le VPC du client. La proposition est moins avantageuse si l’acheteur veut une instance personnalisée de 4 GiB à bas prix : la page tarifaire réserve la personnalisation du CPU et de la RAM à Pro, qui ajoute $150/mois avant même l’usage.

Hobby est généreux pour l’évaluation. L’offre coûte $0 plus l’usage, inclut un crédit unique de $100, ne demande aucune carte, autorise des sessions allant jusqu’à 1 heure et prend en charge 20 sandboxes simultanées. Pro porte les sessions à 24 heures et le nombre de sandboxes simultanées à 100, avec de la capacité supplémentaire achetable jusqu’à 1,100. Le passage à l’offre supérieure relève les limites, mais ne crée pas de crédit d’usage récurrent.

Idéal pour : agents pilotés d’abord par API, interpréteurs de code, charges d’évaluation et entreprises qui ont besoin du BYOC sur AWS ou GCP.
Point fort : un noyau Firecracker propre à chaque sandbox derrière une API simple et dédiée aux agents.
Tarifs : Hobby est à $0 plus l’usage. Pro coûte $150/mois plus l’usage. Enterprise ajoute un prix de base sur devis à l’usage. Le CPU coûte $0.000014 par seconde-vCPU, soit $0.0504 par heure-vCPU, et la mémoire $0.0000045 par seconde-GiB, soit $0.0162 par heure-GiB. Le stockage inclut 10 GiB sur Hobby et 20 GiB sur Pro.
Essai gratuit : un crédit d’usage unique de $100 sur Hobby, sans carte bancaire.

Verdict : E2B est l’API de microVM indépendante la plus lisible du groupe. Choisissez-la lorsque la portabilité ou le BYOC pèse davantage que le prix de base de Pro, et intégrez dès l’architecture un proxy d’identifiants externe de confiance plutôt que de le traiter comme un durcissement ultérieur.

5. Daytona : le meilleur proxy d’identifiants avec plusieurs classes de runtime

Daytona propose le courtier d’identifiants le plus clairement documenté de ce comparatif, ainsi qu’un choix entre des conteneurs rapides par défaut et des VM Linux ou Windows dédiées.

L’architecture des secrets est particulièrement concrète. Daytona stocke un identifiant d’organisation chiffré, ne place qu’un substitut opaque dans la sandbox, puis remplace ce dernier par la valeur réelle dans l’en-tête d’une requête HTTPS sortante au niveau de son proxy. Celui-ci n’envoie la valeur qu’à un hôte autorisé et expurge de la réponse tout secret qui y serait repris avant qu’elle ne parvienne à l’invité. Le code généré peut ainsi utiliser un token sans jamais pouvoir le lire.

Cette conception comporte une désactivation dangereuse : si le champ hosts d’un secret est omis, celui-ci devient libre de toute restriction et le proxy peut remplacer le substitut par la valeur réelle pour n’importe quelle destination. La documentation recommande de définir une liste d’autorisation pour chaque secret. La substitution ne fonctionne en outre que dans les en-têtes HTTPS, pas dans le corps des requêtes, les paramètres de requête, le HTTP en clair ou les valeurs transformées, comme une authentification Basic encodée en Base64. Si un fournisseur n’accepte sa clé que dans le corps, le courtier Daytona ne peut pas protéger cet appel.

Les contrôles réseau couvrent les listes d’autorisation par domaine et par CIDR, le blocage complet des sorties et le recours à un proxy en amont. Les restrictions d’organisation Tier 1 et Tier 2 priment et ne peuvent pas être assouplies au niveau d’une sandbox. Tier 3 et Tier 4 autorisent par défaut un accès Internet complet, qu’il faut resserrer pour les tâches hostiles. La question utile pour l’acheteur n’est pas de savoir si Daytona prend en charge les listes d’autorisation, mais si la combinaison du niveau d’organisation et de la configuration de la sandbox produit effectivement la politique prévue.

Le choix du runtime est l’autre caractéristique déterminante. Les conteneurs Linux constituent l’option par défaut et démarrent rapidement. Daytona propose également des classes dédiées de VM Linux et Windows, ainsi que des sandboxes GPU avec H100, H200, RTX PRO 6000, RTX 5090 et RTX 4090. Pour des builds de confiance, la vitesse des conteneurs peut représenter le bon compromis. Pour du code hostile en environnement multitenant, sélectionnez délibérément une VM au lieu de croire que le mot sandbox garantit à lui seul la barrière la plus forte.

Idéal pour : agents qui doivent appeler des API externes sans voir leurs identifiants, charges mixtes Linux et Windows, et exécution sur GPU.
Point fort : secrets substitués, injection HTTPS limitée aux hôtes autorisés et nettoyage des réponses, le tout hors de l’invité.
Tarifs : le service public est à $0 de base avec paiement à l’usage. Le CPU coûte $0.0504 par heure-vCPU, la mémoire $0.0162 par heure-GiB et le stockage $0.000108 par heure-GiB au-delà des 5 premiers GiB. Le calcul géré par le client passe par le service commercial.
Essai gratuit : $200 de calcul gratuit, sans carte bancaire.

Verdict : Daytona est le meilleur choix lorsque l’acheminement sûr des secrets est plus difficile que la création des sandboxes. Définissez toujours hosts, choisissez une VM pour du code réellement hostile en environnement multitenant et intégrez le niveau réseau effectif de l’organisation à la revue de lancement.

6. Northflank : le meilleur choix pour le BYOC et la maîtrise de la plateforme

Northflank s’impose lorsque la sandbox doit résider dans votre compte cloud et s’intégrer à une plateforme applicative plus large qui réunit services, bases de données, tâches et politiques.

Northflank propose des microVM Kata Containers ou gVisor pour isoler les charges avec une robustesse de niveau VM. Sa page d’infrastructure actuelle indique que chaque conteneur reçoit son propre noyau, entouré de barrières de namespace, de ressources, de stockage et de réseau. Un service mesh ajoute un chiffrement TLS mutuel entre les charges, tandis que les politiques réseau au niveau des projets et le réseau privé réduisent les accès involontaires entre projets.

Sa surface de déploiement est plus vaste que celle de tous les runners pilotés d’abord par API étudiés ici. Northflank peut fonctionner dans son cloud managé ou se connecter à des comptes AWS, GCP, Azure ou Civo ; il prend aussi en charge le Kubernetes du client, sur site, sur matériel nu ou dans un cloud public. Dans les pools de nœuds BYOC compatibles microVM, les charges reçoivent cette isolation par défaut. C’est un bon choix pour la résidence des données, les contrats cloud existants, l’accès aux services privés et les équipes d’entreprise qui veulent gouverner ensemble l’infrastructure applicative et celle des sandboxes.

Cette amplitude constitue également sa faiblesse. Un petit produit d’agents n’a pas nécessairement besoin de clusters, de projets, d’un service mesh, de templates de déploiement, de bases de données et d’un plan de contrôle de plateforme. Northflank peut afficher l’estimation de ressources la plus basse de ce comparatif tout en coûtant davantage à l’organisation si personne ne porte la plateforme. Le bon acheteur recherche déjà le BYOC ou l’ensemble de la plateforme. Les autres doivent confronter le temps d’ingénierie requis à Vercel ou E2B avant de se réjouir du tarif unitaire.

L’offre Sandbox gratuite permet de découvrir la plateforme avec 2 services gratuits, 1 base de données gratuite et 2 tâches cron gratuites. Le calcul de production est facturé à la seconde, à $0.01667 par heure-vCPU et $0.00833 par heure-GB. Les sorties coûtent $0.06 par GB et le stockage SSD $0.15 par GB-mois.

Idéal pour : BYOC, services privés, exigences de résidence des données et équipes qui souhaitent réunir sandboxes et infrastructure applicative sur une seule plateforme.
Point fort : isolation Kata ou gVisor dans des déploiements cloud managés ou appartenant au client.
Tarifs : Sandbox est gratuit. Le paiement à l’usage démarre à $0/mois, puis facture $0.01667 par heure-vCPU, $0.00833 par heure-GB de mémoire, $0.06 par GB de sortie et $0.15 par GB-mois de SSD. Enterprise est sur devis.
Essai gratuit : une offre Sandbox gratuite avec 2 services, 1 base de données et 2 tâches cron.

Verdict : Northflank est la bonne réponse lorsque le placement dans votre propre cloud ou une plateforme unifiée est incontournable. Ce n’est pas automatiquement une bonne affaire pour une équipe produit de deux personnes : le compteur le plus bas peut malgré tout créer le chantier de plateforme le plus lourd.

7. Modal : le meilleur choix pour Python, le ML et les charges GPU intensives

Modal est la meilleure sandbox de ce comparatif lorsque le code généré côtoie Python, des notebooks, l’inférence de modèles ou des charges GPU intermittentes.

Modal Sandboxes utilise gVisor, qui intercepte et restreint les appels système entre la charge invitée et le noyau de l’hôte. Par défaut, une Sandbox ne peut ni accepter de connexion réseau entrante ni accéder aux autres ressources Modal. Son rayon d’impact au sein de la plateforme est donc limité, ce qui en fait une bonne primitive d’exécution pour l’analyse de données et les tâches à forte composante modèle.

La politique de sortie est moins conservatrice. Par défaut, les sandboxes peuvent joindre n’importe quelle IP publique. Modal prend en charge un blocage réseau total, des listes d’autorisation CIDR et une liste d’autorisation de domaines en beta pour le trafic TLS, mais ces contrôles doivent être activés. Modifier la politique pendant l’exécution impose aussi une condition lors de la préparation : pour resserrer ultérieurement une liste de domaines ou de CIDR, la sandbox doit avoir été créée avec cette catégorie de liste activée. block_network=True ne peut pas être modifié par le même mécanisme dynamique ; le cycle de vie d’un agent qui n’ouvre le réseau que pendant la préparation doit donc être conçu à l’avance.

L’intérêt économique de Modal tient à la plateforme ML serverless qui l’entoure, pas au compteur de sandbox le moins cher. Un cœur physique équivaut à 2 vCPU et coûte $0.00003942 par seconde-cœur. La mémoire coûte $0.00000667 par seconde-GiB. Starter coûte $0 plus le calcul, inclut $30 de crédit mensuel, 3 utilisateurs dans le workspace et une capacité de 100 conteneurs et 10 GPU simultanés. Team coûte $250/mois plus le calcul, restitue $100 de crédit mensuel et ajoute un nombre illimité d’utilisateurs, une capacité de 5,000 conteneurs et 50 GPU simultanés, un proxy à IP statique, des budgets par environnement, des domaines personnalisés et des retours arrière de déploiement.

Modal se justifie donc facilement lorsque la même plateforme sert aussi les modèles, les fonctions planifiées et les tâches GPU. Le choix est plus difficile à défendre pour un simple interpréteur de code dont les besoins principaux sont l’isolation par microVM et le courtage d’identifiants. La page actuelle sur la sécurité de Sandbox documente le contrôle réseau et l’isolation au sein de la plateforme, mais pas un mécanisme externe d’injection de secrets aussi explicite que celui de Daytona ou Cloudflare.

Idéal pour : agents Python, notebooks, analyse de données, pipelines ML et exécution de code généré fortement dépendante des GPU.
Point fort : des Sandboxes gVisor intégrées à la plateforme serverless CPU et GPU de Modal.
Tarifs : Starter est à $0 plus le calcul, avec $30 de crédit mensuel. Team coûte $250/mois plus le calcul, avec $100 de crédit mensuel. Enterprise est sur devis. Le CPU Sandbox coûte $0.00003942 par seconde-cœur physique, sachant que 1 cœur équivaut à 2 vCPU, et la mémoire $0.00000667 par seconde-GiB.
Essai gratuit : $30 de crédit Starter mensuel récurrent.

Verdict : Modal l’emporte lorsque la sandbox n’est qu’un composant d’un système ML ou GPU. Pour une simple API d’exécution de code hostile, Vercel, Cloudflare, E2B ou Daytona offrent aux responsables sécurité un chemin plus direct.

Ce que révèle vraiment la facture mensuelle

L’estimation managée la moins chère s’établit à $55.55 et la plus élevée à $288, soit $232.45 d’écart par mois. La différence compte à grande échelle, mais elle pèse peu face au coût d’un ingénieur chargé de maintenir un runner interne ou d’un incident causé par la fuite d’un token de production. Du point de vue de la sécurité, économiser une petite somme mensuelle à trois chiffres ne justifie ni des secrets en clair ni des sorties réseau ouvertes.

Il s’agit d’estimations comparatives, pas de factures. Pour Vercel, le calcul suppose que les $20 de base de Pro sont compensés par les $20 de crédit d’usage inclus. Cloudflare doit allouer une instance standard-3 de 8 GiB avec un disque de 16 GB pour satisfaire la demande de 2 vCPU. E2B inclut l’offre Pro à $150, car la comparaison utilise une allocation personnalisée de 4 GiB. Modal déduit le crédit Starter récurrent de $30. Les $200 de Daytona et les $100 d’E2B sont des crédits uniques ; ils ne réduisent donc pas le coût en régime permanent indiqué dans le tableau.

Le mode de facturation peut inverser l’ordre. Vercel et Cloudflare facturent le CPU actif : l’agent paie moins lorsqu’il attend des entrées-sorties. Si le CPU travaille durant les 5 minutes complètes, Vercel passe de $113.34 à $284.01 et Cloudflare de $91.63 à $187.63. Un agent de code qui compile beaucoup doit modéliser ce scénario chargé. Un agent de navigation en attente du rendu des pages se rapprochera peut-être davantage de l’hypothèse à 1 minute.

Dans ce modèle, le seuil pratique entre Vercel et Daytona se situe à 1.58 minute de CPU actif sur une exécution de 5 minutes, soit environ 95 secondes. En dessous, la facturation au CPU actif de Vercel est gagnante ; au-dessus, le tarif fondé sur la durée d’exécution de Daytona devient moins cher, avant réseau et stockage. C’est une décision de workflow déguisée en question de prix : mesurez la durée réelle de calcul de l’agent au lieu de déduire le budget de la seule durée écoulée.

Le poste budgétaire le plus lourd reste la responsabilité opérationnelle. L’estimation de $55.55 de Northflank paraît remarquable jusqu’à ce que l’équipe ajoute un cluster, les politiques, les templates de déploiement, la réponse aux incidents et un ingénieur capable de maîtriser l’ensemble. Les $288 d’E2B semblent élevés jusqu’à ce que le BYOC évite de bâtir une plateforme séparée. Un achat sérieux compare la charge totale d’exploitation, pas seulement le prix du vCPU.

Quelle AI sandbox choisir selon votre besoin ?

Choisissez Vercel Sandbox si vous voulez le meilleur socle managé par défaut et acceptez de durcir sa politique réseau avant la phase non fiable. Le choix bascule ailleurs si le BYOC, l’exécution locale ou des GPU avancés sont obligatoires.

Choisissez Docker Sandboxes lorsqu’un développeur utilise Codex, Claude Code, Copilot CLI, OpenCode ou Kiro en local. Activez le mode clone pour les dépôts risqués. Passez à un outil managé dès que les exigences incluent des tâches client, de nombreuses exécutions simultanées, une disponibilité centralisée ou des API distantes.

Choisissez Cloudflare Sandbox SDK si Workers constitue déjà le plan de contrôle de confiance et si la majorité des appels approuvés passent par HTTP. La décision s’inverse lorsque la maturité pré-1.0 du SDK ou les tailles fixes de Containers créent davantage de risques qu’elles n’en éliminent.

Choisissez E2B pour obtenir une API Firecracker indépendante ou le BYOC sur AWS et GCP. Préférez autre chose si la personnalisation de la mémoire rend le socle Pro à $150 difficile à justifier, ou si vous ne voulez pas construire un proxy d’identifiants externe.

Choisissez Daytona lorsque l’agent doit appeler des services externes avec un secret qu’il ne peut pas lire, ou lorsque des classes VM Linux, VM Windows et GPU doivent cohabiter derrière une seule API. Une simple microVM Linux pour toutes les charges ne tire pas parti de ces choix de runtimes supplémentaires.

Choisissez Northflank si les sandboxes doivent vivre aux côtés de services privés dans votre compte cloud. La décision s’inverse si l’organisation doit créer une équipe plateforme uniquement pour économiser sur le compteur de calcul.

Choisissez Modal lorsque la couche d’exécution est indissociable de Python, des notebooks, de l’inférence de modèles, des fonctions planifiées ou des GPU. Si la tâche se limite à exécuter du code hostile, une API davantage centrée sur la sécurité fera le travail avec moins de politiques à gérer.

Si vous devez choisir l’agent avant son environnement d’exécution, notre comparatif des meilleurs assistants de code IA traite cette décision en amont. Ne mélangez pas les deux : l’assistant détermine la manière dont le travail est produit ; la sandbox fixe ce que ce travail généré peut atteindre.

Les solutions et configurations à éviter

Un runner dont la documentation de sécurité s’arrête au mot « isolé » : avant tout achat, exigez des réponses écrites sur la barrière du noyau, la séparation des tenants, les sorties par défaut, le placement des identifiants, les journaux et la responsabilité des mises à jour. Si le fournisseur ne répond pas sur ces six points, ne placez ni données de production ni clés dans l’invité.

Un conteneur Docker Engine classique pris pour Docker Sandboxes : docker run n’est pas le produit microVM sbx et n’hérite ni de son noyau distinct, ni de son proxy réseau côté hôte, ni de l’injection d’identifiants, ni de la séparation du workspace en mode clone. Le nom ne fait pas l’architecture.

Docker Sandboxes en mode direct sur un dépôt inconnu : la VM protège l’essentiel de l’hôte, mais l’agent modifie directement l’arborescence de travail. Un hook Git ou un script de paquet altéré peut s’exécuter plus tard sur l’hôte. Utilisez --clone et inspectez chaque passerelle hors de la VM.

Un tunnel rapide Cloudflare sans authentification applicative : le nom d’hôte aléatoire ne dispose d’aucun token d’accès distinct. Considérez l’URL comme découvrable et ajoutez une authentification au service avant d’exposer la moindre prévisualisation sensible.

Un secret Daytona sans hosts : cette omission lève toute restriction sur le secret. Le courtier n’a d’intérêt que si la destination approuvée est explicitement définie.

Une phase de préparation laissée en « allow-all » : Vercel documente clairement le bon enchaînement : accès large pendant la préparation, puis phase d’exécution restreinte. Si la politique n’est jamais durcie, la microVM limite la compromission de l’hôte, mais n’empêche pas le code d’envoyer des données vers l’extérieur.

Ce dernier point trace la véritable ligne de partage de la catégorie. L’isolation répond à la question : « Le code peut-il s’échapper ? » La politique de sortie et d’identifiants répond à une autre : « Que peut faire le code sans avoir à s’échapper ? » Les deux défaillances peuvent aboutir au même résultat pour l’entreprise : les données de production en sortent.

Le plan d’action dès lundi

Ne commencez pas le lundi par une démonstration fournisseur. Commencez par dresser, sur une page, l’inventaire de tous les endroits où s’exécute du code généré par un modèle.

1. Nommez chaque chemin d’exécution. Incluez les agents de code locaux, les tâches CI, les agents de navigation, les notebooks d’analyse de données, les interpréteurs de code et les générateurs de prévisualisations client.
2. Représentez la barrière actuelle. Consignez l’isolation du noyau ou du runtime, les fichiers montés, les réseaux joignables et chaque identifiant accessible à l’invité.
3. Sortez les secrets de la sandbox. Placez les clés API dans un orchestrateur de confiance, un Worker, un proxy hôte ou le courtier d’identifiants du fournisseur. Le code peut toujours lire une variable d’environnement de la sandbox.
4. Bloquez les sorties par défaut. Autorisez l’hôte des paquets pendant la préparation, puis réduisez la liste de destinations au strict minimum avant le démarrage du code généré.
5. Menez deux exercices d’échec. Tentez d’abord de lire le fichier ou le processus d’un autre tenant, puis d’envoyer un token factice vers un hôte non approuvé. Le résultat doit être bloqué et générer un journal exploitable.
6. Désignez le responsable et fixez les plafonds. Quelqu’un doit examiner les changements de politique, les échecs des tests de barrière, les images, les journaux et les dépenses. Définissez les limites de durée, d’exécutions simultanées, de CPU, de mémoire et de budget mensuel avant la montée en charge.

L’achat viendra une fois cette page terminée. Une équipe exposée uniquement à des risques locaux pourra s’arrêter à Docker Sandboxes avec le mode clone. Une équipe produit sur Vercel n’aura peut-être besoin que d’un changement de politique réseau et de secrets intermédiés. Une plateforme réglementée pourra conclure que le BYOC de Northflank ou d’E2B se justifie. Le livrable du lundi est une décision sur les barrières, pas un nouvel abonnement.

Questions fréquentes

Quel outil d’IA offre la meilleure sécurité ?

Vercel Sandbox est le meilleur choix managé global de ce comparatif, car il associe une microVM Firecracker, une politique de sortie modifiable à chaud et un courtage d’identifiants. Docker Sandboxes convient mieux aux agents de code locaux ; Northflank ou E2B prend l’avantage lorsque le déploiement dans votre propre cloud est obligatoire. Le bon gagnant dépend de la frontière de confiance exigée.

Quelles tendances façonnent la sécurité de l’IA en 2026 ?

La tendance concrète va vers des noyaux distincts, des identifiants injectés hors de l’invité, des sorties bloquées par défaut et des tests de barrière récurrents. Les recommandations d’OpenAI du 10 août rendent la conséquence opérationnelle explicite : isolez les agents capables des systèmes de production et de l’Internet ouvert, puis surveillez leurs tentatives.

Existe-t-il des outils d’AI sandbox gratuits en 2026 ?

Oui. Docker Sandboxes propose une CLI à $0 sans frais par utilisateur. Vercel dispose d’une offre Hobby plafonnée, E2B fournit un crédit unique de $100, Daytona offre $200 de calcul, Northflank possède une offre Sandbox gratuite et Modal inclut $30 de crédit Starter mensuel récurrent. Cloudflare Sandbox exige l’offre Workers Paid à $5/mois.

Qu’est-ce qu’une sandbox IA ?

Une sandbox IA est un environnement d’exécution isolé dans lequel un agent peut lancer du code généré sans hériter d’un accès large à l’hôte, aux autres utilisateurs, aux systèmes de production, aux secrets ou à des chemins réseau sans restriction. Une sandbox adaptée à la production combine une barrière d’exécution avec une barrière distincte pour les sorties et les identifiants.

Téléchargez la checklist d’audit des workflows IA en entreprise pour transformer votre choix de sandbox en workflow délimité, avec responsable, liste de contrôles et rythme de revue.