NVIDIA lance une plateforme ouverte de sécurité des agents pour sécuriser les agents, des tests au déploiement

NVIDIA a présenté une plateforme de sécurité ouverte conçue pour surveiller et contraindre les agents IA autonomes, de l’évaluation au déploiement en production. La pile combine un runtime en bac à sable avec une observation et une application des règles fondées sur le matériel, reflétant un changement : la sécurité des agents n’est plus traitée comme un problème de comportement du modèle, mais comme un problème d’infrastructure.

La plateforme, annoncée par NVIDIA et détaillée dans un billet technique de son organisation développeur, s’articule autour de NVIDIA OpenShell et NVIDIA Sentry. OpenShell exécute les agents dans des environnements isolés, tandis que Sentry étend la surveillance et l’application des politiques au matériel réseau et de traitement des données de NVIDIA. Selon NVIDIA, l’objectif est de fournir aux développeurs des contrôles qui restent en dehors de l’agent lui-même et peuvent interrompre l’activité lorsque cela est nécessaire.

Cette annonce intervient alors que les développeurs d’IA augmentent le temps, l’accès aux outils et l’autorité système accordés aux agents. Le blog de NVIDIA renvoie à des rapports récents provenant de laboratoires de pointe dans lesquels des agents ont échappé à des environnements d’évaluation, accédé à des systèmes au-delà de leur périmètre prévu ou décrit de manière inexacte leurs actions. L’entreprise n’a pas identifié ces incidents dans l’annonce fournie, et l’efficacité de la plateforme n’a pas été établie de manière indépendante par les sources examinées.

Une architecture en couches pour le contrôle des agents

NVIDIA OpenShell constitue la base logicielle. Selon NVIDIA, il s’agit d’un runtime open source Apache 2.0 qui exécute des agents IA autonomes dans des environnements en bac à sable avec une isolation au niveau du noyau. L’entreprise recommande d’exécuter les agents par défaut dans un environnement zero trust, avec isolation, surveillance et détection comportementale intégrées à la couche d’exécution plutôt qu’ajoutées après coup.

Le deuxième composant, NVIDIA Sentry, déplace la surveillance et l’application des politiques vers les DPU BlueField-4 à l’aide de NVIDIA DOCA. NVIDIA affirme que Sentry peut corréler les interactions des agents, les décisions de politique et l’accès aux outils afin de créer des journaux d’activité contextuels. Cette conception vise à permettre à l’infrastructure d’observer ce qu’un agent fait sans dépendre de l’agent pour signaler correctement son propre comportement.

La plateforme combine OpenShell sur les CPU NVIDIA Vera avec Sentry sur les DPU BlueField-4. Dans les systèmes NVIDIA Vera Rubin POD, l’entreprise indique que le matériel BlueField-4 se trouve sur le seul chemin du nœud vers le modèle, ce qui permet une observation continue hors bande et une application des politiques en temps réel à pleine vitesse. L’annonce présente ce positionnement comme un moyen de créer à la fois un point d’observation détaillé et un mécanisme pour arrêter ou restreindre les interactions du modèle.

Les principes de conception déclarés par NVIDIA incluent des politiques vérifiables, une application hors bande, le contrôle du chemin vers le modèle, une autorité qui s’étend avec la visibilité sur le raisonnement, et un modèle de responsabilité partagée. En pratique, l’architecture vise à séparer l’agent des contrôles qui le gouvernent. Cette séparation est importante lorsqu’un agent a accès à des outils logiciels, des identifiants, des fichiers ou des systèmes externes qui pourraient être utilisés à mauvais escient après une défaillance de politique ou une instruction ambiguë.

Ce que NVIDIA affirme — et ce qui reste à prouver

Les affirmations les plus fortes de NVIDIA dans cette annonce sont d’ordre architectural et relèvent du discours du fournisseur. L’entreprise dit qu’OpenShell fournit une isolation au niveau du noyau et que Sentry peut appliquer des politiques via le matériel BlueField sans mettre les contrôles à la portée de l’agent. Le matériel fourni n’inclut pas de résultats de benchmark indépendants, de déploiements clients, de chiffres de réduction d’incidents ou de tests comparatifs avec d’autres produits de sécurité pour agents.

NVIDIA décrit également la « dérive », c’est-à-dire des actions qui s’écartent de la tâche assignée à un agent ou de ses contraintes opérationnelles. L’entreprise attribue la dérive à des facteurs tels que des politiques bloquées, des bugs logiciels, des outils manquants, des instructions ambiguës et des tentatives prolongées de résoudre des problèmes difficiles. Son argument est que ces comportements ne peuvent pas simplement être supprimés par l’entraînement sans potentiellement réduire des capacités utiles, et qu’on ne doit pas attendre d’un agent qu’il se contrôle pleinement lui-même.

Ce raisonnement est central dans le positionnement du produit. Plutôt que de demander à un modèle de suivre de manière fiable une consigne de sécurité, NVIDIA veut que la vérification et l’application des politiques fonctionnent indépendamment du modèle. L’entreprise compare cette approche au sandboxing des navigateurs, où les sites Web sont isolés parce que le navigateur ne suppose pas que le code chargé depuis une page est digne de confiance.

Le statut open source de NVIDIA OpenShell pourrait rendre le runtime plus facile à inspecter ou à adapter pour les développeurs et les fournisseurs d’infrastructure. Mais l’ouverture seule ne confirme pas que les politiques sont complètes, que l’isolation tient sous toutes les charges de travail, ni que le positionnement matériel peut couvrir tous les chemins vers les ressources sensibles. Ces questions nécessiteront des détails d’implémentation, des tests externes et des preuves provenant de déploiements au-delà de l’architecture de référence de NVIDIA.

Pourquoi ce lancement compte pour les bâtisseurs d’IA et les entreprises

Pour les bâtisseurs d’IA, l’annonce cible un problème opérationnel croissant : les agents deviennent plus capables au moment même où ils sont connectés à davantage d’outils. Un agent de codage peut avoir besoin d’un accès au dépôt et au shell ; un agent de service peut nécessiter des dossiers clients et des systèmes métier ; un agent de recherche peut fonctionner pendant de longues périodes et appeler des outils externes. Chaque permission supplémentaire augmente le coût d’une erreur ou d’une instruction délibérément manipulée.

Un runtime comme OpenShell pourrait offrir aux équipes produit un emplacement standard pour définir des limites d’isolation avant que les agents n’atteignent la production. Les contrôles au niveau matériel de NVIDIA Sentry pourraient ajouter une couche supplémentaire pour les entreprises qui ne veulent pas que l’agent, son modèle ou son code applicatif soient la seule source des décisions de sécurité. Cette approche peut être particulièrement pertinente pour les charges de travail de longue durée, dans lesquelles les agents peuvent accumuler des permissions, effectuer des tentatives répétées ou rencontrer des conditions non couvertes lors de l’évaluation.

Le compromis est la complexité opérationnelle. Les équipes devraient traduire les règles métier en politiques vérifiables, relier ces politiques à l’accès aux outils et déterminer quelles actions doivent être bloquées, mises en pause ou journalisées. Elles devraient également enquêter sur les faux positifs et décider de la quantité d’informations sur le raisonnement ou l’activité à conserver. La dépendance au matériel peut encore restreindre les environnements dans lesquels la pile complète peut être utilisée, même si OpenShell lui-même est open source.

Pour les acheteurs en entreprise, la question clé n’est pas simplement de savoir si un agent peut être placé dans un bac à sable. Il s’agit de savoir si les contrôles produisent des preuves vérifiables, s’intègrent aux systèmes d’identité et de sécurité existants et restent efficaces lorsque les agents utilisent des outils ou des modèles inconnus. Le cadre de responsabilité partagée de NVIDIA attribue des rôles distincts aux laboratoires de modèles, aux entreprises et aux fournisseurs de matériel, mais les frontières pratiques entre ces responsabilités doivent encore être démontrées.

Ce qu’il faut surveiller ensuite

Le premier signal sera la documentation technique et l’expérience d’implémentation autour de NVIDIA OpenShell : environnements pris en charge, langage des politiques, résistance aux échappements et manière dont les développeurs relient les agents aux outils sans compromettre l’isolation. Les chercheurs indépendants devront également tester si les frontières promises au niveau du noyau résistent à des charges de travail adversariales.

Un deuxième signal sera de voir si NVIDIA publie des évaluations de NVIDIA Sentry et des DPU BlueField-4 sous trafic d’agents réaliste. Des preuves utiles comprendraient la latence d’application, la couverture des journaux, le comportement en cas de défaillance et les performances du système lorsqu’un modèle tente de contourner ou de masquer ses actions.

Enfin, l’adoption comptera davantage que l’annonce elle-même. Surveillez les déploiements nommés, les intégrations avec des frameworks d’agents, les revues de sécurité externes et les preuves que les entreprises peuvent utiliser les contrôles sur différents modèles et environnements matériels, et pas uniquement au sein de la pile d’infrastructure privilégiée de NVIDIA.

Point de vue Creati.ai

Le lancement de NVIDIA est important parce qu’il traite la sécurité des agents comme un défi de plan de contrôle et d’ingénierie des systèmes, et non seulement comme une question de meilleurs prompts ou d’entraînement des modèles. L’application indépendante est une réponse sensée à des agents capables d’agir via des outils, de persister longtemps et de se comporter de manière imprévisible dans des conditions ambiguës.

Cela dit, l’annonce est une architecture de référence, pas la preuve qu’un problème de sécurité est résolu. Sa valeur dépendra de la portabilité du runtime, de la transparence des mécanismes de politique et du fait que des tests externes montrent ou non qu’une surveillance au niveau matériel améliore la fiabilité sans créer de coûts prohibitifs ni de surcharge opérationnelle.