L’architecture de référence NVIDIA OpenShell déplace le contrôle des agents dans l’infrastructure

NVIDIA a lancé son architecture de référence NVIDIA OpenShell le 21 octobre, plaçant les autorisations des agents au-delà du contrôle du logiciel qui effectue le travail. Annoncée lors de la GTC Berlin, cette conception relie le calcul des modèles, l’exécution des agents et une application indépendante de la sécurité. Sa proposition centrale est concrète : un agent doit pouvoir continuer à travailler de manière autonome sans acquérir l’autorité nécessaire pour réécrire ses propres restrictions.

Cela crée une décision d’achat différente de celle qui consiste à choisir un modèle plus performant. Les entreprises doivent déterminer où résident les autorisations, quelle infrastructure les applique et qui peut arrêter un agent après un incident. La tension se situe entre une autonomie utile et des restrictions suffisamment précises pour empêcher les actions non autorisées sans bloquer le travail légitime.

Claude Code d’Anthropic offre un point de comparaison utile, car il restreint lui aussi les agents par leur environnement d’exploitation. NVIDIA étend cette discussion à l’infrastructure d’entreprise et à l’application matérielle facultative. Les développeurs, les équipes de sécurité et les éditeurs de logiciels professionnels sont désormais confrontés à une question commune : comment une organisation transforme-t-elle ses règles métier en limites qui restent effectives pendant l’exécution ?

L’architecture de référence NVIDIA OpenShell relie l’exécution à l’application des règles

L’annonce présente le confinement des agents comme une responsabilité de l’infrastructure, avec des composants distincts pour effectuer le travail et le gouverner.

Une architecture de référence est une conception de système documentée que les organisations et les partenaires peuvent utiliser pour construire des déploiements. Cela ne signifie pas que chaque intégration citée est disponible comme produit fini aux capacités identiques. Cette distinction est importante lors de l’évaluation d’une annonce couvrant des processeurs, des systèmes d’exploitation, des fournisseurs de sécurité et des applications d’entreprise.

Selon l’architecture de référence OpenShell de NVIDIA, l’infrastructure Vera Rubin exécute les modèles, tandis que les CPU Vera font fonctionner les harnais d’agents, le logiciel qui coordonne les appels aux modèles et aux outils. Les unités de traitement des données BlueField-4, des processeurs d’infrastructure spécialisés, exécutent le logiciel de sécurité Sentry pour une surveillance et une application indépendantes.

Cette répartition reflète des problèmes opérationnels distincts. Générer un plan exige de la capacité de calcul. L’exécuter requiert un accès aux fichiers, services et outils. Autoriser ces actions nécessite des règles que l’agent exécutant ne peut pas modifier simplement parce qu’une restriction gêne sa mission.

L’annonce étend également la conception aux déploiements locaux et en périphérie, c’est-à-dire aux systèmes opérant plus près des utilisateurs ou des équipements. NVIDIA cite RTX Spark, DGX Spark et DGX Station. Les acheteurs devraient évaluer ces environnements individuellement plutôt que de supposer qu’une station de travail locale offre toutes les protections décrites pour un déploiement d’infrastructure plus vaste.

Le changement important réside dans la relation proposée entre ces éléments. Au lieu de traiter la sécurité comme une fonctionnalité applicative ajoutée après le développement, l’architecture place l’application des règles sous l’application. La demande d’un agent devient un élément évalué par l’infrastructure, plutôt qu’un élément accepté parce que l’agent a produit une explication plausible.

Prenons une tâche d’ingénierie illustrative : un agent enquête sur un service défaillant et propose une réparation. Lire des fichiers de diagnostic, installer une dépendance, modifier une configuration et déployer le correctif représentent des autorisations différentes. Une simple instruction visant à réparer le service n’établit pas que chaque étape possible est autorisée.

Cet exemple explique pourquoi l’architecture concerne bien plus que les spécialistes de la sécurité. Les équipes produit qui promettent une exécution autonome doivent aussi expliquer les limites de cette exécution. Sinon, les clients reçoivent une description des capacités sans explication correspondante des contrôles.

La disponibilité exige également une interprétation prudente. NVIDIA indique que l’architecture de référence est disponible, mais cela n’établit pas l’état de préparation pour la production de chaque combinaison de partenaires. Une conception documentée, un déploiement pris en charge et une installation client validée répondent à des questions différentes.

Pour les lecteurs qui évaluent ce lancement, la première question est donc précise : quelles parties de la chaîne proposée d’exécution et d’application des règles existent dans la configuration proposée ? La réponse détermine si un acheteur évalue des contrôles logiciels, une protection matérielle supplémentaire ou une feuille de route combinant les deux.

Les équipes d’entreprise héritent du problème des autorisations

Déplacer l’application des règles dans l’infrastructure donne davantage de contrôle aux entreprises, tout en rendant plus difficile l’implicite dans leurs décisions de politique.

La pression immédiate pèse sur les équipes chargées de traduire l’autorité métier en autorisations techniques. Les équipes de sécurité peuvent définir des ressources restreintes, mais les responsables métier doivent expliquer quelles actions relèvent d’une tâche. Les équipes d’infrastructure doivent ensuite rendre ces décisions applicables dans tous les systèmes qu’un agent utilise.

Une instruction telle que « préparer le renouvellement du client » comporte une ambiguïté considérable. Elle peut justifier la lecture de l’historique du compte et la rédaction d’une proposition. Elle ne justifie pas automatiquement la modification de conditions contractuelles, l’exportation de dossiers clients ou l’envoi de la proposition sans examen.

Il s’agit de distinctions illustratives, et non de résultats rapportés de déploiements OpenShell. Elles montrent pourquoi la sécurité des agents exige davantage que l’identification du modèle ou la vérification qu’un employé a initié la demande. L’autorité dépend de l’action, de sa cible et des circonstances.

Les contrôles d’exécution des agents de NVIDIA répartissent les responsabilités entre une passerelle, un superviseur, un bac à sable et un vérificateur de politiques. La passerelle gère les politiques et les cycles de vie des bacs à sable. Le superviseur vérifie les demandes et gère les identifiants en dehors du bac à sable, un environnement d’exécution isolé. Le vérificateur de politiques contrôle les autorisations par rapport à un plafond défini par l’organisation.

Cette séparation fournit des emplacements d’application des règles, mais les organisations doivent toujours décider ce que ces emplacements doivent autoriser. Un plafond vérifié formellement peut confirmer une relation entre des politiques. Il ne peut pas décider de manière indépendante si un département métier a accordé un accès excessif dès le départ.

Cela modifie la discussion entre les développeurs d’applications et les évaluateurs de sécurité. Au lieu de demander si un agent est généralement digne de confiance, les évaluateurs peuvent examiner ce qu’il peut lire, modifier, invoquer ou transmettre. Ces questions produisent des réponses plus exploitables, même si elles exigent également une préparation plus détaillée.

Les développeurs sont confrontés à une contrainte de conception connexe. Un flux de travail qui ne réussit qu’avec des autorisations étendues est plus difficile à approuver qu’un flux aux exigences explicites et limitées. Les interfaces d’outils et les descriptions de tâches deviennent partie intégrante de la conception de sécurité, car elles déterminent avec quelle précision l’autorité peut être exprimée.

Pour les travailleurs du savoir, la distinction commence par l’accès à l’information. Une base de connaissances consultable aide à déterminer où se trouve le matériel utile. Un agent capable d’agir introduit une autre décision : le fait de trouver une information accorde-t-il aussi l’autorisation de la partager ou de modifier le système qui la contient ?

La charge organisationnelle est continue. Les employés changent de rôle, les projets se terminent, les identifiants expirent et les applications acquièrent de nouvelles fonctions. L’autorité d’un agent doit refléter ces changements plutôt que de préserver les accès qui ont permis le succès de sa première démonstration.

C’est pourquoi la gouvernance ne peut pas s’arrêter à un document d’approbation. Les entreprises ont besoin d’un lien entre la personne qui autorise le travail, la politique représentant cette autorité et l’infrastructure qui l’applique. Sans ce lien, des règles appliquées indépendamment peuvent encore préserver une décision obsolète ou trop large.

Ce lancement met donc les éditeurs de logiciels sous pression autant que les acheteurs d’infrastructure. Les éditeurs doivent exposer suffisamment de détails sur les actions des agents pour que les clients puissent les gouverner. Un système qui présente chaque opération comme une demande indifférenciable laisse aux clients un choix rudimentaire entre un accès large et une interruption.

L’isolation matérielle modifie l’emplacement où la limite s’applique

La proposition matérielle de NVIDIA ajoute un emplacement d’application indépendant ; sa valeur dépend de la question de savoir si les actions concernées passent effectivement par cet emplacement.

Une restriction logicielle possède une portée définie. Sa protection dépend des composants qui l’appliquent et des hypothèses sur lesquelles reposent ces composants. L’ajout d’une couche de sécurité matérielle distincte modifie certaines de ces hypothèses en plaçant les contrôles hors de l’environnement d’exécution de l’agent.

NVIDIA présente Sentry comme une protection supplémentaire facultative, en complément des limites logicielles d’OpenShell. Cette distinction évite un malentendu courant : utiliser OpenShell ne signifie pas automatiquement qu’un déploiement inclut l’application BlueField-4. Les acheteurs doivent identifier la configuration réelle avant de comparer les affirmations de sécurité.

Dans la conception de sécurité d’exécution Sentry de NVIDIA, BlueField-4 se situe sur le chemin de communication du nœud vers les modèles et les systèmes externes. Sentry combine l’inspection du trafic à une analyse ciblée de la mémoire hôte. NVIDIA affirme pouvoir mettre les agents en quarantaine en quelques millisecondes sans exiger la coopération de l’agent ou du logiciel hôte.

La logique architecturale est simple. Un contrôle est plus utile face à une charge de travail compromise lorsque cette charge ne peut pas le désactiver. Mais l’indépendance seule n’établit pas une couverture complète. Le point d’application doit aussi voir l’action évaluée et conserver l’autorité de la bloquer.

Cela soulève des questions concrètes lors des revues de déploiement. La configuration fait-elle passer chaque connexion externe pertinente par le chemin contrôlé ? Quelles actions locales reçoivent des restrictions distinctes ? Que se passe-t-il lorsqu’un outil effectue un travail sur un autre service après avoir reçu une demande autorisée ?

Ces questions découlent de la conception plutôt que de documenter des défaillances découvertes. Elles sont importantes parce que le flux de travail d’un agent peut traverser plusieurs limites administratives. Bloquer sa prochaine connexion ne peut pas nécessairement annuler une action déjà acceptée par une autre application.

Le trafic chiffré introduit une autre décision de configuration. NVIDIA décrit l’inspection des connexions configurées pour être déchiffrées et examinées. Les entreprises doivent donc comprendre où l’inspection s’applique, quelles informations deviennent visibles et comment cette visibilité s’inscrit dans leurs exigences de confidentialité.

La comparaison avec Anthropic aide à clarifier le choix de conception. Le sandboxing de Claude Code d’Anthropic utilise des mécanismes de système d’exploitation pour restreindre l’accès au système de fichiers et au réseau. Son approche déclarée donne aux agents de la liberté dans des limites prédéfinies tout en contrôlant l’accès au-delà de celles-ci.

Les deux approches placent des restrictions en dehors des instructions générées par le modèle. La différence ne se résume pas à une opposition entre logiciel sans restriction et matériel sécurisé. Les acheteurs comparent des modalités d’application, des exigences de déploiement et des hypothèses de défaillance.

L’exemple d’Anthropic concerne un environnement d’exécution pour développeurs. L’annonce de NVIDIA relie l’exécution des agents à une conception d’infrastructure plus large, avec une couche matérielle indépendante facultative. Aucune des deux descriptions ne permet à elle seule d’établir quel dispositif convient le mieux à une charge de travail d’entreprise donnée.

Pour une organisation exécutant des tâches de développement étroitement définies, les contrôles d’environnement existants méritent d’être évalués selon leurs propres qualités. Pour les déploiements sensibles nécessitant une indépendance accrue vis-à-vis du logiciel hôte, l’approche matérielle de NVIDIA constitue une autre option. La décision doit dépendre de la menace traitée.

Le compromis essentiel oppose une séparation renforcée à une complexité de déploiement accrue. Une couche d’application supplémentaire crée un point additionnel pour arrêter une activité dangereuse. Elle ajoute aussi un composant dont les politiques, la visibilité, les mises à jour et la responsabilité opérationnelle doivent rester cohérentes avec le reste du système.

Les annonces des partenaires révèlent différents niveaux de maturité

Les informations les plus utiles sur les partenaires distinguent les capacités disponibles aujourd’hui des intégrations qui restent prévues.

ServiceNow fournit un exemple concret de l’entrée de cette architecture dans les discussions autour des produits d’entreprise. Son annonce sur la gouvernance des agents d’entreprise indique qu’Arc, un agent personnel conçu pour des travaux de longue durée, est disponible de manière générale. ServiceNow décrit l’application des règles d’OpenShell comme faisant partie de l’exécution gouvernée d’Arc.

La même annonce situe l’intégration d’AI Passport avec OpenShell et l’application des règles via BlueField dans une version future. AI Passport est un registre d’autorité destiné à communiquer les autorisations d’un agent. Son statut prévu est important, car le lancement actuel d’une application ne démontre pas la disponibilité de l’ensemble de la chaîne de gouvernance proposée.

Cette distinction offre aux acheteurs une méthode utile pour lire d’autres documents de lancement. La disponibilité formulée au présent doit être évaluée séparément de l’intégration envisagée, de la collaboration entre partenaires et des capacités futures. Les réunir dans une même impression de maturité masque le travail qui reste nécessaire.

L’exemple de ServiceNow rend également le problème métier plus tangible. Un agent de travail persistant doit fonctionner malgré l’évolution des missions et des autorisations. La gouvernance doit rester pertinente après la demande initiale, surtout lorsqu’une tâche se prolonge au-delà de l’attention immédiate de l’utilisateur.

Un cas illustratif serait celui d’un employé chargeant un agent de coordonner la transmission d’un projet. Lire les documents du projet, identifier le travail inachevé, rédiger des messages et modifier des droits d’accès exigent des niveaux d’autorité différents. Un système utile doit préserver cette distinction à mesure que la tâche évolue.

Les partenaires de sécurité introduisent un niveau supplémentaire de différenciation. F5 décrit une inspection du trafic IA qui complète les autorisations d’exécution par l’examen des prompts, réponses et appels d’outils pris en charge. Son annonce distingue également une topologie de déploiement proposée, soumise à validation du produit.

Il s’agit d’une réserve importante, et non d’une simple note de bas de page. Un partenaire peut soutenir l’orientation de l’architecture alors qu’une configuration particulière exige encore une validation. Les clients doivent demander quel déploiement a été testé, avec quelles fonctions d’inspection activées et sur quelle charge de travail.

La présentation de F5 sépare aussi l’autorisation de l’évaluation du contenu. Une requête peut cibler un service approuvé tout en contenant des informations sensibles ou des instructions malveillantes. L’autorisation de se connecter et l’évaluation du contenu transmis répondent à des risques différents.

Cela aide à comprendre pourquoi le lancement inclut des partenaires de sécurité plutôt que de présenter l’application des règles d’infrastructure comme un substitut à toutes les défenses existantes. La frontière proposée a besoin d’informations sur l’identité, l’autorisation et l’activité suspecte. Elle a aussi besoin d’une réponse opérationnelle lorsqu’une action est bloquée.

La question commerciale est de savoir si ces couches deviennent plus faciles à exploiter ensemble. Les acheteurs doivent rechercher des politiques cohérentes et des enregistrements d’incidents compréhensibles. Ajouter des consoles séparées sans relation claire entre les décisions obligerait les enquêteurs à reconstituer les événements à travers des systèmes déconnectés.

L’étendue des partenariats signale un intérêt, mais les détails de déploiement ont davantage de poids. Un client peut évaluer une configuration prise en charge, une limitation documentée ou une intégration livrée. Le nom d’une entreprise dans une liste de lancement fournit moins d’éléments sur ce que ce client peut exploiter en toute sécurité aujourd’hui.

Des limites sûres dépendent toujours de règles correctes

L’architecture de référence NVIDIA OpenShell n’élimine pas la distinction entre une action autorisée et une bonne décision.

Un agent peut respecter ses autorisations tout en produisant un résultat erroné. Il peut mal interpréter un document, choisir le mauvais enregistrement ou formuler une recommandation médiocre. Le confinement par l’infrastructure traite du périmètre de l’action ; il ne garantit pas la véracité de chaque conclusion.

Cette distinction doit orienter la manière dont les organisations interprètent le mot « sûr ». La sécurité est un résultat général, tandis que l’application des règles à l’exécution fournit des contrôles particuliers. Une évaluation significative identifie la défaillance évitée et les hypothèses dans lesquelles cette prévention est valable.

Imaginons un agent autorisé à mettre à jour un système de planification. Une restriction pourrait l’empêcher avec succès d’accéder aux données de paie. Ce même agent pourrait néanmoins planifier le mauvais rendez-vous dans l’application autorisée. Les deux résultats comptent, mais ils nécessitent des garanties différentes.

Des autorisations trop larges créent une autre limite. Une règle parfaitement appliquée qui permet à un agent d’exporter un jeu de données entier ne protège pas ce jeu de données contre une exportation autorisée. La qualité de la décision métier reste centrale, même lorsque l’application des règles fonctionne exactement comme prévu.

Des autorisations trop étroites créent le problème inverse. Si le travail courant s’interrompt de façon répétée, les utilisateurs sont incités à demander un accès plus large. Les équipes de sécurité ont alors besoin d’éléments montrant quels blocages évitent des dommages et lesquels reflètent des politiques mal adaptées aux tâches légitimes.

Il s’agit d’une préoccupation analytique, et non d’une conclusion selon laquelle OpenShell provoque des interruptions inutiles. Elle identifie les mesures nécessaires pour évaluer le compromis entre autonomie et contrôle. Un confinement efficace doit être considéré parallèlement à l’accomplissement utile des tâches, à la fréquence des interventions et aux conséquences des opérations refusées.

Le moment de la détection nécessite également du contexte. Une affirmation de mise en quarantaine rapide décrit la réponse après la détection d’une condition pertinente. Les acheteurs doivent encore comprendre quels événements déclenchent la détection et si un système externe a déjà agi avant le début du confinement.

Les descriptions actuellement disponibles des fournisseurs n’établissent pas de garantie universelle, vérifiée indépendamment, pour l’ensemble des flux de travail d’entreprise. Elles expliquent les mécanismes et points d’intégration envisagés. Les conclusions de sécurité en production exigent des éléments liés à la configuration déployée, y compris ses autorisations et protections activées.

L’observabilité accrue comporte aussi une dimension de confidentialité. L’examen des communications et du contexte d’exécution peut améliorer les enquêtes, tout en exposant des éléments sensibles à des composants de sécurité supplémentaires. Les organisations ont besoin de décisions claires sur le périmètre d’inspection, l’accès aux enregistrements et leur conservation.

La responsabilité opérationnelle mérite une attention égale. Quelqu’un doit maintenir les politiques, enquêter sur les refus, approuver les exceptions et restaurer un agent après son confinement. Si ces responsabilités restent floues, une frontière techniquement efficace peut tout de même provoquer une interruption prolongée ou une solution de contournement dangereuse.

L’approche de NVIDIA rend ces questions plus concrètes, car elle identifie des endroits où les règles peuvent être appliquées indépendamment. C’est un progrès utile dans la conception des systèmes. Cela ne supprime pas la nécessité d’évaluer les règles elles-mêmes ni le flux de travail qui entoure une décision de sécurité.

La norme appropriée est donc une affirmation limitée : des contrôles particuliers empêchent des actions non autorisées précises dans des conditions spécifiées. Les acheteurs doivent résister à la tentation de transformer cette affirmation en promesse générale qu’un agent ne peut pas causer de préjudice.

Surveillez les intégrations livrées, les preuves de sécurité et l’adéquation opérationnelle

Les prochains signaux importants seront les capacités livrées, une validation reproductible et la preuve que les organisations peuvent maintenir les contrôles qui en résultent.

Au cours des prochains mois, le premier signal sera la livraison des intégrations décrites comme des travaux futurs. L’application prévue des règles d’AI Passport par ServiceNow en fournit un exemple précis. Une version accompagnée d’une prise en charge et de limitations documentées rendrait plus facile l’évaluation du lien proposé entre l’autorité métier et l’application des règles d’infrastructure.

Cela renforcerait l’idée que les entreprises peuvent faire passer une décision de gouvernance à travers les couches d’exécution. La poursuite d’un langage de feuille de route laisserait cette partie de la proposition moins établie. Les acheteurs doivent distinguer la disponibilité d’un produit des démonstrations ou annonces de collaboration.

Le deuxième signal est une validation de sécurité liée à un déploiement complet. Des éléments utiles décriraient la charge de travail, la configuration des politiques, l’inspection activée, la tentative d’action non autorisée et le résultat observé. Ils devraient également expliquer quel travail légitime est resté possible.

Une démonstration montrant qu’un agent est arrêté établit moins de choses qu’un compte rendu reproductible expliquant pourquoi il a été arrêté. Ce dernier aide les clients à déterminer si le même contrôle s’applique à leurs applications. Il révèle aussi des hypothèses qu’une présentation peut laisser implicites.

La validation doit inclure les flux de travail autorisés ainsi que les attaques. Une frontière qui bloque une activité non autorisée tout en autorisant le travail attendu confirme le compromis central de l’architecture. Une dépendance répétée à de larges exceptions affaiblirait l’affirmation selon laquelle les entreprises peuvent associer autonomie et contrôle précis.

Le troisième signal est l’adéquation opérationnelle dans des environnements d’entreprise réels. Les organisations doivent savoir si les politiques restent cohérentes à mesure que les applications, les identités et les outils évoluent. Elles ont également besoin d’enregistrements d’incidents qui expliquent la relation entre l’action demandée et la décision d’application des règles.

Des preuves de mises à jour de politiques gérables et d’enquêtes compréhensibles renforceraient l’argument en faveur du déploiement. Des preuves de règles incohérentes ou de responsabilités floues identifieraient un autre goulot d’étranglement. Dans ce cas, une capacité d’application supplémentaire ne résoudrait pas à elle seule le problème de gouvernance.

Les déploiements locaux et en périphérie méritent une attention particulière dans cette évaluation opérationnelle. Les lecteurs doivent rechercher les capacités documentées du système précis en cours de déploiement. Une famille de produits ou une étiquette d’architecture partagée ne répond pas à toutes les questions sur la couverture de l’application des règles.

Pour les développeurs, la conséquence pratique est une demande d’exigences d’autorisation plus claires. Pour les acheteurs d’entreprise, il s’agit d’une demande d’éléments propres à chaque configuration. Pour les travailleurs du savoir, c’est une distinction entre accorder à un agent l’accès à des informations et lui déléguer l’autorité d’agir.

Avant d’approuver un déploiement, identifiez le flux de travail exact que vous souhaitez confier à un agent et les actions qui doivent rester hors de son autorité. Demandez au fournisseur de démontrer les deux résultats dans la configuration proposée : la poursuite du travail légitime et l’arrêt d’une action non autorisée. Examinez ensuite qui maintient la politique, comment les changements d’accès prennent effet et ce que les enquêteurs pourront reconstituer par la suite. Distinguez les capacités actuelles des intégrations promises, en particulier lorsque les sorties logicielles et matérielles suivent des calendriers différents. L’architecture de référence NVIDIA OpenShell offre une conception d’infrastructure concrète à examiner dans le cadre de cette évaluation. Utilisez-la pour exiger une réponse précise à une question pratique : quelles décisions restent sous le contrôle de votre organisation pendant que l’agent travaille de manière indépendante ?