Un conteneur est une pièce, pas un système d'autorisation
Les agents IA présentent un nouveau risque substantiel : les développeurs accordent régulièrement à des outils comme Claude Code ou Codex un accès étendu à des référentiels, API et identifiants sensibles, puis les laissent fonctionner sans surveillance. Cette commodité se fait souvent au détriment de la sécurité, car l'utilité d'un agent est directement liée à son accès à des ressources critiques.
Les conteneurs ordinaires, bien qu'efficaces pour l'isolation de l'hôte, ne peuvent pas différencier les actions nuancées. Une connexion GitHub, par exemple, permet à la fois de lire des données et d'effectuer des modifications destructrices. Le conteneur ne voit que le trafic vers la même adresse, incapable de discerner si un agent navigue simplement dans le code ou s'il ouvre activement des tickets.
OpenShell de NVIDIA, un nouveau bac à sable open-source, comble cette lacune. Écrit en Rust et sous licence Apache 2.0, OpenShell contrôle ce qu'un agent peut faire avec son accès, et pas seulement s'il peut atteindre une ressource. Fait crucial, il ne nécessite aucun GPU NVIDIA et fonctionne sur du matériel standard.
La conception axée sur les politiques d'OpenShell impose un contrôle granulaire sur l'accès aux fichiers, les appels système et les connexions réseau. Il fonctionne avec une posture de refus par défaut, ce qui signifie que les agents ne peuvent rien faire tant qu'ils n'y sont pas explicitement autorisés. Cette application fine est un bond en avant significatif par rapport à la conteneurisation de base.
Le videur vérifie chaque sortie
OpenShell cartographie trois composants principaux : la Gateway agit comme interface et plan de contrôle ; le Supervisor applique la politique et négocie les identifiants ; et le Sandbox fournit l'environnement contraint où l'agent s'exécute. Le seul chemin de sortie du Sandbox passe par le Supervisor, garantissant que toutes les interactions externes sont médiatisées.
Le comportement de refus par défaut est au cœur du modèle de sécurité d'OpenShell. Les restrictions du système de fichiers et des processus au niveau du noyau bloquent dès le départ les chemins non autorisés et l'élévation de privilèges. Toute requête réseau provenant de l'agent doit passer par le Supervisor, qui l'examine par rapport à des politiques prédéfinies.
Considérez une politique autorisant le binaire curl à effectuer des requêtes en lecture seule vers l'API GitHub. Le Supervisor l'autorise. Cependant, si ce même binaire curl tente une requête POST non approuvée pour créer un ticket, le Supervisor la refuse. Ces politiques se mettent à jour en direct via openshell policy update sans redémarrer le bac à sable, et chaque refus est consigné, fournissant une piste d'audit claire.
De manière critique, l'agent ne manipule jamais directement les identifiants. Le Supervisor n'injecte des jetons que pour les requêtes approuvées, empêchant l'exfiltration via l'injection de prompt. Même la résolution DNS s'effectue via le Supervisor, limitant la visibilité et le contrôle de l'agent. Cette conception garantit que même si un agent est compromis, il n'a aucune clé à divulguer.
L'astuce : votre agent ne détient jamais la clé
La fonctionnalité la plus ingénieuse d'OpenShell est le masquage des identifiants (credential masking) : l'agent ne détient jamais directement de clés API ou de jetons sensibles. Au lieu de cela, le Supervisor conserve ces secrets, ne les injectant que dans les requêtes sortantes approuvées qui correspondent à la politique établie. Cette conception réduit considérablement la surface d'attaque pour l'injection de prompt, car il n'y a aucune identifiant que l'agent puisse divulguer.
Avant que toute modification de politique ne soit mise en ligne, OpenShell utilise un solveur Z3 pour agir en tant que vérificateur formel. Ce moteur mathématique évalue les modifications de politique proposées, calculant toute l'étendue du nouvel accès accordé. Cette vérification proactive aide à exposer les règles risquées, telles que des caractères génériques involontaires ou des autorisations trop larges, les empêchant d'être jamais déployées.
Bien qu'il existe des alternatives — Docker fournit une isolation de base, le runtime sandbox d'Anthropic offre une configuration plus légère, et des solutions hébergées comme E2B ou Daytona proposent une exécution gérée — OpenShell se taille une place à part. Il met l'accent sur un contrôle des agents auto-hébergé et piloté par des politiques, s'exécutant au-dessus de runtimes de conteneurs tels que Docker, Podman ou Kubernetes. Pour ceux qui s'intéressent à l'architecture sous-jacente et aux contributions open-source, le projet est disponible sur NVIDIA/OpenShell sur GitHub.
OpenShell représente un changement de paradigme, passant de la simple question « l'agent peut-il y accéder ? » à « qu'est-ce que l'agent est autorisé à en faire ? ». Les rapports de télémétrie de NVIDIA montrent qu'en deux semaines cet été, OpenShell a créé plus de 550 000 sandboxes et bloqué 4,2 millions d'actions d'agents, soulignant son rôle actif dans l'application des limites des agents.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Des garde-fous utiles, pas un champ de force de sécurité
OpenShell offre des garde-fous utiles, pas un champ de force de sécurité. Son stade précoce est évident : malgré l'intérêt marqué de l'écosystème de la part de Cisco, CrowdStrike, Google Cloud et Microsoft Security, la version du projet n'est que 0.1.5, étiquetée comme une « early preview ». La télémétrie est activée par défaut, comptant les événements de manière anonyme, bien qu'une variable d'environnement puisse la désactiver.
Les utilisateurs de Mac doivent noter que les sandboxes OpenShell sont basées sur Linux et s'exécutent au sein de la machine virtuelle de Docker Desktop. Cela nécessite des fonctionnalités du noyau comme Landlock et la mise en réseau hôte activées, ce qui est souvent désactivé par défaut. La commande doctor de NVIDIA peut afficher un statut vert, mais des tests sont conseillés.
La télémétrie interne de NVIDIA rapporte une activité stupéfiante : plus de 550 000 créations de sandboxes et 4,2 millions d'actions d'agents bloquées sur une période de deux semaines. Ces chiffres soulignent l'ampleur des dépassements d'agents qu'OpenShell intercepte. Cependant, NVIDIA a également rapporté qu'environ 12 % des créations de sandboxes ont échoué au cours de la même période ; il s'agit de chiffres de télémétrie de l'entreprise, et non d'un audit indépendant.
Pour un codage local plus simple avec des outils comme Claude Code, un conteneur de base ou le runtime sandbox d'Anthropic pourrait suffire avec moins de configuration. Mais pour les agents manipulant de vraies informations d'identification ou effectuant des tâches longues et non supervisées, les règles par requête et le masquage des identifiants d'OpenShell sont inestimables. Une conception minutieuse des politiques reste essentielle, car le sandboxing atténue les risques mais ne peut éliminer toutes les vulnérabilités potentielles.
Questions fréquemment posées
Qu'est-ce que NVIDIA OpenShell ?
OpenShell est un runtime open-source permettant de restreindre l'accès des agents IA aux fichiers, aux processus et au réseau grâce à des politiques appliquées en dehors de l'agent.
OpenShell nécessite-t-il un GPU NVIDIA ?
Non. La vidéo montre qu'il fonctionne sur un Mac ; OpenShell ne dépend pas du matériel GPU NVIDIA.
En quoi OpenShell est-il différent de Docker ?
Docker isole un conteneur, tandis qu'OpenShell ajoute des contrôles granulaires, incluant des règles sur les processus pouvant accéder à des points de terminaison réseau et des opérations spécifiques.
OpenShell empêche-t-il tous les risques de sécurité liés aux agents IA ?
Non. Il limite ce à quoi un agent peut accéder, mais ce n'est pas une garantie de sécurité complète ; la configuration, les limites d'isolation et la maturité du logiciel restent importantes.