NVIDIA publie en open source des contrôles d’exécution pour agents d’IA avec OpenShell 0.1.0

NVIDIA a présenté OpenShell 0.1.0, un runtime open source conçu pour contrôler ce à quoi les agents d’IA peuvent accéder et ce qu’ils peuvent faire une fois déployés. Le système place l’isolation en sandbox, les contrôles de services, la gestion des identifiants et l’application des politiques en dehors de la charge de travail de l’agent, ce qui permet aux équipes d’ajouter des garde-fous sans réécrire l’agent lui-même.

Cette version répond à un problème opérationnel croissant : des agents capables d’écrire du code, d’utiliser des outils, d’accéder aux systèmes de l’entreprise et de continuer à agir à mesure que de nouvelles informations arrivent peuvent être utiles pour des tâches de longue durée, mais peuvent aussi modifier des données de production, exposer des informations confidentielles ou aller au-delà de la tâche qui leur a été assignée. NVIDIA indique qu’OpenShell est destiné à fournir une frontière d’exécution pour ces actions dans l’automatisation d’entreprise, la recherche, la robotique et d’autres déploiements.

Ce qu’OpenShell de NVIDIA change

NVIDIA positionne OpenShell comme une couche de contrôle plutôt que comme un nouveau framework d’agents. Il est conçu pour fonctionner avec des systèmes existants, notamment Codex, Claude Code, Pi et Hermes, tout en contrôlant leur accès aux espaces de travail, aux ressources de calcul, aux données, aux identifiants et aux services externes.

Cette séparation est au cœur de la conception du produit. Un agent peut toujours interpréter des instructions, sélectionner des outils et modifier son approche, mais le runtime environnant détermine si une opération demandée est autorisée. Cela pourrait donner aux équipes de plateforme un moyen d’appliquer des contrôles cohérents à des agents construits par différents développeurs ou basés sur différents modèles.

NVIDIA indique qu’OpenShell 0.1.0 prend en charge les opérations de sandbox, l’intégration de la gouvernance, la protection des identifiants, la vérification des politiques et un calcul flexible. Il peut être utilisé localement via une sandbox puis déployé dans une infrastructure partagée à l’aide de pilotes de calcul Docker ou Kubernetes, d’espaces de travail et de middleware d’identité.

Le runtime fait partie de la plus large Open Agent Safety Platform de NVIDIA, que l’entreprise décrit comme couvrant les couches application, runtime et infrastructure. OpenShell s’adresse spécifiquement à la couche runtime, où les requêtes sortantes d’un agent et ses interactions avec son environnement d’exécution peuvent être inspectées et restreintes.

Comment le runtime applique les autorisations

OpenShell utilise trois composants principaux. Le OpenShell Gateway gère les cycles de vie des sandboxes et les politiques à travers plusieurs agents. Le OpenShell Supervisor s’exécute aux côtés de chaque sandbox, en dehors de la charge de travail de l’agent, et vérifie les requêtes sortantes par rapport à la politique applicable. La sandbox applique des contrôles au système de fichiers et aux processus de l’agent au niveau du noyau.

Cette architecture est destinée à empêcher l’agent de simplement modifier ses propres contrôles. Les autorisations peuvent être gérées en dehors de la charge de travail, tandis que les équipes peuvent attribuer différentes capacités à des sandboxes individuelles ou à des groupes d’agents. Cela est important pour les organisations qui exploitent des flottes d’agents, où un seul ensemble d’autorisations trop large pourrait permettre qu’une erreur dans un flux de travail affecte des systèmes sans rapport.

NVIDIA met également en avant la protection des identifiants. Plutôt que d’exposer directement des identifiants à un agent, OpenShell peut médiatiser l’accès aux services et restreindre les opérations API que l’agent peut effectuer. Selon l’entreprise, cela permet aux équipes de fournir la capacité requise pour une tâche tout en conservant les identifiants sensibles en dehors de la charge de travail de l’agent.

Le système comprend un prouveur de politiques fondé sur la logique formelle. NVIDIA indique qu’il peut vérifier si les autorisations modélisées restent dans des limites définies et identifier les actions qui franchissent ces limites. C’est une approche plus solide que de s’en remettre uniquement à des prompts ou à des instructions, mais l’efficacité du résultat dépendra de la manière dont une organisation modélise complètement ses systèmes, API, identités et actions autorisées.

Éléments de preuve et affirmations derrière la publication

Les détails du produit présentés dans ce rapport proviennent de l’annonce de NVIDIA sur son Developer Blog et sont donc rapportés par le fournisseur. La source ne fournit pas de résultats de tests indépendants, de mesures de prévention des brèches, de chiffres de latence, de comparaisons des coûts d’exploitation ni d’évaluation tierce du prouveur de politiques.

NVIDIA indique que des organisations telles que Cadence, Slack et Gecko Robotics adoptent OpenShell. L’entreprise associe ces exemples à différents cas d’usage : Cadence l’utilise avec son ChipStack Autonomous RTL Design Engineer pour la conception de puces, Slack construit une plateforme d’agents à la demande sur OpenShell pour l’automatisation des tâches, et Gecko Robotics l’utilise pour gouverner des agents prenant des décisions impliquant des robots physiques.

Ces exemples indiquent l’éventail des déploiements que NVIDIA recherche, mais ne prouvent ni l’ampleur de l’adoption, ni la disponibilité en production, ni des résultats commerciaux mesurables. L’annonce ne précise pas le nombre d’agents, d’utilisateurs, de charges de travail ou de sites concernés. Les constructeurs et les acheteurs devraient donc considérer ces signaux d’adoption comme des affirmations de l’entreprise jusqu’à ce que les organisations publient davantage de détails de mise en œuvre.

La version 0.1.0 signale également un stade précoce du runtime. La disponibilité en open source permet aux développeurs d’inspecter le code, de contribuer et de tester les contrôles, mais n’établit pas à elle seule une maturité suffisante pour des environnements de production à fort enjeu. Les organisations devront évaluer la stabilité opérationnelle du projet, la charge d’intégration et sa réponse aux cas de défaillance.

Implications pour les constructeurs et les équipes d’entreprise

Pour les développeurs d’IA, OpenShell pourrait réduire le besoin d’intégrer chaque contrôle de sécurité dans le code ou le prompt d’un agent. Une frontière d’exécution peut être réutilisée lorsque le modèle sous-jacent, le framework ou les instructions de l’agent changent. Cela est particulièrement pertinent pour les équipes qui expérimentent avec plusieurs agents d’IA ou qui mettent fréquemment à jour des modèles.

Pour les équipes IA d’entreprise, la question pratique est de savoir si la politique d’exécution peut se mapper proprement aux systèmes existants d’identité, d’accès et de gouvernance. Un déploiement utile devrait répondre à des questions telles que : quel agent peut accéder à telle base de données, quelles méthodes API sont autorisées, si une requête nécessite une approbation humaine, et comment les changements de politique sont examinés et enregistrés.

Cette approche peut être particulièrement pertinente pour les agents de longue durée. Un assistant éphémère qui rédige du texte présente un profil de risque différent d’un agent qui enquête pendant des jours sur une panne logicielle, exécute des expériences, modifie des fichiers ou agit dans un environnement physique. En plaçant les contrôles en dehors de la charge de travail, OpenShell vise à limiter les conséquences des décisions évolutives d’un agent sans supprimer sa capacité à travailler sur plusieurs étapes.

Il existe aussi des compromis. Des politiques strictes peuvent réduire l’autonomie utile ou créer des frictions opérationnelles lorsque des tâches légitimes exigent de nouvelles autorisations. Des politiques trop souples ou incomplètes peuvent laisser des lacunes même lorsque le runtime fonctionne correctement. Le prouveur de politiques peut aider à identifier des conflits modélisés, mais il ne peut pas valider des hypothèses qu’une équipe n’a pas représentées dans sa politique ou son modèle d’infrastructure.

Ce qu’il faut surveiller ensuite

Les prochains signaux seront la documentation de production, les évaluations indépendantes et les preuves de la manière dont OpenShell se comporte en cas de panne ou d’attaque. Les développeurs devraient rechercher des détails sur la syntaxe des politiques, les journaux d’audit, les workflows d’approbation, les procédures de retour arrière et la prise en charge de systèmes d’identité au-delà des exemples donnés dans l’annonce de NVIDIA.

Les acheteurs d’entreprise devraient également surveiller si Cadence, Slack ou Gecko Robotics publient des résultats concrets de déploiement, notamment l’ampleur de leurs flottes d’agents, les types d’actions contrôlées et le coût opérationnel de l’application de ces politiques. L’activité GitHub du projet, le rythme des versions, la résolution des problèmes et les intégrations avec Docker, Kubernetes et les outils de gouvernance fourniront d’autres indications de maturité.

Enfin, la relation entre OpenShell et l’ensemble de l’Open Agent Safety Platform sera importante. L’annonce actuelle de NVIDIA se concentre sur les contrôles de runtime ; les acheteurs voudront comprendre comment ces contrôles s’articulent avec les garde-fous au niveau applicatif, la sécurité de l’infrastructure, la surveillance et la supervision humaine.

Point de vue de Creati.ai

La publication d’OpenShell par NVIDIA répond à une vraie lacune de déploiement : donner à un agent l’accès à des systèmes utiles sans traiter l’agent lui-même comme un administrateur de confiance. Son idée la plus déterminante est la séparation entre le comportement de l’agent et les autorisations qui régissent l’exécution.

La publication doit néanmoins être jugée comme une infrastructure dans une version précoce, et non comme une solution de sécurité complète. Sa valeur pour les constructeurs et les entreprises dépendra de la qualité des politiques, de l’intégration avec les contrôles existants, des tests indépendants et de la preuve que le runtime peut préserver la fiabilité sans rendre les workflows autonomes ingérables.