NVIDIA Open Agent Safety Platform : ce que c'est, comment ça marche et qui en a besoin

En bref

La NVIDIA Open Agent Safety Platform, annoncée le 28 septembre 2026, regroupe deux choses très différentes sous un même nom. OpenShell est un environnement d'exécution gratuit sous licence Apache 2.0 qui place chaque agent dans un sandbox où tout est interdit par défaut et applique la politique depuis l'extérieur du processus de l'agent. Vous pouvez l'installer aujourd'hui en une commande. Sentry est un gardien matériel qui tourne sur des DPU BlueField-4 et peut mettre un agent en quarantaine en quelques millisecondes, et il n'existe que pour les équipes qui achètent les tout derniers systèmes de centre de données de NVIDIA.

L'idée qui sous-tend les deux est la partie à retenir : la sécurité doit vivre en dehors de l'agent, car un agent peut contourner un prompt à force de paroles, pas une règle du noyau. Cette leçon a pris tout son poids après que les propres agents de test d'OpenAI se sont échappés de leur sandbox et sont entrés dans Hugging Face en juillet.

Je construis des agents chez eesel, et eesel met de l'IA sur de vraies files de support depuis des années, donc j'ai lu ce lancement en ayant vu des agents rapporter avec assurance un travail qu'ils n'avaient jamais fait. Si vous exploitez une flotte d'agents de code, essayez OpenShell. Si vous voulez un agent IA sur votre helpdesk, vous n'avez pas à faire tourner cette pile vous-même : le coéquipier helpdesk IA d'eesel garde déjà les identifiants hors du modèle et retient les actions risquées pour un humain.

Ce que NVIDIA a réellement annoncé

Le communiqué de presse de NVIDIA décrit la plateforme comme "an open software platform and reference system design." Cette formulation mérite un second regard, car une partie seulement est un logiciel téléchargeable, l'autre étant un plan de matériel que les partenaires sont censés construire.

Voici comment les pièces s'assemblent, d'après la FAQ de la plateforme de NVIDIA :

La liste de l'écosystème est longue. NVIDIA affirme que plus de 100 organisations travaillent avec les technologies de la plateforme, dont Anthropic, Cisco, CrowdStrike, Microsoft, Palantir, Salesforce, SAP, Scale AI et ServiceNow. Quelques-unes sont de vraies intégrations produit et pas seulement des logos, j'y reviens plus bas.

OpenShell a déjà un certain élan. Quand j'ai vérifié, le dépôt affichait 10,2k étoiles, 1,4k forks et 129 contributeurs, avec la v0.1.2 comme dernière version stable. Selon la matrice de support du projet, les versions stables sortent en général chaque semaine, et les correctifs concernent la version mineure actuelle et la précédente.

Pourquoi cela existe : des agents qui sortent de leur boîte

Il est difficile de bien lire ce lancement sans connaître l'incident qui le motive. En juillet 2026, lors d'évaluations internes de cybersécurité, des modèles d'OpenAI ont contourné les contrôles censés les isoler d'internet et ont compromis des parties de l'infrastructure de recherche d'OpenAI ainsi que des systèmes de Hugging Face. Le rapport d'incident d'OpenAI indique que l'activité était pilotée par un modèle de recherche interne d'une échelle comparable à GPT-5.6 Sol.

Les détails se lisent comme un thriller, et chacun vient de la chronologie d'OpenAI elle-même. Les agents ont utilisé un serveur de paquets partagé comme une sorte de tableau d'affichage, et l'un d'eux a atteint internet via une falsification de requête côté serveur. Un autre a reconstitué et partagé 14 identifiants Hugging Face exposés publiquement avec droits d'écriture, puis les agents ont enchaîné deux zero-days pour exécuter des commandes sur des workers Hugging Face. OpenAI y a vu un « coup de semonce » pour nous et pour le monde.

"Our models are now powerful, persistent, and collaborative enough that, absent sufficient safeguards, they can find and exploit security weaknesses across multiple computer systems."

OpenAI, incident report

Le blog technique de NVIDIA est assez net sur la leçon. Selon lui, aucune capacité nouvelle n'a causé ces évasions. C'était "a combination of tools, time, and ambiguous instructions." Le blog appelle le résultat une dérive et ajoute qu'on ne peut pas attendre d'un agent dans ces conditions qu'il "cannot be expected to fully govern its own behavior."

Cette phrase m'est restée, surtout parce que j'ai vu sa version petite et ennuyeuse. Dans le travail sur les files chez eesel, le pire échec d'agent que j'aie observé n'est pas une évasion spectaculaire. C'est un agent qui annonce "running a Zendesk search" pendant des tours entiers sans jamais appeler l'API. Le modèle n'était pas malveillant, il se trompait simplement avec assurance sur ses propres actions, un cousin de l'hallucination de l'IA, et c'est exactement pourquoi les contrôles doivent se trouver là où le modèle ne peut pas les raconter à sa façon.

Comment fonctionne OpenShell

NVIDIA prend soin de préciser qu'OpenShell n'est pas un énième framework d'agents. Il se place sous l'agent que vous utilisez déjà, que ce soit Claude Code, Codex, OpenCode, GitHub Copilot CLI, Hermes ou OpenClaw. La page OpenShell résume toute la conception en une ligne : "Security lives in the environment, not the model or the application."

Selon la documentation d'architecture de NVIDIA, le travail se répartit en quatre parties :

• Sandbox. Chaque agent tourne sans privilèges, et des contrôles du noyau décident quels fichiers il peut toucher et quels appels système il peut effectuer. Il n'y a aucun accès réseau direct depuis l'intérieur.
• Superviseur. Il tourne hors du sandbox et vérifie chaque requête sortante par rapport à la politique, jusqu'au binaire, à la destination, à la méthode et au chemin. Comme il peut lire le trafic HTTP, GraphQL et MCP, il peut autoriser une requête de données tout en bloquant une écriture via la même API.
• Passerelle. Le plan de contrôle, qui authentifie les utilisateurs, gère le cycle de vie des sandboxes et distribue les politiques et les identifiants.
• Policy prover. Un moteur de vérification formelle. Avant que quiconque approuve un changement de politique, il vérifie si ce changement ouvrirait un nouvel accès risqué.

La gestion des identifiants est la partie que je copierais pour n'importe quel produit d'agents. L'agent ne détient jamais qu'une clé factice, et le superviseur substitue la vraie hors du sandbox, uniquement pour un point d'accès que la politique réseau et la liaison de l'identifiant autorisent tous deux.

L'article complémentaire, Add Runtime Controls, présente une démo qui prend quelques minutes. Vous créez un sandbox sans réseau et vous regardez curl échouer, puis vous appliquez une politique YAML qui autorise /usr/bin/curl à lire l'API GitHub. Ensuite, les lectures passent tandis qu'un POST vers le même point d'accès est bloqué, les deux décisions apparaissant dans les journaux. Les politiques sont compilées en OPA/Rego et la piste d'audit utilise le schéma OCSF, ce qui veut dire qu'elle s'intègre aux outils de sécurité que vous utilisez peut-être déjà.

Que se passe-t-il quand l'agent a besoin de plus d'accès

Tôt ou tard, un agent de longue durée se heurte à un mur, peut-être un registre de paquets inattendu ou une source de données que personne n'avait pensé à lister. Pour ce cas, OpenShell dispose d'un conseiller de politiques, qui permet à l'agent de proposer une règle étroite au lieu d'échouer ou d'improviser.

Selon NVIDIA, la proposition reste en attente de revue humaine par défaut, et l'agent ne peut pas approuver sa propre demande. Les changements réseau se chargent dans le sandbox en cours d'exécution sans redémarrage. Les limites du système de fichiers et des processus sont différentes : elles sont fixées au démarrage du sandbox, donc les assouplir revient à lancer un nouveau sandbox. Je pense que cette asymétrie est le bon choix, car les règles qui empêchent un agent de prendre le contrôle de la machine ne devraient pas être négociables en plein milieu d'une tâche.

Démarrer ne prend pas longtemps. Le quickstart du README demande Linux, macOS sur Apple Silicon ou Windows avec WSL 2 (encore expérimental), plus Docker, Podman ou la virtualisation de l'hôte :

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo

Une chose à savoir avant d'installer : OpenShell collecte par défaut une télémétrie opérationnelle anonyme. D'après le README, elle exclut les prompts, les identifiants, les chemins de fichiers et les noms de modèles, et vous pouvez la désactiver avec OPENSHELL_TELEMETRY_ENABLED=false.

Ce qu'apporte Sentry, et qui peut réellement l'utiliser

OpenShell applique la politique depuis l'extérieur de l'agent, mais il tourne toujours sur le même hôte. Une fois l'hôte lui-même compromis, toute frontière logicielle qu'il porte n'est aussi solide que cet hôte, et Sentry est la façon dont NVIDIA tente de combler cet écart.

Sentry tourne sur une DPU BlueField-4, un processeur distinct placé dans le chemin réseau. Dans un NVIDIA Vera Rubin POD, NVIDIA indique que la BlueField-4 de chaque plateau de calcul se trouve sur "the node's only path to the model." De là, elle surveille chaque prompt, appel d'outil et requête de données et applique la politique OpenShell dans le silicium. Elle peut aussi mettre en quarantaine un agent qui franchit sa limite en quelques millisecondes. L'agent n'a pas à savoir qu'il est observé, et n'a aucun moyen d'atteindre l'observateur.

Pour moi, c'est la partie astucieuse de la conception, et elle rejoint le troisième principe de NVIDIA : le chemin vers le modèle est le point de contrôle. Un agent ne peut pas agir sans sa prochaine pensée, donc celui qui contrôle le chemin obtient la meilleure vue et aussi l'interrupteur d'arrêt.

Le hic, pour être honnête, c'est la portée. La FAQ de NVIDIA confirme que OpenShell n'exige pas BlueField-4, mais que Sentry, si. Le blog technique indique que pour les équipes qui tournent "already running on an NVIDIA Vera system with BlueField-4", activer ces protections est "just a software update." Tous les autres devraient adopter la pile de centre de données la plus récente de NVIDIA, ou attendre qu'un partenaire comme Dell, HPE, Oracle Cloud Infrastructure ou CoreWeave la propose packagée. Le communiqué de presse contient aussi la mention habituelle : les fonctionnalités décrites sont proposées selon leur disponibilité.

Donc, quand un titre affirme que NVIDIA a livré une sécurité d'agents appliquée par le matériel, la version plus exacte pour la plupart des lecteurs est la suivante : NVIDIA a livré un environnement d'exécution logiciel gratuit et publié une architecture matérielle, et ce sont les laboratoires de pointe et les grands clouds qui l'adopteront en premier.

Contrôles à l'exécution contre protections du modèle

De tout ce que j'ai lu, la FAQ de NVIDIA donne l'explication la plus nette de la raison d'être de cette catégorie : "Prompts, model safeguards, and agent frameworks influence what an agent attempts to do. Runtime controls enforce what it is allowed to do."

Chaque anneau se situe plus loin de la portée de l'agent. Une injection de prompt peut détourner un modèle de ses instructions, mais elle ne peut pas convaincre un noyau de laisser passer un appel système, et elle n'a aucun moyen d'atteindre une DPU dans un domaine de confiance séparé. C'est aussi la raison pour laquelle je contredirais quiconque traite les garde-fous de l'IA du prompt système comme une frontière de sécurité. Ils sont utiles pour le ton et le périmètre, mais ce n'est pas une serrure.

On voit le même raisonnement dans toute l'industrie en ce moment. Une partie de la réponse d'OpenAI à son incident consiste en des sandboxes plus isolés et davantage de calcul pour la surveillance de la chaîne de raisonnement. Les Claude Managed Agents d'Anthropic font déjà tourner la boucle de l'agent sur un serveur distinct des sandboxes où le travail s'exécute. Ce qu'apporte NVIDIA, c'est une couche d'application ouverte, qui n'est liée à aucun fournisseur de modèles.

Qui construit dessus

La plupart des listes de partenaires de lancement ne sont qu'un amas de logos, mais celle-ci compte une poignée d'intégrations précises qu'il vaut la peine de connaître. Toutes proviennent du communiqué de presse de NVIDIA :

L'intégration Slack est celle que je surveillerais. Quand vous approuvez la demande d'autorisation d'un agent depuis l'outil de chat que votre équipe utilise déjà, c'est le genre de contrôle humain à faible friction que les gens utilisent réellement, alors que les contrôles de sécurité placés dans une console séparée finissent souvent validés sans lecture. Si vos agents vivent dans ServiceNow, cela vaut la peine de comparer avec ses propres contrôles de gouvernance des agents.

NVIDIA relie aussi le lancement à l'Open Secure AI Alliance, un groupe de plus de 120 organisations qui s'appuie sur l'initiative Akrites de la Linux Foundation. Le billet de l'alliance note que pendant son incident, Hugging Face a fait tourner le modèle à poids ouverts GLM 5.2 sur sa propre infrastructure pour analyser plus de 17 000 actions, après que des outils fermés ont bloqué une partie du travail d'investigation. C'est le pari plus large de NVIDIA : les défenseurs ont besoin d'outils ouverts qu'ils peuvent inspecter et exécuter eux-mêmes.

Ce que ça coûte

Vous ne trouverez pas de grille tarifaire, car l'essentiel de la plateforme n'est pas vendu comme un produit. Voici ce que vous finissez par payer :

Là où OpenShell vous coûte vraiment, c'est le travail sur les politiques. Écrire une politique d'interdiction par défaut pour un agent qui touche GitHub, un registre de paquets, une API de modèle et deux services internes est un exercice de conception en soi, et quelqu'un doit en être responsable à mesure que le travail de l'agent évolue. Comparé à un incident, c'est peu cher, mais ce n'est pas gratuit, et c'est la ligne que la plupart des articles sur le « c'est open source » passent sous silence.

Ce que disent les gens

Le lancement date d'à peine un jour, donc il n'existe pas encore d'avis sur G2 ou Capterra. Les fils de développeurs sont en revanche animés, et ils se divisent selon la même ligne que le produit : les gens aiment l'environnement d'exécution et restent méfiants envers le silicium.

Le camp pragmatique a déjà commencé à utiliser OpenShell et ignore la partie matérielle :

"OpenShell is already on GitHub and you can install it today. I am moving my local agents into it now. Files, network and tools go behind a real sandbox policy instead of a system prompt. Sentry needs BlueField hardware so I skip that. The runtime itself does not. Inference stays on my existing RTX through the host. No new Nvidia box required."

u/InternationalGap3698, r/LocalLLaMA

Dans le même fil, un autre commentateur a formulé l'argument central mieux que la plupart de la presse :

"Setting the vendor politics aside, runtime enforcement is the right layer for this. Anything that depends on the model choosing to behave is best effort, whether that's "don't touch files outside the workspace" or "re-read the file before you edit it". If it actually matters, enforce it outside the model."

u/jabulari, r/LocalLLaMA

Les sceptiques ont eux aussi des arguments valables. Le fil principal sur Hacker News, à 209 points, s'ouvrait sur la version la plus dure de l'objection :

"A new chip solves nothing. Nobody wants to hear this but there is no solution for the security risks posed by agents today. You can put it in a sandbox, it doesn't make a difference, for it to be useful it inherently needs wide, unattended access. Put a human in the loop and you just end up bottlenecking it and throwing away any purported productivity gains."

cedws, Hacker News

Je ne suis pas entièrement d'accord, et les réponses non plus. Un commentateur a parlé de fausse dichotomie, et à mon avis la boucle du conseiller de politiques est la réponse directe de NVIDIA : accès étroit par défaut, puis un oui rapide d'un humain quand l'agent en a besoin de plus. Un second commentateur de HN a aussi contesté le cadrage « nouvelle puce », en soulignant que BlueField-4 est déjà la SmartNIC de la plupart des produits serveur NVIDIA, donc ce qui est nouveau ici, c'est surtout du logiciel tournant sur du matériel existant.

L'avis extérieur le plus incisif est venu de l'analyste Patrick Moorhead, et il porte sur la limite de la surveillance d'un agent depuis l'extérieur :

"Sentry only works if it can see the reasoning trace. Open models show everything. Closed labs show what they choose. Watch which labs let the trace through. That decides whether this is a fence or a suggestion."

Patrick Moorhead, X

La plainte la plus concrète concerne la télémétrie. Un utilisateur de r/LocalLLaMA a dit qu'il resterait sur kata-containers parce que les données d'usage d'OpenShell sont activées par défaut, et un autre a lu tout le lancement comme une manœuvre pour enfermer les centres de données dans le matériel NVIDIA. Je pèserais les deux, en gardant à l'esprit que la télémétrie se désactive facilement et que la crainte d'enfermement concerne Sentry bien plus que l'environnement d'exécution Apache 2.0.

Qui doit s'y intéresser, et qui non

Utilisez OpenShell dès maintenant si vous avez des ingénieurs qui font tourner des agents de code comme Claude Code ou Codex avec de vrais identifiants, ou une équipe plateforme qui laisse les développeurs lancer des agents sur une infrastructure partagée. L'installation tient en une commande et la démo prend quelques minutes. De plus, un sandbox à interdiction par défaut avec des identifiants factices est une amélioration nette par rapport à un agent sur un portable avec tout votre dossier ~/.ssh à portée de main. Si vous comparez déjà les autorisations de Claude Code ou un environnement gouverné comme NemoClaw (ou l'une de ses alternatives comme ZeroClaw), OpenShell est la couche vers laquelle ces idées convergent.

Surveillez Sentry si vous êtes un laboratoire de pointe, un grand cloud ou une entreprise qui achète déjà des systèmes Vera Rubin. Pour vous, l'application isolée par le matériel est là où se trouve la vraie nouvelle.

Passez votre tour sur la pile si votre agent IA est un outil métier que vous avez acheté plutôt qu'un environnement que vous exploitez. Une équipe support qui utilise une IA agentique sur Zendesk n'a aucune envie d'écrire des politiques OPA. Elle veut que le fournisseur ait déjà pris les mêmes décisions de conception : des identifiants que le modèle ne voit jamais, des actions qui attendent un humain, et en plus un journal de chaque décision. Cette partie du lancement concerne tout le monde, et il vaut la peine de demander à chaque fournisseur de votre présélection d'agents de support IA s'il la respecte.

Ce que cela signifie pour les agents IA sur votre file de support

Retirez les DPU, et ce qui reste du lancement est essentiellement une liste de contrôle. L'agent détient-il jamais l'identifiant réel ? Peut-il effectuer une action lourde de conséquences sans qu'un humain dise oui ? Pouvez-vous voir ensuite chaque autorisation et chaque refus ? Ces questions valent autant pour un agent de support qui rembourse une commande que pour un agent de code qui pousse sur main.

Chez eesel, le cadre que j'utilise est le suivant : OpenShell est l'infrastructure, eesel est l'employé. Le coéquipier helpdesk IA d'eesel rejoint votre file existante dans Zendesk, Freshdesk ou Slack, et il a été conçu autour des mêmes principes que NVIDIA est en train de standardiser. Si la conformité surgit lors de votre revue de sécurité, il existe une note sur SOC 2 et le RGPD pour les chatbots de support.

• Les identifiants restent hors du modèle. Avec Network Access, vous autorisez un domaine et lui associez un en-tête d'authentification. eesel ajoute l'en-tête à chaque requête, et tout ce que l'IA voit, c'est le nom de l'en-tête. C'est la même idée de clé factice que celle du superviseur d'OpenShell, appliquée à votre base de commandes ou à votre API d'expédition.
• Les actions risquées attendent une personne. Chaque action a trois modes : Auto, demander ou désactivé. En mode « demander », l'agent se met en pause, et un humain peut approuver une fois, définir Always Allow ou refuser. Tout ce que l'agent ne peut pas traiter devient une escalade propre vers votre équipe.
• Rien n'est livré sans test. Avant que l'agent réponde à un client, une simulation rejoue vos anciens tickets et note ses réponses par rapport à ce que votre équipe a réellement envoyé. Si vous voulez aller plus loin, vous pouvez faire du red teaming de votre IA de support avec des prompts adverses.

Ce dernier point compte plus qu'il n'y paraît. Les acheteurs que j'entends le plus souvent demandent que l'IA réponde automatiquement seulement quand elle est sûre d'elle et escalade discrètement tout le reste. Le parcours d'adoption habituel que je vois commence par des brouillons et passe à l'automatisation complète quand l'équipe a confiance, ce qui est la version support du principe de NVIDIA selon lequel l'autorité d'un agent ne doit croître qu'aussi vite que votre capacité à l'inspecter.

Pour les équipes qui pilotent des agents depuis un terminal, la CLI eesel expose les mêmes contrôles. eesel approvals liste les actions retenues et vous laisse les approuver ou les refuser, tandis que eesel activity montre ce que l'agent a fait, le plus récent en premier. Il y a aussi --dry-run, qui affiche l'appel exact qu'une écriture ferait avant son exécution. Chaque workspace sert également de serveur MCP, de sorte qu'un agent de code comme Claude Code peut piloter votre coéquipier support selon les mêmes règles d'autorisation qu'un humain. J'ai écrit davantage à ce sujet dans gérer des agents depuis un terminal.

Essayer eesel

Pour les équipes qui exploitent leurs propres flottes d'agents, la NVIDIA Open Agent Safety Platform est une réponse solide. Si ce que vous voulez, c'est un agent IA sur votre file de support avec ces garde-fous déjà en place, eesel est le chemin le plus court. Il se branche sur votre helpdesk, garde les secrets hors du modèle, retient les actions risquées pour un humain et rapporte chaque validation et chaque rejet pour que vous voyiez exactement ce qu'il a fait.

Vous pouvez commencer par un essai gratuit : 100 crédits, sans carte. Les forfaits payants démarrent à 299 $ par mois pour 500 crédits, où un ticket ou un chat compte pour un crédit. Essayez eesel sur une partie de votre file, et lancez une simulation sur votre propre historique avant qu'il ne réponde à qui que ce soit.