Anthropic sandbox-runtime : encadrer les agents IA sans conteneur
Anthropic publie sandbox-runtime, un bac à sable OS pour limiter fichiers et réseau des agents IA sans gérer de conteneur.
Anthropic met en avant sandbox-runtime, un runtime de sandboxing au niveau du système d'exploitation conçu pour encadrer les agents IA. L'objectif est simple : limiter précisément ce qu'un agent peut lire, écrire et contacter sur le réseau, sans demander aux équipes de créer ni d'exploiter un conteneur.
Pour les entreprises, l'intérêt n'est pas seulement Claude Code. Ce modèle de contrôle peut servir à réfléchir à la manière de faire tourner des agents, des outils en ligne de commande et des serveurs MCP avec moins de surface d'accès.
Ce qui change concrètement
Anthropic présente sandbox-runtime comme un nouveau runtime de sandbox disponible en bêta, sous forme de research preview. Il permet de définir les répertoires et les hôtes réseau accessibles à un agent. La différence clé : l'isolation se fait au niveau OS, sans obliger l'équipe à construire une image, lancer un conteneur ou gérer une pile d'orchestration.
La documentation officielle GitHub décrit sandbox-runtime comme un outil léger pour imposer des restrictions de système de fichiers et de réseau au niveau du système. Anthropic indique qu'il peut sandboxer des processus arbitraires, des agents et des serveurs MCP. Ce point est important pour les organisations qui commencent à relier des agents à des outils internes.
Dans son article de recherche sur le containment de Claude, Anthropic précise que la sandbox s'appuie sur des primitives natives : bubblewrap sous Linux et Seatbelt sous macOS. Le principe appliqué à Claude Code est clair : lecture et écriture autorisées dans le workspace, réseau refusé par défaut. Les accès supplémentaires doivent donc être explicitement ouverts.
Ce modèle répond à un problème très concret. Un agent de code peut avoir besoin de modifier un projet local, lire des fichiers de configuration ou interagir avec des outils. Mais il n'a pas toujours besoin d'accéder à tout le disque, ni à Internet. En séparant le workspace, les chemins autorisés et les hôtes réseau acceptés, l'équipe peut réduire les permissions globales sans bloquer les tâches utiles.
Anthropic indique aussi avoir observé une baisse de 84 % des demandes de permission après le déploiement de cette sandbox OS-level dans son contexte. Ce chiffre ne garantit pas le même résultat partout, mais il montre l'enjeu : une bonne politique d'accès peut rendre l'agent plus fluide à utiliser, tout en évitant les validations répétitives.
Comment l'essayer
Le projet est publié sur GitHub comme early open source preview. Anthropic le décrit aussi comme une bêta en research preview. Aucun tarif propre à sandbox-runtime n'est communiqué.
Pour les équipes qui veulent l'approcher via Claude Code, Anthropic indique qu'un abonnement Pro ou Max donne accès à Claude Code, avec une souscription unifiée couvrant aussi Claude sur le web, desktop et mobile. La même page de support précise que Claude Code peut également être authentifié via Anthropic Console, avec une facturation API pay-as-you-go si l'utilisateur choisit cette voie.
Le centre d'aide Claude liste notamment les plans individuels Free, Pro, Max 5x et Max 20x, avec Pro à 20 dollars par mois ou 200 dollars par an, Max 5x à 100 dollars par mois et Max 20x à 200 dollars par mois. Ces prix concernent les plans Claude, pas un prix séparé pour sandbox-runtime. Anthropic indique par ailleurs que la France fait partie des pays où Claude est accessible.
Pour qui, et pour quoi faire
Le cas d'usage le plus immédiat concerne les équipes de développement qui laissent un agent intervenir sur un dépôt local. Tu peux concevoir une politique où l'agent lit et écrit dans le workspace du projet, mais ne voit pas le reste du disque. Le réseau reste fermé par défaut, puis seuls les hôtes nécessaires sont ajoutés si le flux de travail l'exige.
Exemple professionnel : une équipe produit utilise un agent pour préparer une correction dans un dépôt applicatif. L'agent peut modifier les fichiers du projet, lancer les commandes prévues par l'équipe et travailler dans le répertoire autorisé. En revanche, il ne peut pas parcourir des dossiers personnels, ni envoyer des données vers un hôte non approuvé si la politique réseau ne l'autorise pas.
Le même raisonnement vaut pour les serveurs MCP. Si un serveur MCP donne accès à des outils internes, le faire tourner dans un périmètre réduit aide à limiter les conséquences d'un mauvais paramétrage, d'un prompt imprécis ou d'une action non prévue. Pour structurer ce type de démarche, le guide NXUS sur les agents IA en entreprise peut servir de point de départ : faire travailler un agent IA dans son entreprise.
Limites et points de vigilance
Le premier point à retenir : sandbox-runtime est présenté comme une preview. Il faut donc l'évaluer comme une brique technique en maturation, pas comme une réponse clé en main à tous les risques agents. Une validation sécurité interne reste nécessaire, surtout si l'agent manipule du code sensible, des secrets ou des données client.
Deuxième point : ce n'est pas un conteneur. C'est justement son intérêt pour certains usages, car l'approche est plus légère. Mais cela signifie aussi qu'il ne remplace pas les fonctions attendues d'une plateforme de conteneurs, comme la gestion d'images, le cycle de vie complet d'un environnement ou l'orchestration à grande échelle.
Troisième point : le niveau d'isolation dépend des primitives OS utilisées. Anthropic mentionne bubblewrap pour Linux et Seatbelt pour macOS. Si ton parc technique est hétérogène, il faut vérifier comment cette approche s'intègre à tes postes de développement, à tes runners CI et à tes règles de sécurité existantes.
Enfin, le refus du réseau par défaut est utile, mais il ne dispense pas d'une gouvernance. Les hôtes autorisés doivent être documentés. Les chemins accessibles doivent être minimisés. Les accès aux secrets doivent rester séparés autant que possible.
L'avis NXUS
sandbox-runtime est une brique intéressante parce qu'elle rend le contrôle d'accès des agents plus concret : quels dossiers, quels hôtes, quels processus. Pour une équipe, le bon réflexe est de commencer petit : workspace autorisé, réseau fermé, puis ouverture progressive des seuls accès nécessaires.
Il ne faut pas y voir une protection magique. La valeur vient surtout de la discipline de configuration et de la revue régulière des permissions. Si tu déploies des agents en entreprise, réutilise l'idée centrale : une politique d'accès explicite avant de donner des outils puissants à un agent.
Sources
Source : Anthropic
Rudy Molinillo
