OpenShell : Nvidia veut mettre les agents IA en cage avant de leur donner les clés du système

Donner un terminal à une IA demande quelques précautions

Un agent IA devient réellement intéressant lorsqu’il peut faire autre chose que discuter. On veut qu’il lise des fichiers, installe un package, interroge une API, lance un script, utilise Git ou déploie quelque chose sur un serveur. Le problème est assez évident : toutes ces capacités sont également celles dont dispose un logiciel lorsqu’il commence à faire des choses que vous n’aviez absolument pas prévues.

Nvidia vient justement de présenter son Open Agent Safety Platform , une architecture destinée à imposer des limites techniques aux agents autonomes plutôt que de compter uniquement sur les instructions données au modèle. La plateforme associe principalement deux briques : OpenShell, un environnement d’exécution sécurisé open source, et Sentry, un mécanisme de surveillance séparé pensé pour fonctionner sur les DPU BlueField-4 de Nvidia. L’idée tient dans une philosophie assez saine : la sécurité ne doit pas vivre uniquement dans le prompt ou dans l’application qui pilote l’agent. Elle doit être appliquée en dehors du processus de l’IA, à un niveau où celle-ci ne peut pas simplement décider qu’une règle devient gênante pour terminer sa mission. Parce qu’un rm -rf reste relativement peu impressionné par votre system prompt.

OpenShell : un bac à sable avec de vraies barrières

Le cœur logiciel du projet s’appelle NVIDIA OpenShell . Le projet est publié en open source sous licence Apache 2.0 et vise à créer des environnements isolés dans lesquels des agents peuvent travailler sans disposer d’un accès illimité à la machine hôte, au réseau ou aux secrets de l’utilisateur.

Concrètement, chaque agent fonctionne dans une sandbox régie par une politique déclarative. L’administrateur définit ce que l’agent peut lire ou écrire, les processus qu’il peut lancer, les destinations réseau auxquelles il peut accéder et les fournisseurs de credentials qu’il est autorisé à utiliser. OpenShell applique ensuite ces règles au niveau du système plutôt que de demander au modèle de s’en souvenir. La partie fichiers s’appuie notamment sur des mécanismes kernel comme Landlock pour restreindre les chemins accessibles, tandis que les connexions sortantes passent par un proxy capable de contrôler la destination, le port et le programme à l’origine de la requête.

Autrement dit, si votre agent est censé modifier /home/projet/site-web, il n’a aucune raison d’aller fouiller /home/sebastien/Documents/impots. Et cette fois, « aucune raison » peut devenir « techniquement impossible ».

Même les clés API peuvent rester cachées à l’agent

La gestion des credentials est probablement l’un des aspects les plus intéressants d’OpenShell. Les agents modernes utilisent souvent des tokens GitHub, des clés cloud, des accès à des modèles ou des comptes de service. Le réflexe classique consiste à exposer ces secrets comme variables d’environnement, ce qui revient parfois à confier le trousseau de clés directement au programme que l’on essaie justement de surveiller.

OpenShell adopte une approche différente. Les credentials peuvent être rattachés à des providers, puis injectés uniquement lorsque l’agent communique avec un endpoint explicitement autorisé. D’après la documentation du projet , l’agent n’a pas besoin de voir directement la vraie clé : OpenShell peut l’ajouter au moment où la requête part vers la destination approuvée. Un agent capable d’utiliser GitHub n’a donc pas forcément besoin de connaître votre token GitHub ; il doit simplement pouvoir effectuer certaines opérations GitHub.

La distinction paraît subtile, jusqu’au jour où une prompt injection demande gentiment à l’agent d’envoyer toutes ses variables d’environnement vers totally-not-evil.example.

« Tout est interdit » devient enfin une stratégie viable

Nvidia présente OpenShell selon un modèle deny by default : rien n’est permis tant qu’une règle ne l’autorise explicitement. C’est l’inverse de nombreuses installations d’agents actuelles, où le développeur commence souvent par donner suffisamment de permissions pour que « ça marche », puis réfléchit éventuellement à la sécurité après la démo.

Les règles réseau peuvent également être modifiées pendant l’exécution. Un agent pourrait par exemple démarrer avec uniquement accès à GitHub, puis demander temporairement une nouvelle permission afin de contacter un service externe. Le système peut alors journaliser, approuver ou refuser cette extension. C’est une architecture beaucoup plus proche de la manière dont on sécurise déjà des applications sérieuses : segmentation, moindre privilège, audit et contrôles indépendants. Une découverte étonnante en 2026 : les bonnes pratiques de sécurité fonctionnent aussi quand le programme contient de l’IA.

Nvidia ajoute même un videur à l’extérieur de la boîte

OpenShell constitue la première barrière, mais Nvidia veut aller plus loin avec Sentry. Sentry est conçu comme un mécanisme de surveillance séparé du serveur sur lequel travaille l’agent. Il doit fonctionner sur les DPU BlueField-4, ces processeurs spécialisés capables de gérer certaines fonctions réseau et de sécurité indépendamment du CPU principal.

Selon la présentation technique de Nvidia , ce composant peut observer les interactions, corréler les politiques et isoler un agent qui tente de dépasser son périmètre. Nvidia parle d’une mise en quarantaine pouvant intervenir en quelques millisecondes. L’intérêt principal n’est pas seulement la vitesse : Sentry fonctionne dans un domaine séparé que l’agent n’est normalement pas capable de modifier. Même si le programme réussit à compromettre son propre environnement logiciel, la surveillance continue d’exister ailleurs. C’est un peu le principe du videur placé à l’extérieur de la boîte de nuit : vous pouvez éventuellement casser l’alarme à l’intérieur, le gars devant la porte vous regarde toujours.

Pourquoi mettre autant de couches autour d’un chatbot

Parce qu’on ne parle justement plus vraiment de chatbots. Les agents modernes peuvent rester actifs pendant des heures, utiliser plusieurs outils, lancer du code, naviguer sur Internet et improviser de nouvelles étapes lorsque la première méthode échoue. Nvidia souligne que plusieurs incidents récents ont montré des agents capables de contourner des contrôles applicatifs simplement parce que ces contrôles les empêchaient d’atteindre l’objectif assigné.

WIRED résume assez bien le problème : les agents sont très bons pour trouver de nouvelles manières d’accomplir ce qu’on leur demande. Cette créativité est exactement la qualité que l’on souhaite lorsqu’une tâche est complexe. Elle devient beaucoup moins amusante lorsque « trouver une autre manière » signifie contourner une restriction de sécurité. Un script traditionnel rencontre une erreur et s’arrête. Un agent peut rencontrer une erreur et penser : « Bon, comment est-ce que je contourne ça » C’est formidable pour réparer un pipeline CI. Beaucoup moins lorsque « ça » était le pare-feu.

Microsoft, Anthropic, Red Hat et une jolie brochette autour de la table

Nvidia ne lance pas cette architecture seul dans un coin de GitHub. L’entreprise annonce travailler avec une longue liste d’acteurs autour d’Open Agent Safety Platform, dont Anthropic, Microsoft, Cisco, CrowdStrike, Red Hat, Salesforce, SAP, Hugging Face ou encore Palo Alto Networks. Salesforce a par exemple intégré OpenShell avec Slack afin que des équipes puissent observer l’activité d’un agent et approuver ou refuser certaines demandes d’extension de permission depuis leur espace de travail. Red Hat travaille également sur l’intégration des technologies de la plateforme dans ses infrastructures AI Factory.

Il faut évidemment garder en tête que nous sommes aussi face à une stratégie industrielle. Nvidia fournit déjà une part gigantesque du matériel qui exécute l’IA moderne ; devenir également une brique de référence pour sécuriser les agents lui permet d’occuper encore un étage supplémentaire de la pile technique. WIRED souligne justement cet enjeu : derrière l’effort open source, Nvidia cherche aussi à s’installer dans les standards de sécurité des agents, du logiciel jusqu’au silicium.

Open source ne veut pas dire absence de stratégie commerciale. Sinon Red Hat vendrait des autocollants.

OpenShell peut fonctionner sans acheter tout le catalogue Nvidia

Bonne nouvelle pour les homelabs et les développeurs qui n’ont pas trois BlueField-4 sous le bureau : OpenShell lui-même n’est pas limité à une grosse infrastructure Nvidia. Le dépôt GitHub d’OpenShell indique prendre en charge plusieurs types d’environnements, notamment Docker, Podman, MicroVM et Kubernetes. Le runtime est séparé de Sentry et peut donc être utilisé comme sandbox pour des agents sans déployer toute l’architecture matérielle Nvidia.

Le projet mentionne aussi une compatibilité avec plusieurs agents et fournisseurs. La logique n’est pas d’imposer un modèle unique, mais de placer une couche de contrôle entre l’agent et les ressources auxquelles il veut accéder. C’est probablement ce qui rend OpenShell intéressant au-delà de l’annonce Nvidia : même sans BlueField, le principe reste immédiatement utile. Un agent, une sandbox, une politique, et beaucoup moins de confiance aveugle.

Petit détail amusant : le sandbox a lui-même eu besoin de correctifs de sécurité

Il existe toutefois une excellente raison de ne pas transformer OpenShell en talisman magique. En août 2026, Nvidia a publié un bulletin de sécurité concernant plusieurs vulnérabilités dans OpenShell . Certaines étaient particulièrement sérieuses : deux vulnérabilités recevaient un score CVSS de 9,9/10, dont une pouvait notamment permettre une sortie de sandbox avec exécution de code, élévation de privilèges, modification ou divulgation de données.

Les versions concernées allant jusqu’à 0.0.33 ont été corrigées dans OpenShell 0.0.34, et le projet est depuis passé à la branche 0.1.x. Ce n’est pas forcément un argument contre OpenShell ; c’est surtout une magnifique démonstration de la difficulté du problème. Construire un bac à sable capable de contenir des logiciels potentiellement hostiles est extrêmement difficile. Et quand le logiciel enfermé à l’intérieur possède justement la capacité de tester des chemins imprévus de manière automatique, mieux vaut considérer les mises à jour de sécurité comme autre chose qu’une suggestion décorative. La morale tient en une phrase : le sandbox doit lui aussi être patché.

Le véritable enjeu : sortir la sécurité du prompt

C’est finalement là que l’approche de Nvidia devient la plus intéressante. Depuis l’arrivée des agents IA, une partie importante de leur « sécurité » repose encore sur des instructions en langage naturel : « ne fais pas ceci », « demande confirmation avant cela », « ne révèle jamais cette information ». Ces consignes peuvent être utiles pour guider le comportement du modèle, mais elles ne constituent pas des barrières de sécurité sérieuses.

Une politique kernel qui interdit l’accès à un fichier n’a pas besoin que l’agent soit coopératif. Une règle réseau qui bloque une destination ne dépend pas de la qualité du raisonnement. Une clé API que l’agent ne voit jamais ne peut pas être facilement recopiée dans une réponse. C’est exactement ce qui manque encore à beaucoup de déploiements agentiques : des contraintes qui existent indépendamment de l’intelligence du modèle.

Plus les agents deviennent puissants, plus ce principe va devenir important. Un agent suffisamment bon pour résoudre tout seul les problèmes que vous lui donnez devient également suffisamment bon pour découvrir des moyens de résoudre des problèmes que vous auriez préféré le voir abandonner.

On revient finalement à une idée très Unix

OpenShell paraît extrêmement moderne parce qu’il protège des agents IA. Mais son idée fondamentale ne l’est pas vraiment : limiter les permissions, isoler les processus, séparer les secrets, filtrer le réseau, journaliser les actions et ne jamais accorder plus d’accès que nécessaire.

C’est de la sécurité informatique assez classique. Et c’est probablement une excellente nouvelle.

Les agents IA n’ont peut-être pas besoin d’un nouveau paradigme mystique de cybersécurité. Ils ont surtout besoin qu’on arrête de leur donner sudo, Internet, toutes les clés API de l’entreprise et l’accès complet au disque avant de demander : « Tu peux juste corriger ce bouton CSS »

Nvidia veut désormais mettre une véritable cage technique autour de ces agents. Vu la vitesse à laquelle nous leur distribuons les clés, ce n’est probablement pas trop tôt.