Une plateforme avec des contrôles sur deux niveaux
Nvidia a présenté le 28 septembre 2026 la Open Agent Safety Platform, une proposition combinant des outils logiciels et une architecture de référence matérielle pour établir des contrôles sur les agents d'intelligence artificielle. La plateforme est constituée d'OpenShell, un runtime open source, et de Sentry, un mécanisme de surveillance conçu pour s'exécuter sur les unités de traitement de données BlueField-4.
L'idée centrale est de distribuer la sécurité en dehors de l'agent lui-même. OpenShell applique des limites d'exécution par logiciel ; Sentry ajoute une supervision indépendante depuis l'infrastructure. Nvidia soutient que les organisations peuvent adopter des parties de la plateforme selon leurs besoins, si bien que l'utilisation d'OpenShell n'implique pas nécessairement le déploiement de Sentry ni la possession de BlueField-4.
Il convient de séparer l'annonce de son évaluation : la documentation officielle décrit l'architecture et les capacités prévues, mais n'apporte pas à elle seule une comparaison indépendante permettant de mesurer son efficacité face à d'autres contrôles ou à toutes les attaques possibles. L'affirmation selon laquelle Sentry peut intervenir en quelques millisecondes doit être comprise dans le cadre du design annoncé, et non comme une garantie universelle.
OpenShell impose des limites à ce que l'agent peut faire
OpenShell crée un environnement d'exécution isolé et applique des politiques sur les actions et les ressources disponibles pour un agent. Selon la documentation de Nvidia, ces contrôles peuvent couvrir les fichiers, les connexions réseau et les opérations système. La plateforme vise également à gérer de manière restreinte l'accès aux identifiants, de sorte que l'agent n'ait pas à les recevoir directement pour chaque tâche.
La différence par rapport à une instruction écrite dans le prompt réside dans la localisation et le respect. Une consigne comme « n'accédez pas à ce dossier » dépend du fait que le modèle la respecte. Un contrôle appliqué par l'environnement d'exécution peut restreindre l'accès indépendamment de cette instruction. Cela ajoute une barrière technique, bien que son étendue dépende de la configuration et des ressources autorisées.
Nvidia indique qu'OpenShell est open source et qu'il peut être étendu pour fonctionner sur des plateformes tierces, y compris Arm et Intel. L'entreprise le présente également comme largement disponible. Cette disponibilité du composant logiciel ne doit pas être confondue avec la disponibilité de tout le système intégré ni avec le besoin de matériel spécifique pour Sentry.
Sentry ajoute une surveillance depuis une DPU
Sentry est une architecture de référence qui, selon Nvidia, fonctionne sur les DPU BlueField-4 et supervise en continu l'activité des agents depuis un environnement séparé. L'entreprise décrit sa fonction comme l'inspection des requêtes et des réponses, la vérification de l'identité de l'agent, la génération de télémétrie et l'application de politiques d'accès aux données, aux outils, aux interfaces et aux services.
La séparation vise à ce que la supervision ne dépende pas uniquement du logiciel qui exécute l'agent. Si une opération tente de dépasser les limites définies, Nvidia affirme que Sentry peut mettre l'agent en quarantaine et l'arrêter en quelques millisecondes. Cette phrase décrit la vitesse annoncée pour l'intervention une fois une infraction identifiée ; elle ne précise pas à elle seule le temps nécessaire pour reconnaître une activité dangereuse ni les signaux suffisants pour la détecter.
En termes pratiques, Sentry introduit une exigence différente d'OpenShell : son architecture est liée à BlueField-4. Par conséquent, la possibilité d'adopter OpenShell sur d'autres plateformes ne doit pas être transposée automatiquement à Sentry. Les informations disponibles ne résolvent pas non plus toutes les conditions de déploiement, de compatibilité et de disponibilité commerciale pour chaque configuration.
Ce que chaque composant apporte
La séparation aide à distinguer les limites logicielles de la surveillance basée sur le matériel.
| Composant | Localisation décrite | Fonction annoncée | Point à encore évaluer |
|---|---|---|---|
| OpenShell | Runtime logiciel | Isoler l'exécution et appliquer des politiques sur les ressources et les actions. | Quelles configurations et politiques couvrent chaque environnement réel. |
| Sentry | DPU Nvidia BlueField-4 | Surveiller l'activité et appliquer des politiques depuis un environnement séparé. | Comment détecter une infraction et quelle latence atteindre dans des tests reproductibles. |
| Plateforme conjointe | Logiciel et matériel | Combiner les limites d'exécution avec une surveillance hors bande. | Efficacité globale face aux attaques, aux pannes et aux contrôles alternatifs. |
Des millisecondes de contention ne signifient pas une détection instantanée
L'annonce de Nvidia attribue à Sentry la capacité de mettre un agent en quarantaine en quelques millisecondes lorsqu'il tente de sortir de ses limites. Cependant, la vitesse de réponse et la vitesse de détection sont des mesures différentes. Pour évaluer la protection, des données sur les deux sont nécessaires : quand le comportement problématique est reconnu et combien de temps s'écoule avant que le blocage ne soit appliqué à partir de ce moment.
Un agent peut posséder des identifiants valides et effectuer une action qui semble légitime d'un point de vue technique, bien que le résultat soit inapproprié. Il peut également initier des opérations avant qu'une quarantaine ne soit activée. Par conséquent, connaître uniquement le temps d'intervention ne suffit pas pour déterminer ce qui peut se produire avant le blocage, quelles données auraient pu être consultées ou quels changements auraient pu être effectués.
L'évaluation nécessite de fixer des conditions concrètes : ressources connectées, permissions accordées, politiques configurées, localisation de l'agent et critères de détection. Sans ces informations, le chiffre des millisecondes ne permet pas de comparer des déploiements distincts ni d'anticiper les résultats dans une organisation spécifique.
Comment évaluer une affirmation de contention rapide
Séparer les étapes évite de confondre une réponse rapide avec une détection efficace.
- 01Définir quel comportement est considéré comme une infraction et comment il est enregistré.
- 02Mesurer le temps écoulé depuis le premier signal détectable jusqu'à l'alerte.
- 03Mesurer séparément l'intervalle entre la détection et la quarantaine effective.
- 04Enregistrer quelles actions et accès se sont produits avant le blocage.
- 05Répéter les tests avec les mêmes politiques, permissions et ressources pour comparer les résultats.
Ce qui peut rester hors de la protection
Les contrôles d'infrastructure peuvent limiter les actions, mais ne garantissent pas que l'agent interprète correctement une tâche, produise des réponses fiables ou prenne de bonnes décisions dans l'espace autorisé. Un agent travaillant dans son bac à sable peut encore commettre des erreurs aux conséquences graves, générer des résultats incorrects ou utiliser de manière préjudiciable des permissions légitimes.
La réponse face aux agents trompés ou qui cachent leurs intentions reste ouverte. Les sources critiques soulignent qu'une surveillance basée sur des signaux comportementaux peut ne pas suffire si l'agent feint d'agir légitimement ou si le dommage commence avant l'activation de la quarantaine. Cela ne prouve pas une vulnérabilité spécifique de Sentry : cela indique que l'annonce ne démontre pas une couverture suffisante de ces scénarios.
Les politiques comptent également. Une règle trop permissive peut laisser passer des actions indésirables ; une règle trop stricte peut interrompre des tâches légitimes. La protection dépend donc de la définition correcte des limites, de leur mise à jour et de la vérification de leur interaction avec les permissions, les outils et les services connectés.
Quels tests sont nécessaires pour juger son efficacité
La documentation officielle explique les composants, le but et l'architecture, et indique qu'OpenShell est disponible en tant que logiciel open source. Cela permet d'examiner le projet et d'adapter le composant logiciel, mais n'équivaut pas à une validation indépendante de la plateforme complète. Dans les informations disponibles, aucune comparaison reproductible, dans des conditions équivalentes, avec des outils de sécurité existants n'est fournie.
Une évaluation utile devrait publier la configuration testée, les politiques, les modèles et outils connectés, les classes d'attaques, les critères de détection et les mesures de latence. Elle devrait également enregistrer les faux positifs et les faux négatifs, ainsi que les actions que l'agent a réussi à réaliser avant d'être isolé. Sans ces données, il n'est pas possible de transformer une affirmation du fabricant en une estimation générale d'efficacité.
Pour les organisations intéressées, la conclusion prudente est de traiter OpenShell et Sentry comme des couches de contrôle annoncées nécessitant une configuration et une validation propres. Avant de les adopter, il convient de confirmer ce qui est disponible pour l'environnement spécifique, quel matériel Sentry requiert, quelles ressources restent dans le périmètre de surveillance et quelle preuve indépendante existe pour les scénarios d'utilisation prévus.
Questions pour une revue technique
Ces questions aident à distinguer la disponibilité, l'architecture et l'efficacité mesurée.
| Aspect | Ce qu'il faut vérifier |
|---|---|
| Disponibilité | Quelles versions sont publiées et quelles fonctions correspondent au logiciel open source ou au design de référence. |
| Matériel | Quelle configuration de BlueField-4 Sentry requiert et où il peut être déployé. |
| Détection | Quels signaux identifient l'activité infractionnelle et combien de temps prend cette reconnaissance. |
| Contention | Quand le blocage commence et quelles opérations peuvent être terminées avant. |
| Comparaison | S'il existe des tests indépendants, répétables et réalisés avec des contrôles équivalents. |
| Couverture | Que se passe-t-il avec des agents trompés, une activité ambiguë, des erreurs et des identifiants valides. |
Questions ouvertes
- Les conditions de test soutenant l'affirmation de contention en millisecondes et la latence de détection séparée ne sont pas suffisamment détaillées.
- Les informations disponibles n'établissent pas de manière indépendante les performances de Sentry face aux agents trompés, qui cachent leurs intentions ou agissent avec des permissions valides.
- Aucune comparaison reproductible et indépendante de la plateforme complète face à d'autres contrôles dans des conditions équivalentes n'est documentée.
- La disponibilité et la compatibilité de Sentry pour chaque produit et configuration doivent être confirmées ; la disponibilité d'OpenShell n'implique pas que Sentry fonctionne sans BlueField-4.
Poursuivre l’exploration
Sources consultées
Corrections et transparence
Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.
Proposer une correction