Avec OpenShell, Nvidia applique la logique « zero trust » aux agents IA

Sous le capot, OpenShell n’a rien de magique

OpenShell applique in fine une politique « zero trust » aux agents IA. Les outils ne sont pas nouveaux : les spécialistes de la sécurité de microservices les connaissent très bien. L’on peut s’étonner que les fournisseurs de LLM n’aient pas appliqué ce principe aux agents avant que Nvidia le décrive dans un design de référence.

OpenShell est présenté comme un runtime privé pour exécuter une flotte d’agents IA tout en contrôlant l’accès aux données, aux processus, aux secrets et au réseau.

Le runtime, c’est-à-dire le data plane, intègre un sandbox et un superviseur. En dehors de la frontière de sécurité, le bac à sable peut accueillir des outils agentiques (Claude Code, Pi, OpenCode, Codex), des frameworks de type Ollama, des processus longue durée, voire de petits LLM.

Chaque agent est exécuté dans son environnement isolé dont les contrôles résident dans le kernel Linux. « Notre approche est agnostique. OpenShell fonctionne avec les VM, les microVM, les conteneurs et les pods Kubernetes. Nous l’adaptons à toutes les technologies d’isolation du marché », indique Justin Boitano.

Nvidia prend en charge Linux (Debian/Ubuntu) sur les processeurs x86 et aarch 64, macOS et, dans une version expérimentale, Windows via WSL2.

Une passerelle est considérée comme le control plane de ce système et fait le lien entre le CLI/l’interface utilisateur et les sandbox (les agents IA) en lien avec le superviseur.

Cette gateway gère le cycle de vie des sandbox et des règles d’accès. Ces règles sont écrites par défaut en YAML. Elle semble compatible avec le moteur de politiques OPA (Open Policy Agent) et son DSL Rego.

Au sein de la passerelle, un solveur mathématique SMT (Z3) est utilisé pour s’assurer l’agent IA ne sorte pas de ses gonds. Plus particulièrement, « Il signale les modifications telles que les nouvelles autorisations d’accès, les nouvelles méthodes HTTP ou l’accès aux points de terminaison de métadonnées dans le cloud », indique Nvidia dans sa documentation. « Toute anomalie bloque l’approbation automatique ». Une commande permet par ailleurs de vérifier la conformité de ces politiques réseau depuis un environnement CI. Des règles qui s’appliquent de la couche L4 à L7, précise Justin Boitano.

Lancé avant le sandbox dans l’ordre de démarrage du runtime, le superviseur se charge d’évaluer l’application des politiques, transmet les authentifiants, résout les adresses DNS, ouvre les connexions autorisées et s’assure de sa connexion permanente avec la gateway. « Le superviseur et le sandbox communiquent au moyen d’un protocole authentifié, basé sur HTTP/2 », précise la documentation. Au sein de la gateway, un driver « compute » est chargé de « déterminer la couche de transport – TCP pour Kubernetes, un socket Unix pour Docker et Podman, ou vscock pour les microVM ». Les authentifiants sont des paires de jetons jetables (JWT) signés par la gateway, qui sont transmis via MTLS au sandbox.

Les requêtes sortantes autorisées permettent d’appeler les outils et les LLM distants, via des API et des serveurs MCP.

Les fonctionnalités seccomp intégrées au kernel Linux sont utilisées pour restreindre les appels système. Landlock sert à limiter l’accès aux fichiers. Elles peuvent être activées à l’aide de filtres BPF.

« Toutes les actions d’un agent sont traçables », ajoute le dirigeant. Dans le détail, les événements de sécurité et la télémétrie peuvent être collectés depuis la gateway, les sandbox et les superviseurs à l’aide de Prometheus, OpenTelemetry et les systèmes prenant en charge le format JSON OCSF (Open Cybersecurity Schema Framework).

Le schéma présenté dans la documentation prévaut pour un déploiement local, sur la machine d’un développeur. Dans ce cas-là, trois conteneurs Docker ou Podman suffisent. En apparence, la partie la plus complexe, semble la gestion des règles afin d’éviter les blocages intempestifs et gérer la sécurité.Pour Kubernetes ou des machines virtuelles, c’est une autre paire de manches. Il faut une VM ou un Pod par agent et la même chose pour le superviseur. Sans compter les configurations spécifiques, comme avec OpenShift. Il faut aussi configurer la durée de vie des conteneurs, des pods ou des VM.

Une architecture de référence supportée par Red Hat et Microsoft

C’est justement là où l’architecture de référence présentée lors de la GTC intervient. Elle introduit le concept d’espace de travail agentique sécurisé.

Il s’agit de décrire la manière dont OpenShell interagit avec le SIEM, la brique SSO et les outils des entreprises. Nvidia recommande d’installer sur les ordinateurs des employés ou dans le cloud une VM managée par utilisateur, contenant le bac à sable et le superviseur. Le harnais IA (Claude Code, OpenCode, Pi, etc.) et les outils locaux (appels de fonctions, hooks, serveurs MCP, skills) sont dans le runtime. Les drivers permettent de gérer l’accès à la puissance de calcul, dont les accélérateurs et les cartes graphiques des PC ou des data centers.

Le tout est accessible depuis l’IDE, le navigateur ou le terminal, après s’être authentifié. Une couche de contrôle distante – le control plane – doit permettre de gérer les politiques, de récupérer la télémétrie, d’analyser les incidents et d’activer, si nécessaire des kill switches.

Pour l’instant, Red Hat propose un déploiement qui fait le lien entre les ordinateurs des usagers et une instance on-prem d’OpenShift. Le fournisseur utilise ses briques de virtualisation, et Git comme control plane. Microsoft décline un déploiement cloud en s’appuyant sur des VM Azure éphémères contrôlées depuis sa console Azure Resource Manager, Azure Key Vault pour la gestion des clés et Entra ID pour les accès. Anthropic est l’un des premiers à mettre en place cette architecture pour ses propres besoins.

Sentry, un module pour les fournisseurs de LLM

Si elles ne sont pas nécessaires pour exécuter OpenShell, Les puces de Nvidia sont donc « complémentaires » à ces architectures, dixit Justin Boitano.

Il faut bien que Nvidia fasse fonctionner son écosystème et favorise la vente de hardware. D’ailleurs, Jensen Huang s’est évertué à décliner les gammes Vera Rubin, DGX Station, DGX Spark et RTX Spark en lien avec l’architecture de référence OpenShell.

Nvidia a également annoncé Confidential Bare Metal, une option de déploiement pour des acteurs comme OpenAI, Anthropic, Mistral, Cohere ou Google. Il s’agit de s’appuyer sur la racine de confiance matérielle pour protéger l’exécution des charges de travail sur les racks Grace Blackwell NVL72, ainsi que sur les serveurs DGX et HGX Rubin NVL8. Cette option réduit d’environ 5 % la vitesse et la latence d’un cluster doté de huit GPU B200.

« Les clients veulent avoir l’assurance de pouvoir exécuter une machine virtuelle sur une infrastructure qui ne leur appartient pas, sans que personne ne puisse y accéder », affirme Justin Boitano. « Les fournisseurs de LLM souhaitent également pouvoir transférer un modèle vers une infrastructure qu’ils n’exploitent pas et être en mesure de le déployer sur celle-ci ».

En revanche, Sentry, encore indisponible, n’est pas pour tout le monde. Ce logiciel de défense supplémentaire s’exécutant sur les futures puces DPU Bluefield-4 de ses cartes réseau est davantage destiné aux fournisseurs de LLM lors de l’entraînement et aux systèmes les plus critiques.

« Dans 90 % des cas, il suffit d’intégrer le harnais de l’agent dans le sandbox », conçoit Justin Boitano. « Mais lorsque vous souhaitez supprimer les garde-fous des modèles, ou effectuer un préalignement, c’est-à-dire une évaluation des modèles, vous avez besoin de cette deuxième couche de protection pour garantir que le système échoue en toute sécurité ».

Ni Sentry, Bluefield-4 ou OpenShell ne sont des réponses parfaites aux menaces. Le dirigeant chez Nvidia reconnaît sans hésiter que cela n’existe pas. Cela dit, d’après les tests d’Hugging Face évoqué par le dirigeant, le framework open source OpenShell aurait pu suffire à prévenir l’incident chez OpenAI. Et les échanges entre les membres de l’écosystème sont essentiels pour renforcer le niveau de sécurité, considère-t-il.

Reste à chiffrer le prix d’une telle protection, mise en œuvre par Nvidia et ses partenaires. Que ce soit en matière de sécurité ou d’IA agentique, les investissements dans l’open source du géant fabless n’ont rien d’une activité philanthropique. Ils visent à alimenter un catalogue en pleine expansion.

« Les licences logicielles vont devenir un pilier de plus en plus important de notre activité », annonce Jensen Huang, lors d’un point presse. « Nous facturerons un montant fixe par GPU et par an – environ 2 000 dollars, par exemple – pour utiliser l’ensemble des logiciels NVIDIA qui font fonctionner des agents sur les usines IA », déclare-t-il.

En matière sécurité des agents IA, Nvidia n’est pas seul. Solo.io propose sa propre passerelle pour le trafic agentique (agentgateway) et une extension Kubernetes pour la gestion de l'identité et de la sécurité des agents (Kagent). Docker et Google Cloud ont développé également leurs propres runtimes agentiques durcis.