Une seule injection réussie équivaut à livrer tous les identifiants
Placer les clés APTI dans les variables d’environnement était la pratique par défaut en ingénierie serveur pendant vingt ans. Le 28 septembre 2026, NVIDIA a lancé sa plateforme de sécurité pour agents IA ouverte (Open Agent Safety Platform), transformant cette pratique par défaut en interdit à l’ère des agents. La plateforme comprend deux éléments : le logiciel open source OpenShell (sous licence Apache 2.0, dépôt NVIDIA/OpenShell sur GitHub), et un design de système de référence Sentry — ce dernier s’exécute sur le BlueField-4 DPU (Data Processing Unit), agissant comme un chien de garde hors bande (out-of-band) pour surveiller les agents sur le CPU principal, avec une capacité officielle d’isoler les agents hors de contrôle en millisecondes.
État du dépôt : implémentation en Rust, divisé en modules comme core, supervisor, credential-gateway, policy-engine, egress-gateway ; 18,2k étoiles, 1 852 commits ; version stable 0.1.x, environ une version toutes les trois semaines. La densité des commits ajoutée au rythme d’une version par trois semaines pointent vers la même conclusion — cet runtime est encore en phase de formation rapide, et ceux qui l’intégreront en production doivent prévoir des coûts pour les changements d’interface.
La logique de conception d’OpenShell se résume à un principe : si le comportement de l’agent est imprévisible, restreignez sa portée et déplacez le jugement d’autorisation du contexte du modèle vers le noyau. Le point de compétitif du runtime des agents change ainsi — de « le modèle se comporte bien » à « comment loin une escalade de privilèges peut aller ».
Les identifiants passent par la passerelle, pas par le contexte
Le travail quotidien d’un agent autonome consiste à exécuter des commandes shell, écrire des fichiers, envoyer des requêtes réseau, et les identifiants se trouvent généralement dans les variables d’environnement, les fichiers de configuration ou .env. Une seule injection de prompt réussie, ou simplement une mauvaise interprétation par le modèle, et l’agent agit avec tous les identifiants. Le rayon d’impact équivaut à l’ensemble des permissions qui lui ont été accordées, et restreindre les permissions, c’est réduire le rayon d’impact. C’est le point de départ de toute la conception d’OpenShell.
Les garde-fous au niveau des prompts n’ont pas de force contraface face aux entrées adverses. Les contraintes du système de prompt dépendent de la docilité du modèle, et tout ce que l’attaquant doit faire est de faire changer d’avis au modèle ; les limites de permissions au niveau noyau ignorent l’avis du modèle et rejettent directement les appels système. La différence entre un garde-fou et une limite réside dans l’entité qui l’impose : l’un repose sur la bonne volonté du modèle, l’autre sur le noyau.
Figure : Capture d’écran de l’interface en ligne de commande d’OpenShell en cours d’exécution, les actions de l’agent ne sont exécutées qu’après avoir passé la vérification de la politique. Source : Documentation du dépôt officiel d’OpenShell
L’application au niveau noyau est le premier mécanisme clé. Les politiques prennent effet au niveau du noyau, ne dépendant ni des bibliothèques d’exécution, ni de la configuration des conteneurs ; chaque action de l’agent à l’intérieur de la limite doit passer par une vérification de politique. Les conteneurs résolvent l’isolation des processus et la distribution des images, OpenShell répond à une autre question : chaque accès de l’agent en cours d’exécution aux identifiants, fichiers et réseaux, est-il autorisé.
La passerelle d’identifiants est le deuxième mécanisme clé. Les clés APTI et les jetons sont confiés à la passerelle d’identifiants (credential gateway) qui les injecte lors des requêtes sortantes ; les identifiants n’entrent jamais dans le contexte de l’agent, ni ne se retrouvent dans son système de fichiers. Par comparaison avec la pratique habituelle de « mettre la clé dans .env », la surface de vulnérabilité passe de la machine entière à un seul composant de passerelle. Le modèle peut être trompé, mais le modèle trompé n’a pas les clés en main.
Le trafic sortant est également contrôlé : la passerelle sortante (egress gateway) autorise uniquement les destinations sur une liste blanche, tout ce qui est en dehors de cette liste est inaccessible ; le système de fichiers et les cibles réseau n’exposent que les répertoires et adresses que l’agent devrait voir.
Figure : Architecture d’OpenShell — les modules agent, supervisor, passerelle d’identifiants, moteur de politique et passerelle sortante sont indépendants, les identifiants et les décisions de politique sont tous effectués en dehors du contexte de l’agent. Source : Documentation du dépôt officiel d’OpenShell
Les modifications de politique passent d’abord par une vérification formelle avant d’être appliquées
Une erreur dans l’écriture d’une politique équivaut à ouvrir une faille. OpenShell bloque les changements de politique derrière une vérification formelle : la nouvelle politique est vérifiée formellement avant d’entrer en vigueur, pour confirmer que sa sémantique correspond aux attentes. Parmi les outils de sandbox similaires, cette étape est rare — la plupart des solutions restent à l’état « la politique est du code, elle est appliquée immédiatement une fois modifiée ».
Le composant supervisor gère la création, la surveillance et la terminaison des agents, formant une couche de gestion du cycle de vie. Le SDK couvre quatre langages : Python, TypeScript, Go et Rust, le déploiement Kubernetes se fait via Helm, et le chemin d’intégration est complet.
La vérification formelle a ses propres limites : elle combat les « erreurs dans l’écriture des politiques », mais ne résout pas « la politique est bien écrite mais trop restrictive ». Si la politique est trop restrictive, l’agent ne peut pas travailler, et la pression opérationnelle poussera à assouplir les règles ; une fois l’intention assouplie, même une vérification stricte ne fait qu’exécuter avec précision une intention relâchée. La responsabilité en matière de sécurité est déplacée du niveau du code vers celui de l’auteur des politiques, et les politiques elles-mêmes deviendront un nouvel objet d’audit.
Figure : Schéma des points d’application de la sandbox — les politiques prennent effet sur les limites du système de fichiers, du réseau, des identifiants et du trafic sortant, chaque limite correspondant à un composant indépendant. Source : Documentation du dépôt officiel d’OpenShell
Le chien de déporté sur le BlueField-4 DPU, l’isolation en millisecondes
La conception de référence Sentry déplace le chien de garde hors de l’hôte. Il s’exécute sur le BlueField-4 DPU, surveillant les agents s’exécutant sur le CPU principal hors bande, avec une capacité officielle d’isoler les agents hors de contrôle en millisecondes, et dans l’environnement de démonstration, le CPU Vera a également participé à l’exécution.
Le hors bande est la clé de cette conception. La surveillance en bande et l’objet surveillé partagent le même noyau et le même domaine de confiance ; si l’hôte est compromis, le monitoring l’est aussi ; le DPU a sa propre puissance de calcul et son propre chemin réseau, et même si l’agent sur le CPU principal est hors de contrôle, il ne peut atteindre le chien de garde lui-même. L’isolation se mesure en millisecondes, réduisant ainsi la fenêtre d’action malveillante — à condition que le micrologiciel et la pile logicielle du côté DPU tiennent, le chien de garde lui-même devient une nouvelle cible de haute valeur pour les attaques.
Le communiqué officiel liste en même temps 12 partenaires et intégrants du secteur, avec des fournisseurs cloud et des entreprises de sécurité sur la liste. La position dans l’écosystème est claire : NVIDIA veut que « les agents s’exécutent dans un runtime avec des limites » devienne la forme de déploiement par défaut, tout comme hypervisor pour les machines virtuelles.
Le numéro de version 0.1.x est plus honnête que les quatre mots « largement disponible »
Le numéro de version verse d’abord un seau d’eau froide. OpenShell est actuellement en version stable 0.1.x, avec un rythme de publication d’environ une version toutes les trois semaines, mais le langage officiel est « désormais largement disponible » (now broadly available). Le rythme d’une version par trois semaines est en soi un signal : les interfaces et la sémantique sont encore en évolution, et intégrer en production nécessite de prévoir des coûts de migration ; entre les quatre mots « largement disponible » et 0.1.x, l’espace d’interprétation est laissé à l’utilisateur.
Le deuxième seau d’eau froide : la sandbox réduit le rayon d’impact, mais n’élimine pas les risques. La couche d’application au niveau noyau, la passerelle d’identifiants et le moteur de politique deviennent eux-mêmes une nouvelle base de confiance, et leur problème équivaut à une défaillance de la limite. La surface d’attaque change de position, mais le volume ne diminue pas — l’objet à auditer passe de « l’agent application » à « le runtime sandbox ».
Le débat sur la voie à suivre n’est pas encore tranché. Les plateformes gérées comme Claude Managed Agents d’Anthropic intègrent la sandbox dans le service cloud, sans que les utilisateurs aient à construire leurs propres limites ; OpenShell suit une route auto-hébergée et auditable. Les prérequis des deux approches sont différents : les équipes ayant des données qui ne doivent pas quitter leur périmètre et ayant besoin de traces d’audit internes choisiront la seconde, tandis que les équipes sans capacité opérationnelle dédiée à la gestion des limités utiliseront les services gérés pour simplifier. Le choix est dicté par les exigences de conformité et les capacités opérationnelles, les deux approches ayant leurs scénarios valides.
Le logiciel est offert, le matériel se vend
La facture commerciale doit être claire. OpenShell est distribué sous licence Apache 2.0 open source, ce qui abaisse le seuil de conformité pour le déploiement d’agents ; la conception de référence Sentry est liée au BlueField-4 DPU et au CPU Vera. Le logiciel est distribué gratuitement, le matériel de sécurité se vend par unité — une répétition de la vieille méthode de l’époque CUDA : les outils de l’écosystème sont gratuits, l’argent se gagne sur le calcul. Le runtime sandbox lui-même ne génère pas de revenus, l’argent se gagne là où la limite s’exécute sur quel matériel.
Cette approche a aussi du sens pour l’utilisateur : choisir OpenShell, c’est obtenir une limite auditable et une liste d’achat matérielle claire ; choisir une plateforme gérée, c’est obtenir une solution sans opérationnel. Les deux modes de livraison ont leur propre calcul, et en regardant simplement la licence open source du dépôt, on ne peut pas voir la structure globale de l’affaire.
Revenons à la ligne de démarcation initiale. Les garde-fous des prompts contrôlent ce que le modèle dit, les limites du noyau contrôlent ce que le processus peut faire ; le premier dépend de la docilité du modèle, le second de la justesse des politiques. Après avoir livré à la fois le runtime open source et le chien de garde DPU, NVIDIA a déplacé le point d’application de la sécurité des agents IA de « faire en sorte que le modèle obéisse » à « empêcher une escalade de privilèges d’aller trop loin ». On ne sait toujours pas si le modèle va perdre le contrôle, mais la distance qu’un processus peut parcourir est désormais mesurable et auditable — c’est vraiment la nouveauté dans l’annonce du 28 septembre, et la partie que le numéro de version 0.1.x n’a pas encore eu le temps de concrétiser.
Liens de référence :
- Communiqué officiel de NVIDIA
- README du dépôt officiel d’OpenShell
- Documentation d’architecture d’OpenShell
