NVIDIA a publié le 21 août 2026 une architecture technique qui place les contrôles de sécurité applicables aux agents IA dans le moteur d'exécution et l'infrastructure, sous le harness de l'agent. L'idée centrale est concrète : les prompts et les règles du harness influencent ce que l'agent tente, mais seule une couche de contrôle externe détermine ce qu'il est autorisé à faire.
Il s'agit de la position de NVIDIA, et non d'une nouvelle norme ou d'une garantie de sécurité validée indépendamment. AI Understanding a décrit séparément la proposition tout en soulignant l'absence de validation indépendante. Pour les équipes plateforme et sécurité, l'apport utile est une séparation plus nette entre orientation du comportement et autorité effectivement imposée.
Ce que propose l'architecture de sécurité de NVIDIA
NVIDIA décrit une pile comprenant le modèle, le harness de l'agent, l'orchestration, un moteur d'exécution sécurisé et l'infrastructure d'inférence. Le modèle et le harness se trouvent au-dessus d'une frontière de sécurité. L'identité, la politique, les identifiants, l'isolation et l'audit se trouvent en dessous.
Chaque requête produisant un effet externe devrait franchir cette frontière. Cela concerne les fichiers, processus, requêtes réseau, appels API, modifications de données, communications et allocations de ressources. Les composants situés au-dessus ne devraient pas pouvoir s'accorder une autorité ni contourner la décision.
NVIDIA propose aussi quatre profils de charge :
| Profil | Usage type | Contrôles prioritaires |
|---|---|---|
| Isolé | Préproduction avec données jetables | Aucun identifiant de production, réseau limité, session enregistrée |
| Connecté | Préproduction avec services approuvés | Identité courte durée, données masquées, limites, journalisation complète |
| Production | Modification de systèmes ou de données métier | Accès lié à la tâche, contrôles indépendants, revue humaine pour les actions à fort impact |
| Adversarial | Red team ou évaluations avec protections réduites | Communications interdites par défaut, quarantaine, isolation maximale |
Ces profils sont des recommandations de NVIDIA. Ils ne prouvent pas que NVIDIA OpenShell, ou une autre mise en oeuvre, contient tout agent ni empêche toute défaillance.
Pourquoi les contrôles du harness ne suffisent pas
Le harness gère la boucle de travail, les outils, le contexte et la mémoire. Il peut refuser une requête, demander une confirmation ou orienter le modèle vers un plan plus sûr. Ces contrôles sont utiles, mais le harness reste un logiciel susceptible d'être modifié, mal configuré ou influencé par une entrée non fiable.
NVIDIA cite plusieurs défauts récurrents : identifiants durables, documents non fiables traités comme des instructions, effets externes non contrôlés et preuves d'audit incomplètes. Une injection de prompt peut exploiter ces faiblesses lorsque le même agent interprète le contenu et décide si l'action qui en découle est autorisée.
L'autorisation doit donc rester hors de ce chemin. Le moteur d'exécution peut lier la requête à une identité, évaluer une politique, délivrer un accès étroit et enregistrer le résultat. Un signal de risque peut réduire l'autorité, mais ne doit pas l'augmenter. Le guide Maetra sur les contrôles contre l'injection de prompt explique pourquoi l'analyse du contenu et le contrôle déterministe des actions couvrent deux risques différents.
Six vérifications pour les agents utilisant des outils
Les responsables sécurité et plateforme peuvent utiliser cette architecture comme liste de contrôle :
- Cartographier chaque chemin d'effet. Recenser outils, API, fichiers, réseaux, identités, données et actions physiques ou financières accessibles.
- Identifier le point de politique faisant autorité. Déterminer quel composant autorise, bloque ou exige une revue. Vérifier que l'agent ne peut ni le modifier ni le contourner.
- Réduire l'autorité permanente. Remplacer les identifiants larges et durables par un accès court et limité à la tâche lorsque la plateforme le permet.
- Séparer orientation et exécution. Conserver prompts et règles du harness, sans les considérer comme l'ultime frontière de sécurité.
- Tester l'échec et la reprise. Couvrir injection de prompt, abus d'outil, sortie réseau, accès aux secrets, délégation, révocation et résultats externes incertains.
- Conserver la preuve de décision. Enregistrer l'identité, la version de politique, l'action demandée, la décision, le réviseur éventuel, le résultat et l'état de rapprochement. Le guide sur les journaux d'audit des agents IA propose une structure pratique.
L'examen doit inclure les chemins indirects. Si un outil approuvé peut créer un identifiant, lancer du calcul, installer un logiciel ou déléguer à un autre agent, l'autorité réelle dépasse son simple nom.
Ce qui reste incertain
L'article de NVIDIA présente une position architecturale issue de travaux avec OpenShell, des développeurs, des projets open source et des partenaires. Il ne publie pas d'évaluation comparative démontrant que cette pile dépasse d'autres conceptions. Il faut toujours valider le comportement du produit, les droits cloud, le réseau et la réponse aux incidents.
L'infrastructure peut aussi échouer si la politique est incorrecte, si un chemin d'effet manque, si une identité dispose de trop de droits ou si un système externe renvoie un résultat ambigu. La revue humaine convient à certaines actions importantes, mais elle doit dépendre de la politique et des conséquences, pas s'appliquer automatiquement à tout.
Analyse Maetra : définir l'autorité avant l'autonomie
La leçon la plus utile n'est pas que toutes les équipes ont besoin du même moteur d'exécution. La frontière d'autorité doit être explicite avant d'accorder davantage d'outils ou un horizon d'action plus long.
Commencez par un processus à conséquence réelle. Identifiez la tâche, l'action, le système, l'identifiant, la décision de politique, l'effet attendu et la preuve. Testez ensuite si un chemin atteint l'effet sans franchir le point de contrôle. Maetra Secure aide à inspecter prompts et appels d'outils suspects tout en laissant l'autorisation finale dans une couche capable d'appliquer la politique.
Sources
- NVIDIA : Where Security Fits in an AI Agent Stack, publié le 21 août 2026.
- AI Understanding : NVIDIA says AI-agent security should sit below the harness, publié le 21 août 2026.