Les agents d’IA deviennent de plus en plus opérationnels : ils ne se contentent plus d’interroger des API, ils exécutent des commandes, installent des paquets et accèdent aux fichiers. Cette autonomie expose, en théorie, des codes non audités à des informations sensibles. Face à ce risque, NVIDIA présente OpenShell, un runtime conçu pour fournir à ces agents les capacités nécessaires – lire des fichiers, appeler des API, utiliser des identifiants – tout en appliquant un confinement rigoureux.

OpenShell organise le fonctionnement de ces agents en les plaçant dans des environnements isolés, des « sandboxes ». Ce système ne se contente pas de faire confiance ; il gouverne l’action de chaque agent selon une politique déclarée par l’utilisateur. L’outil fonctionne sur deux niveaux de contrôle. Premièrement, il instrumentalise le noyau du système d’exploitation pour surveiller chaque accès au fichier, chaque appel système ou chaque connexion réseau en temps réel. Deuxièmement, il utilise une vérification formelle pour analyser les changements de politique avant qu’ils ne soient appliqués, signalant ainsi les accès potentiellement risqués pour une revue humaine.

Ce contrôle fin est essentiel. L’outil garantit que les agents n’ont jamais accès aux identifiants réels. Lorsque l’agent doit communiquer avec un point de terminaison approuvé, OpenShell ajoute les identifiants uniquement aux requêtes destinées à ces points approuvés. Selon l’annonce de github.com, l’implémentation repose sur un confinement au niveau du noyau, où chaque agent opère dans un bac à sable isolé.

Le contrôle granulaire sur Kubernetes

Pour les équipes qui déploient ces agents à l’échelle, l’intégration avec Kubernetes est une piste sérieuse. Le déploiement peut s’opérer via la passerelle (gateway) avec Helm. Les démonstrations, comme celle fournie par nirmata/demo-openshell, montrent comment OpenShell interagit avec des composants Kubernetes comme Agent Sandbox et Kyverno. Ce dernier, un garde-fou d’admission, vérifie les objets Kubernetes autour des sandboxes créées.

Dans cette configuration, OpenShell ne fournit pas son propre planificateur. Il s’appuie sur l’objet Agent Sandbox, une ressource issue de l’écosystème SIG Apps. Les agents se présentent ainsi comme des Pods standards, ce qui permet aux administrateurs Kubernetes d’employer leurs outils habituels. Néanmoins, OpenShell introduit un niveau de granularité que les politiques réseau classiques ne permettent pas d’atteindre. Une politique réseau standard peut autoriser un Pod à se connecter à un serveur, mais elle ne peut pas distinguer si le binaire curl doit pouvoir consulter des problèmes sur GitHub, sans pouvoir en créer. OpenShell, en revanche, peut appliquer cette nuance, y compris en ajustant ces règles sur un sandbox actif sans nécessiter de redémarrage.

Le flux de travail sécurisé des agents

Le processus de création d’un sandbox sur Kubernetes est complexe et séquentiel. La passerelle OpenShell, initiée via TLS, envoie une requête qui est enregistrée comme source de vérité, et non le Pod lui-même. Après validation, le système crée une série de ressources. Le contrôle de réseau est mis en place en premier lieu par le pilote Kubernetes, garantissant qu’aucun trafic sortant n’est autorisé par défaut. Ensuite, le Pod est créé, mais maintenu en attente par un « portail de planification » tant que le runtime OpenShell n’a pas validé des critères stricts : absence d’utilisateur root, absence de capacités spécifiques, utilisation de seccomp, etc.

Le superviseur est créé ensuite. Il agit comme point de passage obligatoire pour tous les échanges de l’agent. Lorsque l’agent tente une requête externe, elle passe par ce superviseur. Ce dernier vérifie la destination, le binaire exécuté et le type de requête HTTP avant de relayer le trafic. C’est cette chaîne de validation qui assure que les capacités données à l’agent sont strictement délimitées par la politique déclarée.

Pour ceux qui souhaitent intégrer cette solution, des SDK existent pour Python, TypeScript, Go et Rust, permettant aux applications de se connecter à la passerelle OpenShell. Ces outils permettent d’interfacer avec le système, mais ne remplacent pas le CLI pour la gestion des politiques et des sandboxes.

Sources

• GitHub – NVIDIA/OpenShell: OpenShell is the safe, private runtime for autonomous AI agents., github.com
• GitHub – nirmata/demo-openshell: Demo of OpenShell and Kyverno, github.com
• OpenShell on Kubernetes: A guide for platform engineers, CNCF, 4 novembre 2026 (contenu sous licence CC BY 3.0)
• The 5 essential layers of AI agent sandboxing on Kubernetes, The New Stack, 29 octobre 2026
• Your AI Agent Needs an Operating Environment. Who’s Engineering It?, DevOps.com, 3 novembre 2026