Agent IA : encadrer les accès avec NVIDIA OpenShell

À quoi sert NVIDIA OpenShell pour un agent IA ?

OpenShell est un environnement d’exécution open source : il fait fonctionner l’agent et contrôle ses accès. Il se place sous l’agent, sans remplacer son raisonnement ni ses outils.

Imaginez un prestataire qui intervient dans un bâtiment. Vous lui attribuez un atelier, l’accès à certaines pièces et l’autorisation d’appeler certains fournisseurs. Vous ne lui confiez pas le passe-partout sous prétexte que sa fiche de mission indique « soyez prudent ». OpenShell matérialise ce type de limites pour les agents logiciels.

La présentation de l’environnement d’exécution décrit les restrictions du système de fichiers, les contrôles réseau, les restrictions des processus et la protection des identifiants des fournisseurs. Landlock est le mécanisme du noyau Linux qui limite l’accès aux fichiers ; seccomp restreint les appels système, ces requêtes de bas niveau qu’un programme adresse au système d’exploitation. Ces règles s’appliquent indépendamment du raisonnement de l’agent.

La passerelle gère les bacs à sable et les accès. Un superviseur situé hors du bac à sable vérifie les requêtes sortantes au regard de la politique et fournit les identifiants lorsque celle-ci l’autorise. L’outil de preuve des politiques vérifie que les permissions modélisées respectent les limites définies. Ces mécanismes encadrent ce que l’agent peut faire ; ils ne garantissent pas la justesse du travail autorisé.

NVIDIA décrit des possibilités d’utilisation avec Claude Code, Codex, GitHub Copilot CLI, Hermes, LangChain Deep Agents, OpenClaw et OpenCode, ainsi qu’avec des agents et des images personnalisés. « Pris en charge » ne signifie pas que tous les outils sont préinstallés : l’environnement de travail par défaut repose actuellement sur une image Ubuntu minimale, sans les CLI des agents, ces programmes en ligne de commande qui permettent de les lancer.

Pour l’entreprise, le changement tient à la réutilisation des permissions. Sans limites réutilisables, chaque nouveau workflow d’agent peut relancer les discussions sur les fichiers, les secrets et les services à exposer. Avec ce cadre, l’équipe peut associer ces décisions à la charge de travail et examiner leurs évolutions. Mesurez le résultat en heures d’ingénierie consacrées à la configuration des accès et aux interruptions ; aucun gain de temps universel vérifié ne peut servir de référence.

Sur quelles plateformes fonctionne-t-il aujourd’hui ?

Choisissez l’hôte à partir de la matrice de prise en charge actuelle. Ce guide suit la documentation portant la version v0.1.7, consultée le 8 novembre 2026.

WSL 2 exécute un environnement Linux sous Windows. MXC constitue une autre voie d’isolation, native sous Windows. La « prise en charge de Windows » ne désigne donc pas un parcours d’installation unique dont les variantes seraient interchangeables.

L’annonce de collaboration autour de Windows décrit l’arrivée d’OpenShell sur Windows via MXC. Cette orientation ne fait pas de la voie native une installation stable et standard aujourd’hui. La documentation actuelle précise explicitement que les canaux de distribution habituels ne fournissent pas de binaires Windows natifs.

Pour une première évaluation, retenez une configuration Linux ou Apple Silicon prise en charge. La matrice de prise en charge précise aussi les exigences concernant le noyau et l’environnement d’exécution : Linux 6.2 a introduit l’ABI Landlock nécessaire, mais la version du noyau ne suffit pas. L’environnement d’exécution doit réussir les vérifications requises. Avec Docker Desktop sous macOS, ces mécanismes Linux fonctionnent dans sa machine virtuelle Linux. Les processeurs NVIDIA Vera ne sont pas nécessaires.

Installer la CLI et lancer son premier agent

Partez de l’exemple OpenCode documenté par NVIDIA. Il met en évidence les trois ingrédients : un fournisseur pour l’accès au service, une image contenant l’agent et un bac à sable pour l’exécuter. Les étapes ci-dessous proviennent de la documentation ; elles ne constituent pas un compte rendu de test local.

1. Préparer l’hôte et installer OpenShell. Pour la voie Docker, Docker Desktop doit être lancé, ou Docker Engine 28.0 ou ultérieur doit être disponible. Sur les configurations Linux ou macOS prises en charge, le guide d’installation utilise curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh. Examinez le script avant de l’exécuter. Il installe la CLI, l’outil de preuve des politiques et la passerelle locale. Lancez openshell status pour vérifier que la CLI peut joindre la passerelle.

2. Configurer le service de modèles. L’exemple utilise OpenRouter. Définissez OPENROUTER_API_KEY dans l’environnement de l’hôte avant de créer le fournisseur. Un profil de fournisseur décrit les points de terminaison des services et les chemins des exécutables autorisés ; le fournisseur conserve les identifiants. Le profil d’exemple de NVIDIA autorise /usr/local/bin/opencode à joindre openrouter.ai.

3. Importer le profil, créer le fournisseur et lancer l’image. Exécutez ces commandes sur l’hôte, dans cet ordre :

openshell profile import \
  --url https://raw.githubusercontent.com/NVIDIA/OpenShell/main/providers/openrouter.yaml
openshell provider create \
  --name openrouter --type openrouter --from-existing
openshell sandbox create \
  --name my-agent \
  --from ghcr.io/anomalyco/opencode:latest \
  --provider openrouter \
  -- opencode -m openrouter/nvidia/nemotron-3.5-lightning:free

L’image fournit OpenCode ; la commande placée après -- le lance comme processus principal. Le guide de démarrage du premier agent utilise ce modèle gratuit sans nécessiter de crédits OpenRouter. Il s’agit du modèle choisi pour l’exemple, pas d’une promesse de gratuité pour n’importe quel usage des modèles.

4. Examiner les demandes d’accès depuis l’hôte. Lorsqu’un agent tente de joindre une destination non approuvée, OpenShell refuse la requête et prépare une proposition de règle au périmètre restreint. Lancez openshell rule get my-agent --status pending. Si une proposition correspond aux accès prévus pour la mission, approuvez-la spécifiquement avec openshell rule approve my-agent --chunk-id <chunk-id>, en remplaçant le paramètre fictif par son véritable identifiant. La règle est rechargée et l’agent peut réessayer.

5. Vérifier les permissions réellement accordées. Exécutez openshell policy get my-agent --base, puis openshell policy get my-agent --full. La première commande affiche la politique de base ; la seconde inclut les règles apportées par les fournisseurs. Examinez les permissions effectives avant d’ajouter un véritable projet ou un service sensible.

Une fois l’évaluation jetable terminée, supprimez le bac à sable avec openshell sandbox delete my-agent.

Quelles politiques peuvent changer à chaud ?

Les accès réseau peuvent évoluer pendant une tâche. Modifier les limites du système de fichiers ou des processus nécessite de créer un nouveau bac à sable.

« À chaud » ne signifie pas sans conséquence. Les nouvelles règles réseau ferment les connexions ouvertes avec les règles précédentes : les clients doivent donc se reconnecter. L’enregistrement d’un nouveau service de middleware externe nécessite de configurer puis de redémarrer la passerelle. Ajouter un chemin de fichiers à la politique enregistrée ne donne pas accès à ce chemin à la charge de travail déjà lancée ; retirer des chemins ou modifier les paramètres de démarrage est refusé après le lancement. Le guide de gestion des politiques détaille ces différences.

Autre piège : l’absence de fichier de politique ne signifie pas l’absence d’accès. Une politique peut provenir de l’image, d’un paramètre d’environnement ou d’une politique globale de la passerelle. Les fournisseurs rattachés peuvent ajouter des règles réseau. Les règles de sélection des politiques précisent également qu’une politique globale remplace celle du bac à sable ; elle ne constitue pas simplement une couche de restrictions supplémentaire.

Une politique lisible pour un agent de programmation

Donnez à un agent chargé de corriger des bugs un répertoire de projet accessible en écriture et un accès API en lecture seule avant de l’autoriser à publier des modifications.

Voici un exemple de politique pour une image de programmation préparée, avec le projet dans /workspace et curl installé dans /usr/bin/curl. Enregistrez-le sous policy.yaml et passez --policy ./policy.yaml lors de la création d’un nouveau bac à sable. Ce modèle correspond à cette organisation de l’image ; il ne peut pas remplacer tel quel la politique de toutes les images d’agents :

version: 1
filesystem_policy:
  include_workdir: false
  read_only: [/usr, /lib, /etc]
  read_write: [/workspace, /tmp]
landlock:
  compatibility: hard_requirement
network_policies:
  github_readonly:
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/curl

L’agent peut modifier le projet et les fichiers temporaires. La règle réseau autorise l’exécutable désigné à envoyer des requêtes GET, HEAD et OPTIONS à l’API GitHub. Elle ne donne pas un accès à Internet à n’importe quel programme, n’autorise pas le téléchargement de paquets et ne permet pas les opérations Git push. Le fournisseur de modèles se configure séparément.

Préparez les éventuels répertoires d’état de l’agent qui doivent être accessibles en écriture dans l’image, et ajoutez-les explicitement. Ces chemins désignent le système de fichiers du bac à sable. N’en déduisez pas qu’un répertoire du même nom sur l’hôte est automatiquement accessible. Par ailleurs, des chemins de base du système de fichiers sont ajoutés pour les charges de travail disposant d’un accès réseau : ce court fichier YAML ne signifie donc pas que le périmètre effectif se limite aux chemins énumérés.

Deux paramètres méritent votre attention. hard_requirement empêche le démarrage si les règles utilisateur du système de fichiers ne peuvent pas être appliquées, même si certains chemins absents ou inaccessibles peuvent tout de même être ignorés. enforcement: enforce bloque les requêtes inspectées non autorisées ; le mode audit, utilisé par défaut dans le schéma, journalise les violations et laisse passer ces requêtes. Consultez la référence du schéma des politiques avant d’adapter ce modèle.

Testez les autorisations comme les refus. Le tutoriel sur les politiques réseau de NVIDIA vérifie que curl -s https://api.github.com/zen réussit avec la règle de lecture seule, puis qu’une requête POST est refusée. Consultez openshell logs my-agent --since 5m --source sandbox depuis l’hôte. Pour votre projet, testez aussi une écriture de fichier prévue et un accès à un fichier hors périmètre. Le simple fait que l’agent démarre ne suffit pas à valider une politique de sécurité.

Cinq workflows à essayer en priorité

Les meilleurs premiers cas d’usage ont un périmètre clair et un responsable humain capable de juger le résultat. Les voici classés selon leur valeur opérationnelle probable :

Aucun de ces workflows ne rend le code généré correct ni le diagnostic d’un incident fiable. Leur intérêt consiste à limiter ce qui peut se produire pendant le travail de l’agent. Pour élargir le choix d’outils, consultez les meilleurs outils de sécurité pour les bacs à sable IA en 2026 ; pour choisir une plateforme d’exécution, consultez les meilleurs bacs à sable d’exécution de code pour agents IA en 2026.

Deux offres à construire autour d’OpenShell

La piste la plus prometteuse est un kit de mise en service d’agents de programmation en équipe. L’acheteur est un responsable plateforme qui veut permettre aux développeurs de travailler efficacement dans un environnement approuvé. DataForSEO estime à 1,300 le nombre de recherches mensuelles pour « claude code sandbox » sur le marché renvoyé par la requête de cette exécution. Cela témoigne d’un intérêt pour la configuration, pas de 1,300 clients potentiels ; certains internautes cherchent d’ailleurs le bac à sable propre à l’agent plutôt qu’OpenShell.

La plus petite offre commercialisable pourrait prendre en charge un agent et une configuration d’hôte approuvée : une image préparée, une politique examinée, une checklist de configuration du fournisseur et des tests reproductibles d’autorisation et de refus. Vendez un déploiement opérationnel pour l’équipe, en définissant clairement la responsabilité des mises à jour. La difficulté est la maintenance : les chemins des images, le comportement des agents et les interfaces expérimentales peuvent changer. Interrogez des responsables plateforme sur cette charge de maintenance avant de développer un produit hébergé.

Un atelier de revue des politiques constitue la deuxième piste. Les équipes sécurité pourraient s’en servir pour visualiser ce qu’autorise une politique effective, comparer les modifications et consigner les approbations. DataForSEO estime à 480 le nombre de recherches mensuelles pour « ai agent security », contre 70 pour « ai agent security tools ». Ces requêtes distinctes donnent des indications générales sur la demande ; il ne faut pas les additionner pour en déduire un nombre d’acheteurs uniques.

Un MVP pourrait importer les politiques de base et effectives, faire ressortir les destinations et les permissions de requêtes ajoutées, puis joindre les résultats de test à un dossier de revue. La difficulté tient à la différenciation : OpenShell dispose déjà de fonctions d’analyse des politiques, de propositions et de journaux. Le produit doit améliorer le processus de revue de l’équipe, au-delà d’un tableau de bord habillant les commandes existantes. Commencez par le kit de mise en service, dont l’acheteur et le livrable sont plus faciles à définir.

Quelles sont les limites d’OpenShell ?

OpenShell limite les accès ; il ne décide pas si une action autorisée est une bonne décision pour l’entreprise. Un agent autorisé à écrire dans les fichiers du projet peut toujours produire un mauvais correctif. Une destination externe approuvée peut toujours recevoir les données que votre politique permet de lui transmettre. Les accès aux fichiers et l’approbation des points de terminaison doivent refléter ce que vous souhaitez réellement exposer.

OpenShell ne remplace pas non plus les systèmes d’identité, les coffres de secrets, la supervision ou la gouvernance. L’annonce de NVIDIA sur les contrôles à l’exécution situe l’application des règles hors de la charge de travail de l’agent. Considérez-la comme une composante du système environnant, pas comme une raison d’abandonner les autres.

Le projet propose désormais des versions stables destinées à la production dans le cadre de sa matrice de prise en charge : présenter tout OpenShell comme une démonstration expérimentale serait donc trompeur. Les limites sont plus précises : les interfaces expérimentales peuvent changer dans les versions correctives, la version Windows native reste en développement et NVIDIA indique que son profil de qualification actuel ne couvre pas l’ensemble de sa politique de qualification des versions. Figez la version déployée et validez la combinaison exacte de la charge de travail et de l’hôte.

À faire dès lundi : demandez au responsable plateforme de choisir un dépôt non sensible et un agent. Installez OpenShell sur un hôte pris en charge, préparez l’image, définissez les accès aux fichiers et au réseau, puis testez une opération autorisée et une opération bloquée. Relevez le temps de configuration et les heures d’ingénierie consacrées à la gestion des interruptions pendant la première semaine. Élargissez le périmètre seulement lorsque l’équipe peut justifier chaque permission accordée.

Pour intégrer ces mécanismes au workflow de votre équipe, nous pouvons vous aider à mettre en place les contrôles nécessaires en production.