--- service: "Publicasta" schema_version: "1.0" article_id: 739 title: "NVIDIA OpenShell place les permissions des agents sous contrôle politique : ce qui est prêt à être testé" language: "fr" default_language: "en" canonical_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries?lang=fr" json_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.json?lang=fr" api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/nvidia_openshell_agent_runtime_policy_boundaries?lang=fr" channel_url: "https://publicasta.com/api/public/v1/channels/open_source_radar" channel_articles: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-09-30T13:56:53+00:00" updated_at: "2026-09-30T13:56:53+00:00" translations: - language: "ar" html_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries?lang=ar" markdown_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.md?lang=ar" json_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.json?lang=ar" - language: "de" html_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries?lang=de" markdown_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.md?lang=de" json_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.json?lang=de" - language: "en" html_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries?lang=en" markdown_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.md?lang=en" json_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.json?lang=en" - language: "es" html_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries?lang=es" markdown_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.md?lang=es" json_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.json?lang=es" - language: "fr" html_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries?lang=fr" markdown_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.md?lang=fr" json_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries?lang=pl" markdown_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.md?lang=pl" json_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries?lang=ru" markdown_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.md?lang=ru" json_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries?lang=zh" markdown_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.md?lang=zh" json_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.json?lang=zh" --- # NVIDIA OpenShell place les permissions des agents sous contrôle politique : ce qui est prêt à être testé > OpenShell est un runtime sous licence Apache qui enferme les agents de code et les agents autonomes dans des sandboxes gouvernées par des règles. Son intérêt tient à la frontière qu’il impose aux fichiers, processus, réseaux, identifiants et changements de politique. NVIDIA OpenShell constitue le volet open source d’une nouvelle initiative visant à contenir plus facilement les agents autonomes. Le projet place des agents comme Codex, Claude Code, OpenCode et GitHub Copilot CLI dans des sandboxes, puis applique des règles aux fichiers qu’ils peuvent toucher, aux programmes qu’ils peuvent lancer, aux destinations réseau qu’ils peuvent atteindre et aux identifiants qu’ils sont autorisés à utiliser. ![Illustration éditoriale d’un agent autonome de programmation dans un bac à sable régi par des politiques pour les fichiers, les processus, le réseau et les identifiants.](https://publicasta.com/storage/projects/10/pages/739/2026/09/1f38b816-0b0a-4237-9770-bf3037993645.webp) Cette approche compte parce que les discussions sur la sécurité des agents commencent encore souvent par le modèle. OpenShell se place un niveau plus bas. Le projet part du principe qu’un modèle peut mal comprendre une demande, suivre des instructions hostiles présentes dans un dépôt, exécuter une commande shell risquée ou déléguer une tâche à un processus fils. La question devient alors : que le traitement résultant est-il techniquement autorisé à faire ? NVIDIA a annoncé sa plateforme plus large Open Agent Safety Platform le 28 septembre 2026. Celle-ci comprend également Sentry, une conception distincte de supervision et de confinement liée au matériel NVIDIA. OpenShell est la partie que les développeurs peuvent examiner et exécuter avec plusieurs choix d’infrastructure. Le projet est distribué sous licence Apache 2.0, mais il reste émergent, avec une certaine complexité opérationnelle, des exigences côté hôte et un modèle de politiques qui doit être testé avec soin. Le conseil pratique est simple : OpenShell mérite d’être essayé pour des expériences de sécurité, l’évaluation locale d’agents et des flux de développement contrôlés. Il est encore trop tôt pour considérer qu’un démarrage réussi prouve qu’un agent est sûr pour la production. ## L’angle actuel : la frontière de l’agent est le produit Le dépôt d’OpenShell le décrit comme un runtime destiné à des flottes d’agents autonomes. C’est une proposition différente de celle d’un framework d’agents. Le projet ne décide ni de la façon dont un agent planifie une tâche, ni du modèle qui doit générer l’étape suivante, ni de la manière dont un développeur doit structurer un graphe d’orchestration. Il se place sous un harnais existant et tente de maintenir ce harnais à l’intérieur d’une frontière de fonctionnement déclarée. Cette distinction est facile à manquer, car le projet arrive au milieu d’une vague de lancements d’agents. Un agent de code courant peut lire un checkout, modifier des fichiers source, installer des dépendances, appeler des registres de paquets, utiliser Git, accéder à des API cloud et lancer des sous-processus. Un prompt peut lui demander d’être prudent, mais un prompt n’est pas un mécanisme d’application. Si un agent reçoit une instruction malveillante depuis un README ou une issue, il peut toujours disposer des droits accordés par le shell qui l’entoure. OpenShell déplace l’endroit où cette autorité s’exprime. L’opérateur écrit la politique en YAML. Le runtime transforme cette politique en contrôles appliqués par le noyau, le superviseur de sandbox et un proxy réseau. Le modèle peut toujours prendre une mauvaise décision, mais cette décision doit passer par les permissions accordées à sa charge de travail. C’est un angle open source plus utile qu’une nouvelle liste de modèles pris en charge. Le projet cherche à savoir si les permissions d’un agent peuvent devenir une configuration portable et révisable. Si cela fonctionne, la même politique peut voyager avec une image de sandbox ou être examinée dans une pull request. Si cela échoue, le projet deviendra une couche de configuration supplémentaire que les développeurs contourneront dès qu’elle gênera une tâche. ## Ce qu’OpenShell contrôle réellement La politique centrale comprend plusieurs domaines, qui ne se comportent pas tous de la même façon. Le facteur temps est l’un des premiers points qu’un évaluateur doit comprendre. `filesystem_policy` définit les chemins lisibles et ceux qui sont accessibles en écriture. Le projet utilise des contrôles fondés sur Landlock pour l’accès au système de fichiers. Les paramètres liés au système de fichiers et à Landlock sont appliqués au démarrage de la sandbox. Les modifier n’équivaut donc pas à modifier une règle réseau sur une charge de travail déjà en cours. Une politique peut autoriser un agent à écrire dans un répertoire de projet et un répertoire temporaire tout en gardant hors de sa vue les identifiants, les clés SSH, les profils de navigateur et les données non liées du répertoire personnel. La section `process` contrôle l’identité et les conditions de processus utilisées lors de la création de la sandbox. L’objectif est d’empêcher une charge de travail de transformer une tâche de programmation ordinaire en exercice d’escalade de privilèges. Cela reste toutefois dépendant du runtime et de la configuration de l’hôte choisis ; un fichier de politique n’efface pas les hypothèses de sécurité de Docker, Podman, Kubernetes, d’une machine virtuelle ou du système d’exploitation sous-jacent. Les `network_policies` contrôlent les accès sortants. OpenShell adopte pour les connexions de sandbox un modèle où tout est refusé par défaut, puis autorise des destinations nommées et, lorsque cela est configuré, certains binaires. Une règle peut distinguer un gestionnaire de paquets d’une commande shell, ou un client Git d’un client HTTP générique. Il devient ainsi possible d’autoriser un flux précis sans donner la même sortie réseau à chaque processus. La couche réseau peut aussi inspecter les requêtes à un niveau supérieur. L’exemple de NVIDIA autorise `curl` à lire l’API REST de GitHub tout en rejetant une requête d’écriture. Le détail important est qu’autoriser un hôte ne revient pas nécessairement à autoriser toutes les opérations sur cet hôte. Une politique peut décrire un endpoint, un port, un protocole, un binaire autorisé et un accès en lecture seule ou en écriture. Les `network_middlewares` fournissent un autre emplacement pour inspecter, transformer ou bloquer les requêtes. En pratique, c’est là qu’une politique peut devenir plus précise qu’une règle de pare-feu classique. La documentation du projet décrit des contrôles pour les flux HTTP, GraphQL et Model Context Protocol. Cela ne signifie pas que tous les protocoles applicatifs sont aussi matures ou aussi faciles à exprimer ; cela signifie que le runtime est conçu pour raisonner sur les requêtes, et pas seulement sur les adresses IP et les ports. Enfin, les profils de fournisseurs gèrent les identifiants et les accès approuvés aux services. Le modèle visé est qu’un agent ne reçoive pas un secret brut pour pouvoir ensuite l’utiliser partout. OpenShell conserve l’identifiant réel hors de la charge de travail, vérifie la destination et la politique, puis substitue le secret uniquement pour une requête autorisée. Un jeton GitHub utilisable sur un chemin d’API en lecture seule ne devrait pas automatiquement devenir un secret général accessible à chaque commande de la sandbox. Cette dernière frontière est particulièrement importante pour les agents de code. Un outil peut être empêché de lire un jeton local tout en recevant un accès étroitement limité à un service distant. Ce dispositif ne remplace pas les permissions propres au service. Il ajoute un contrôle sur la manière dont l’agent peut les utiliser. ## Une petite politique est plus instructive qu’une promesse marketing La meilleure manière d’évaluer OpenShell consiste à commencer par une tâche volontairement banale. Créez une sandbox sans accès réseau sortant. Lancez une requête sans danger, par exemple un appel à l’API publique de GitHub. Vérifiez que la requête est bloquée et examinez le journal. Appliquez ensuite une politique qui autorise un endpoint GitHub en lecture seule et répétez l’appel. Enfin, tentez une opération d’écriture et vérifiez que la règle en lecture seule la rejette. Une forme de politique simplifiée peut ressembler à ceci : ```yaml version: 1 filesystem_policy: include_workdir: true read_only: - /usr - /lib - /etc read_write: - /tmp landlock: compatibility: best_effort network_policies: github_api: name: github-api-readonly endpoints: - host: api.github.com port: 443 protocol: rest enforcement: enforce access: read-only binaries: - path: /usr/bin/curl ``` Cet exemple n’est pas une politique de production. Il sert à rendre le contrôle visible. Il montre aussi pourquoi le projet doit être évalué avec des tests plutôt qu’avec des captures d’écran. La vraie question n’est pas de savoir si le YAML existe. Il faut vérifier qu’une requête qui devrait être refusée l’est bien avec le runtime, l’image, le chemin du binaire, la configuration des identifiants et la configuration de l’hôte que l’équipe entend déployer. La documentation d’OpenShell indique que les contrôles statiques sont verrouillés lors de la création de la sandbox, tandis que les contrôles réseau peuvent être modifiés pendant l’exécution. Cela peut servir à une approbation progressive : un agent commence sans réseau, demande l’accès à un service précis, puis reçoit une mise à jour examinée sans redémarrage. Cette possibilité crée aussi un problème de gouvernance. Un changement de politique dynamique peut élargir l’accès au cours d’une session longue ; le circuit d’approbation, la trace d’audit et le comportement en cas de retour arrière comptent donc autant que la politique initiale. Le projet comprend un conseiller de politique et un outil de preuve de politique pour examiner les accès proposés. L’idée est de vérifier qu’un changement n’ajoute pas une nouvelle autorité avant de l’appliquer. C’est une direction utile, mais la vérification formelle d’une politique ne revient pas à vérifier qu’elle exprime l’intention métier. Une règle formellement valide peut quand même autoriser le mauvais dépôt, la mauvaise méthode d’API ou un identifiant plus puissant que nécessaire. ## Qui devrait l’essayer maintenant OpenShell convient aux personnes qui exécutent déjà des agents avec une autorité locale importante et qui veulent mesurer la différence entre la prudence demandée par un prompt et l’application d’une règle au niveau du runtime. Les ingénieurs sécurité peuvent s’en servir pour construire des tests reproductibles d’évasion et d’exfiltration d’agents. Les équipes plateforme peuvent étudier la manière dont les politiques se déplaceraient d’un ordinateur de développeur vers une passerelle Kubernetes. Les mainteneurs d’outils d’agents peuvent tester le comportement de leurs arbres de processus, de leurs appels réseau et de leurs intégrations fournisseurs dans un environnement restreint. Le projet intéresse aussi les développeurs qui travaillent sur des dépôts qu’ils n’ont pas créés. Une base de code inconnue peut contenir des scripts d’installation, des fichiers générés, des hooks de dépendances ou des instructions destinées aux outils automatisés. Une sandbox limitée au répertoire de travail et dépourvue de sortie réseau par défaut offre un endroit plus sûr pour examiner ces éléments. La protection n’est pas absolue, mais elle peut réduire les conséquences d’une commande accidentelle. Les chercheurs qui évaluent des modèles locaux peuvent également tirer parti de cette séparation. OpenShell peut exécuter un agent avec une inférence locale ou cloud tout en plaçant les fichiers et les requêtes sortantes de la charge de travail derrière une politique. Une expérience peut ainsi comparer plusieurs modèles sans modifier entièrement l’environnement de l’hôte à chaque exécution. Les équipes doivent être plus prudentes si elles cherchent un plan de contrôle d’entreprise prêt à l’emploi. Le dépôt comprend une passerelle, des SDK, la gestion des fournisseurs, des fonctions d’audit et un chemin de déploiement Kubernetes, mais utiliser ces éléments ensemble relève d’un projet systèmes. Il faut gérer les images, les privilèges du runtime, l’application réseau, l’identité, les secrets, les journaux, la réponse aux incidents et la responsabilité des politiques. Installer la CLI ne revient pas à avoir terminé ce travail. ## L’hôte et le runtime restent déterminants Le guide de démarrage rapide vise actuellement Linux, macOS sur Apple Silicon et Windows via WSL 2 à titre expérimental. Le projet attend un support de conteneurisation ou de virtualisation comme Docker, Podman ou la virtualisation de l’hôte. Kubernetes est pris en charge au moyen d’un déploiement Helm, le projet précisant que la couche réseau du cluster doit appliquer la politique réseau concernée. Ces exigences ne sont pas de simples notes administratives. Une sandbox n’est aussi solide que la frontière qui l’applique réellement. Une équipe doit documenter les fonctions du noyau disponibles, le comportement observé lorsque Landlock est indisponible, le caractère rootless ou non du moteur de conteneurs, les capacités qui restent dans la charge de travail, la manière dont les images sont construites et la façon dont les mises à jour sont authentifiées. Le même YAML peut produire des résultats pratiques différents lorsque les hypothèses côté hôte changent. La documentation des politiques inclut un réglage de compatibilité pour Landlock. Cette adaptation est utile dans des environnements variés, mais un choix de compatibilité permissif ne doit pas être confondu avec la garantie que chaque restriction de système de fichiers prévue est active. Un déploiement de production a besoin d’un contrôle au démarrage qui échoue fermé ou qui signale clairement une posture de sécurité réduite. Le proxy réseau est une autre dépendance à tester. Si l’agent doit utiliser un registre de paquets, un fournisseur Git, un endpoint de modèle, un outil de suivi ou un serveur MCP, chaque service élargit la surface de politique. Une règle autorisant un domaine général peut être pratique tout en sapant la raison d’être des contrôles par endpoint. Une règle trop étroite peut inciter un développeur à ajouter une exception attrape-tout. La conception opérationnelle doit rendre le chemin étroit plus facile que le contournement. ## Le courtage des identifiants est prometteur, mais pas magique Le modèle de fournisseurs d’OpenShell répond à un échec courant : donner à un agent un environnement contenant tous les jetons disponibles pour l’utilisateur. En conservant les identifiants hors de la sandbox et en les liant à des destinations approuvées, le runtime peut empêcher qu’un jeton destiné à un service soit envoyé vers un autre. Il peut aussi appliquer une règle de requête en lecture seule même si le jeton sous-jacent autorise techniquement les écritures. Cela ne supprime pas le risque lié aux identifiants. Le service doit toujours émettre des jetons raisonnablement limités. Un profil fournisseur doit être configuré correctement. Le proxy doit reconnaître le trafic qu’il est censé inspecter. Un identifiant autorisé à supprimer des dépôts reste dangereux si la politique autorise la méthode d’API correspondante. Et un modèle peut toujours produire une action dommageable dans le périmètre qui lui a été accordé. Le meilleur test est donc une matrice, pas un seul cas de réussite. Testez une lecture autorisée, une écriture refusée, un hôte non approuvé, une requête envoyée par le mauvais binaire, un identifiant expiré, une requête mal formée, un sous-processus et un agent fils. Testez les mêmes actions via le SDK ou le chemin d’intégration qu’utilisera la charge de travail réelle. Examinez ensuite les sorties d’audit afin de déterminer si un opérateur pourrait reconstituer ce qui s’est passé. OpenShell indique qu’il consigne les décisions de politique dans une trace d’audit conforme à l’Open Cybersecurity Schema Framework. C’est utile pour répondre à un incident, mais les journaux n’aident que s’ils sont collectés, conservés, protégés contre la charge de travail et reliés à l’identité de la personne ou de l’automatisation ayant approuvé le changement. Un journal local de démonstration n’est pas encore un système d’audit d’entreprise. ## Ce que le projet ne résout pas OpenShell est un mécanisme de confinement, pas un mécanisme d’alignement. Il ne peut pas rendre fiable un modèle peu fiable, distinguer une erreur métier subtile d’une action valide ni garantir qu’une spécification de tâche est sûre. Si un agent est autorisé à modifier un déploiement de production, le runtime peut appliquer correctement cette permission tandis que le modèle effectue une modification désastreuse mais techniquement autorisée. Il ne remplace pas non plus les fournisseurs d’identité, les gestionnaires de secrets, la sécurité des endpoints, la gestion des vulnérabilités, les contrôles de la chaîne logistique logicielle, l’observabilité ou l’approbation humaine. Les documents de NVIDIA présentent OpenShell comme une frontière de runtime pour les agents, intégrée aux systèmes environnants. C’est la bonne manière de le comprendre. Le projet ajoute une couche ; il ne rend pas le reste de la pile facultatif. Il existe une limite plus élémentaire : la qualité de la politique détermine l’accès réellement utile. Un agent de développement qui ne peut pas lire les bons fichiers ou atteindre le bon registre de paquets échouera de façon difficile à interpréter. Un agent disposant de permissions étendues sur le système de fichiers et le réseau peut fonctionner sans accroc tout en recevant peu de protection concrète. Le défi consiste à définir l’autorité minimale qui permet encore à la tâche d’aboutir, puis à rendre les exceptions explicites et révisables. Les discussions publiques ont soulevé la même inquiétude sous un autre angle. La couverture de l’annonce a relevé que des contrôles restrictifs pouvaient bloquer un travail utile et qu’il fallait des études de cas pour comprendre l’équilibre. Ce n’est pas une raison pour écarter le projet. C’est une raison de tester des flux réels au lieu de répéter qu’un agent peut être mis en quarantaine en quelques millisecondes. Le composant Sentry doit aussi rester conceptuellement distinct. NVIDIA le présente comme une couche de supervision et de confinement au niveau matériel, tandis qu’OpenShell est le runtime ouvert et la frontière de politique. Selon NVIDIA et les articles consacrés au lancement, OpenShell peut être utile sur des plateformes de calcul concurrentes, notamment Arm et Intel. Une équipe qui évalue le projet open source ne doit pas supposer qu’elle reçoit automatiquement toutes les propriétés de la plateforme NVIDIA plus large. ## Licence et maturité du projet Le dépôt d’OpenShell identifie la licence Apache 2.0 comme licence du projet. Il s’agit d’une licence permissive courante pour les projets d’infrastructure et les outils destinés aux développeurs. Elle facilite l’inspection, la modification et l’intégration du code, sous réserve de ses conditions et des conditions distinctes attachées aux contenus récupérés, aux images de conteneurs, aux modèles, aux fournisseurs et aux composants tiers. Le dépôt contient également une politique de sécurité et des notices relatives aux tiers. Ces documents doivent faire partie d’un examen avant adoption. La clause de non-responsabilité du projet précise que les éléments récupérés ou consultés par le logiciel sont régis par leurs propres conditions et que les utilisateurs sont responsables de vérifier leur sécurité, leur intégrité et leur adéquation. En pratique, un runtime ouvert ne rend pas automatiquement fiables toutes les images, compétences, extensions, modèles ou scripts qui y sont exécutés. La maturité doit être jugée à partir de l’historique des versions et des issues, pas seulement de la présence d’une grande entreprise derrière le dépôt. OpenShell couvre une surface étendue : CLI, passerelle locale, pilotes de sandbox, schéma de politiques, comportement du proxy, identifiants fournisseurs, SDK, déploiement Helm, routage d’inférence et compétences pour agents. Chaque composant soulève des questions de compatibilité et de sécurité. Les premiers utilisateurs devraient figer les versions, conserver un environnement de test jetable, examiner les changements entre les versions et préserver une possibilité de retour arrière. La télémétrie mérite une vérification spécifique. Le dépôt indique qu’OpenShell collecte par défaut des catégories opérationnelles anonymes et des compteurs, tout en excluant les noms, les noms d’hôtes, les chemins de fichiers, les prompts, les identifiants, les noms de fournisseurs, les noms de modèles et le contenu utilisateur. Il documente également des moyens de désactiver la télémétrie ou de la supprimer à la compilation. Cette transparence est plus utile que le silence, mais les organisations soumises à de strictes exigences de confidentialité doivent vérifier l’implémentation et leur configuration de build plutôt que de s’en remettre à un résumé. ## Alternatives et compléments OpenShell n’est pas la seule façon de réduire l’autorité d’un agent. Un conteneur minimal sans montage depuis l’hôte peut suffire pour une étape de build étroite. Un conteneur rootless, une microVM, une machine virtuelle dédiée, un worker de développement distant ou un job CI offrent d’autres compromis d’isolation. Les primitives Linux telles que Landlock et seccomp peuvent aussi être utilisées directement lorsqu’une équipe souhaite une surface de contrôle plus petite. Ces approches ne résolvent pas les mêmes parties du problème. Les conteneurs et les pods fournissent des substrats d’exécution. Les microVM peuvent offrir une frontière d’isolation plus forte au prix d’un temps de démarrage et d’une gestion d’images supplémentaires. Les runners CI sont utiles pour les jobs répétables, mais peuvent être moins pratiques pour le développement interactif. Une politique directe au niveau du noyau peut rester légère, mais elle laisse aux équipes le soin de construire leur propre courtage d’identifiants, médiation réseau, gestion du cycle de vie et conventions d’audit. L’argument d’OpenShell est que les charges de travail d’agents ont besoin d’une coordination entre ces éléments. Une politique devrait décrire non seulement ce que le processus peut lire, mais aussi quel exécutable peut appeler quel endpoint, quel identifiant est associé à cet endpoint, comment une politique en cours évolue et comment le résultat est journalisé. Cette coordination est la principale raison d’être du projet. La bonne comparaison n’est donc pas OpenShell contre Docker. Il faut comparer OpenShell plus un runtime à un runtime seul, en évaluant la politique et les composants de passerelle supplémentaires au regard de la complexité qu’ils ajoutent. Pour une simple commande de build non fiable, OpenShell peut être inutile. Pour un agent capable de parcourir un dépôt, d’installer des outils, d’appeler des API et de lancer des sous-processus pendant une longue session, cette couche supplémentaire peut se justifier. ## Un plan d’évaluation raisonnable Commencez par un hôte jetable et un petit dépôt. Notez le système d’exploitation de l’hôte, les fonctions du noyau, le moteur de conteneurs, la version d’OpenShell, l’image de sandbox, la version de l’agent et la configuration des fournisseurs. Ne commencez pas avec des identifiants de production ni avec un projet contenant des secrets sans rapport avec le test. Créez une sandbox de référence. Vérifiez quels fichiers sont visibles, quels chemins sont accessibles en écriture, quel utilisateur possède les processus et ce qui se passe lorsqu’une commande tente d’utiliser le réseau. Exécutez les mêmes contrôles depuis l’agent, depuis un shell lancé par l’agent et depuis un processus fils. Ajoutez un seul service à la fois. Un service de paquets ou Git en lecture seule constitue un meilleur point de départ qu’un accès web sans restriction. Testez le chemin positif et plusieurs chemins négatifs. Conservez la politique dans le contrôle de version, examinez-la comme du code et écrivez pourquoi chaque endpoint et chaque binaire autorisé sont nécessaires. Testez ensuite les changements de politique pendant une session. Vérifiez quelles sections exigent une nouvelle sandbox et lesquelles peuvent être rechargées à chaud. Assurez-vous qu’une requête refusée le reste jusqu’à l’application effective du changement approuvé. Testez le retour arrière et la gestion des erreurs. Un système de contrôle d’accès doit être évalué lorsque la passerelle est indisponible, qu’une politique est mal formée, qu’un fournisseur manque et qu’une requête réseau expire. Simulez enfin un incident. Donnez à l’agent une instruction de dépôt lui demandant de rechercher des secrets, d’appeler un endpoint non approuvé ou de modifier un fichier situé hors de l’arborescence de travail. Le but n’est pas de piéger le modèle pour le plaisir. Il s’agit de déterminer si la frontière bloque l’action, si l’erreur est compréhensible, si l’événement est journalisé et si un opérateur peut resserrer la politique sans détruire la session. ## Le verdict NVIDIA OpenShell est intéressant parce qu’il traite l’autorité d’un agent comme une question d’infrastructure plutôt que comme une promesse enfouie dans un message système. Son code sous licence Apache, ses politiques déclaratives, ses contrôles du système de fichiers fondés sur le noyau, sa médiation réseau, ses identifiants fournisseurs et son modèle de passerelle donnent aux développeurs quelque chose de concret à tester. Le projet s’insère aussi naturellement dans l’écosystème open source : il prend en charge plusieurs harnais d’agents, expose des SDK, documente une voie Kubernetes et peut fonctionner sur du matériel qui n’est pas exclusivement NVIDIA. La prudence est tout aussi concrète. Le projet n’est pas un système de sécurité universel, ses politiques peuvent être difficiles à concevoir, ses hypothèses côté hôte doivent être vérifiées et son vaste éventail de fonctions augmente le coût d’un déploiement sérieux. Une règle réseau par défaut qui refuse tout est utile seulement si les exceptions restent étroites. Une sandbox est utile seulement si l’hôte et l’image sont compris. Un courtier d’identifiants est utile seulement si les permissions des fournisseurs et l’inspection des requêtes sont testées. Pour le lectorat d’Open Source Radar, l’étape raisonnable est un essai en laboratoire, pas une migration de production. Utilisez OpenShell pour construire un banc de test reproductible sur les flux d’agents qui disposent actuellement d’une autorité excessive. Mesurez les actions bloquées, les faux positifs, le comportement au démarrage, la revue des politiques, les journaux et la récupération après incident. Si les contrôles résistent à ce processus sans transformer chaque tâche en file d’attente d’approbation, OpenShell pourrait devenir une base pratique pour un développement d’agents plus sûr. Dans le cas contraire, l’expérience montrera tout de même précisément où le flux dépend d’une autorité ambiante — et c’est une information dont la plupart des projets d’agents ont besoin. ## Sources - [Dépôt et README de NVIDIA OpenShell](https://github.com/NVIDIA/OpenShell) — NVIDIA, source factuelle. - [Politiques de sandbox OpenShell](https://docs.nvidia.com/openshell/dev/how-it-works/policies/overview) — documentation NVIDIA, source factuelle. - [Add Runtime Controls to AI Agents with NVIDIA OpenShell](https://developer.nvidia.com/blog/?p=122891) — NVIDIA Technical Blog, publié le 28 septembre 2026, contexte factuel. - [Présentation et FAQ du produit NVIDIA OpenShell](https://www.nvidia.com/en-us/ai/openshell/) — NVIDIA, contexte. - [Licence OpenShell](https://github.com/NVIDIA/OpenShell/blob/main/LICENSE) — NVIDIA, licence. - [Nvidia unveils security platform to stop AI agents from going rogue](https://apnews.com/article/nvidia-ai-agent-artificial-intelligence-safety-3c4d7c1cfde82851;) — Associated Press, contexte. - [Discussion de contexte sur les projets open source actuels](https://news.ycombinator.com/front) — Hacker News, discussion.