NVIDIA OpenShell : confiner Claude Code, Codex et OpenClaw par une politique YAML

D'où vient OpenShell

NVIDIA a présenté OpenShell à la GTC le 16 mars 2026, dans son Agent Toolkit et dans NemoClaw, la pile qui installe en une commande les modèles Nemotron et ce runtime pour OpenClaw. Six mois et plus d'une centaine de versions 0.0.x plus tard, le dépôt publie la 0.1.0 le 25 septembre ; la 0.1.2 sort le 28, jour où NVIDIA l'intègre à son Open Agent Safety Platform et le déclare largement disponible. Le dépôt NVIDIA/OpenShell comptait environ 9 400 étoiles et 1 300 forks le 29 septembre.

La documentation le définit comme un runtime open source qui exécute des flottes d'agents autonomes dans des sandboxes isolées au niveau du noyau, gouvernées par une politique YAML déclarative. Le README ajoute la promesse centrale : l'agent ne voit jamais les vrais identifiants.

Trois pièces : gateway, superviseur, sandbox

Alex Watson et Ali Golshan décrivent l'architecture dans le billet technique du 28 septembre. La gateway gère le cycle de vie et les politiques de nombreuses sandboxes ; c'est le plan de contrôle, déployable avec Helm sur Kubernetes. Chaque sandbox exécute l'agent avec des contrôles noyau sur son système de fichiers et ses processus : Landlock limite l'accès aux chemins déclarés, seccomp bloque les appels système qui ouvriraient une escalade de privilèges. Modifier ces deux réglages impose de recréer la sandbox. Le superviseur, apparié à chaque sandbox, tourne hors de la charge de l'agent et reste son seul chemin réseau.

Les règles réseau, elles, se rechargent à chaud. La politique s'écrit en YAML et OpenShell la compile en OPA/Rego, évalué à chaque requête sortante. Voici la règle du tutoriel officiel qui autorise curl à lire l'API GitHub sans pouvoir y écrire :

network_policies:
  github_api:
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/curl

La règle nomme la destination et le binaire autorisé à l'atteindre. Avec protocol: rest, le superviseur termine le TLS et lit chaque requête HTTP : un GET passe, un POST sur la même API reçoit une erreur 403 qui cite la règle en cause. NVIDIA étend cette inspection à GraphQL et aux appels MCP, pour autoriser une requête de lecture et refuser une écriture qui passent par le même point d'accès. Une règle trop large sur api.github.com ne suffit donc plus à laisser un agent pousser du code.

Des clés d'API que l'agent ne voit jamais

OpenShell gère les identifiants comme des providers. Une commande comme openshell provider create --type claude-code --from-existing lit la clé Anthropic de l'environnement local et la stocke côté gateway. Dans la sandbox, l'agent manipule une valeur de substitution. Le superviseur vérifie que la politique réseau et le rattachement de l'identifiant autorisent tous deux la requête, puis injecte la vraie clé hors de la charge de l'agent, et seulement vers le point d'accès autorisé.

Un agent victime d'une injection de prompt peut donc lire tout son environnement sans y trouver de secret exploitable. S'il envoie la valeur de substitution vers un domaine non prévu, la requête est refusée et le refus journalisé.

Prouveur, conseiller, journal

Le prouveur de politique s'appuie sur un solveur SMT. Sa vérification de frontière compare une politique candidate à une politique maximale fixée par l'entreprise, et montre un contre-exemple quand la candidate autorise davantage. Un agent parent peut ainsi vérifier que la politique qu'il écrit pour un sous-agent reste dans ses propres limites. NVIDIA rapporte que des agents frontier aux garde-fous allégés ont passé jusqu'à deux heures à essayer de convaincre un relecteur IA de leur accorder l'écriture sur un dépôt GitHub protégé, sans y parvenir.

Le conseiller de politique, désactivé par défaut, laisse un agent bloqué proposer une règle réseau étroite : un hôte, un port, un binaire, une méthode et un chemin. La proposition passe un contrôle de risque du prouveur, qui signale par exemple l'accès aux adresses de métadonnées cloud ou une nouvelle destination pour un identifiant, puis attend une validation humaine. L'agent ne peut pas approuver sa propre demande. L'approbation automatique des propositions sans alerte existe, mais il faut l'activer.

Chaque décision, autorisation ou refus, part dans un journal au format OCSF (Open Cybersecurity Schema Framework), un schéma ouvert d'événements de sécurité. Chaque ligne donne la destination, la règle appliquée et le motif du refus ; les refus au niveau de la connexion nomment aussi le binaire qui l'a tentée :

[sandbox] [OCSF ] [ocsf] HTTP:POST [MED] DENIED POST http://api.github.com:443/repos/octocat/hello-world/issues [policy:github_api engine:l7]

Qui l'utilise déjà

NVIDIA cite trois adoptants : Cadence pour un agent de conception de puces, Slack pour sa plateforme d'agents à la demande, Gecko Robotics pour gouverner des robots physiques. SAP intègre OpenShell au runtime de Joule Studio, dans sa SAP Business AI Platform, et contribue au code sur l'architecture, les opérations Kubernetes, les images et l'observabilité. Andre Lamego, qui signe le billet de SAP, place encore sur la feuille de route le lien entre l'isolation d'OpenShell et la gouvernance métier de Joule Studio, ainsi que les habilitations FedRAMP et FIPS. Canonical et SUSE figurent parmi les éditeurs de systèmes d'exploitation partenaires, Red Hat dans la liste courte du communiqué.

Côté agents, la FAQ de NVIDIA liste Claude Code, Codex, OpenCode, GitHub Copilot CLI et OpenClaw ; le billet technique ajoute Pi et Hermes. Une équipe peut aussi apporter son propre agent et sa propre image de sandbox.

Les limites de la version 0.1

Le prouveur ne couvre pas tout. Sa vérification de frontière porte sur le système de fichiers, l'identité des processus, Landlock, le réseau et les requêtes REST. Face à une règle GraphQL ou MCP, il déclare ne pas pouvoir conclure plutôt que d'ignorer la règle. Les politiques qui filtrent des appels MCP, souvent les plus sensibles pour un agent de code, échappent donc à la preuve formelle.

Le multi-agents reste un chantier. NVIDIA qualifie de travail en cours l'analyse des politiques croisées, quand l'accès d'un agent se combine à celui d'un autre. Une flotte d'agents qui se passent des résultats peut reconstituer un droit qu'aucune politique individuelle n'accorde.

Sur Kubernetes, le confinement réseau dépend du cluster : la documentation exige un CNI qui applique les NetworkPolicy. Et la gateway envoie par défaut une télémétrie anonyme de catégories et de compteurs d'usage ; NVIDIA précise qu'elle exclut noms de sandbox, chemins, prompts et identifiants. Une variable d'environnement la coupe (OPENSHELL_TELEMETRY_ENABLED=false), et une DSI la coupera avant tout déploiement.

La cadence enfin : plus de cent versions 0.0.x en six mois, trois versions 0.1.x en quatre jours. NVIDIA annonce une cadence de publication stable à partir de la 0.1, mais un projet de cet âge se teste sur un périmètre restreint avant de porter des agents de production.

Par où commencer

Pour une équipe qui fait déjà tourner des agents de code, un premier essai tient en une demi-journée :

• installer la CLI et une gateway locale sur un poste Linux ou un Mac Apple Silicon avec Docker ou Podman, et couper la télémétrie ;
• créer une sandbox, lancer l'agent habituel dedans et lire le journal des refus : il dresse l'inventaire réel des accès dont l'agent a besoin ;
• transformer cet inventaire en politique versionnée dans Git, relue comme du code, avec un fichier de frontière vérifié par openshell-prover en CI ;
• déclarer les clés d'API comme providers plutôt que comme variables d'environnement dans l'image ;
• brancher le journal OCSF sur le SIEM avant d'étendre l'usage.

Ce parcours rejoint ce que nous décrivions pour déployer Hermes Agent en environnement maîtrisé et pour gouverner les outils d'OpenClaw : la politique de l'agent devient un artefact d'ingénierie, écrit, relu, testé et audité. La page contrôles d'exécution des agents situe OpenShell parmi les autres approches.

FAQ

OpenShell est-il gratuit ? Oui. Le code est publié sous licence Apache 2.0 sur GitHub, dans le dépôt NVIDIA/OpenShell, avec des SDK Python, TypeScript, Go et Rust.

Faut-il un GPU ou un DPU NVIDIA ? Non. OpenShell tourne sur Linux, macOS Apple Silicon ou Windows avec WSL 2 (expérimental), avec Docker, Podman, des microVM ou Kubernetes. Seul Sentry, la couche optionnelle de la plateforme, exige un DPU BlueField-4.

Quels agents fonctionnent dans OpenShell ? NVIDIA cite Claude Code, Codex, OpenCode, GitHub Copilot CLI, OpenClaw, Pi et Hermes. Un agent maison fonctionne aussi, dans l'image de sandbox par défaut ou dans une image fournie par l'équipe.

OpenShell remplace-t-il les garde-fous du modèle ? Non, il les complète. Les garde-fous et le prompt orientent ce que l'agent tente ; la politique d'OpenShell décide de ce qui s'exécute, même si l'agent a été manipulé.

Sources

Officiel NVIDIA

1. Alex Watson, Ali Golshan, « Add Runtime Controls to AI Agents with NVIDIA OpenShell », NVIDIA Technical Blog, 28 septembre 2026 — developer.nvidia.com.
2. « Overview of NVIDIA OpenShell », documentation NVIDIA — docs.nvidia.com.
3. Dépôt NVIDIA/OpenShell : README, licence Apache 2.0, tutoriel « Sandbox Policy Quickstart », pages « Policy Prover », « Policy Advisor » et « Providers » (commit du 28 septembre 2026) — github.com.
4. Releases NVIDIA/OpenShell : v0.1.0 (25 septembre 2026), v0.1.1 (26 septembre), v0.1.2 (28 septembre) — github.com.
5. Page produit « NVIDIA Open Agent Safety Platform » et FAQ — nvidia.com.
6. « NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment », NVIDIA Newsroom, 28 septembre 2026 — nvidianews.nvidia.com.
7. « NVIDIA Announces NemoClaw », NVIDIA Newsroom, 16 mars 2026 — nvidianews.nvidia.com.

Partenaires

8. Andre Lamego, « SAP and NVIDIA OpenShell: Working Toward Governance and Security for Auditable AI Agents », SAP News, 28 septembre 2026 — news.sap.com.