NVIDIA OpenShell
Runtime open source de NVIDIA qui exécute les agents IA dans des sandboxes isolées au niveau du noyau, gouvernées par une politique YAML déclarative.
SFEIR AI · Publié le 29 septembre 2026
Un runtime qui confine les agents
NVIDIA OpenShell est un runtime open source, publié sous licence Apache 2.0, qui exécute des flottes d'agents IA autonomes dans des sandboxes isolées au niveau du noyau. Ce que chaque agent peut toucher (fichiers, processus, réseau, identifiants) se déclare dans une politique YAML qu'OpenShell applique pendant l'exécution. Par défaut, tout trafic sortant est refusé.
NVIDIA l'a présenté le 16 mars 2026 à la GTC, dans son Agent Toolkit et dans NemoClaw, la pile qui l'installe avec les modèles Nemotron pour OpenClaw. La version 0.1.0 est publiée le 25 septembre 2026, après plus d'une centaine de versions 0.0.x ; le 28 septembre, OpenShell devient la pièce logicielle de la NVIDIA Open Agent Safety Platform. La page des releases du dépôt fait foi pour la version courante.
Architecture
OpenShell se compose de trois éléments :
- la gateway, plan de contrôle qui gère le cycle de vie et les politiques des sandboxes, déployable avec Helm sur Kubernetes ;
- la sandbox, qui exécute l'agent sous Landlock (accès limité aux chemins déclarés) et seccomp (blocage des appels système d'escalade), sans chemin réseau direct ;
- le superviseur, apparié à chaque sandbox et placé hors de la charge de l'agent, qui confronte chaque requête sortante à la politique compilée en OPA/Rego.
Ce que la politique contrôle
Une règle réseau nomme un hôte, un port et le binaire autorisé. Pour HTTP, GraphQL et MCP, le superviseur inspecte chaque requête : il peut autoriser une lecture et refuser une écriture sur la même API. Les identifiants sont gérés comme des providers : l'agent ne manipule qu'une valeur de substitution, remplacée par la vraie clé hors de la sandbox et seulement vers un point d'accès autorisé. Chaque décision part dans un journal au format OCSF.
Le prouveur de politique, fondé sur un solveur SMT, vérifie qu'une politique n'accorde rien au-delà d'une politique maximale ; il couvre fichiers, processus, Landlock, réseau et REST, et signale qu'il ne peut pas conclure sur les règles GraphQL ou MCP. Le conseiller de politique, désactivé par défaut, permet à un agent bloqué de proposer une règle étroite, soumise à revue humaine : l'agent ne peut pas approuver sa propre demande.
Compatibilité et limites
NVIDIA le donne compatible avec Claude Code, Codex, OpenCode, GitHub Copilot CLI, OpenClaw, Pi et Hermes, ainsi qu'avec des agents maison. Il tourne sur Docker, Podman, des microVM ou Kubernetes, sans matériel NVIDIA particulier. Cadence, Slack, Gecko Robotics et SAP (runtime de Joule Studio) figurent parmi les premiers adoptants.
L'analyse des politiques entre plusieurs agents reste un travail en cours selon NVIDIA. La gateway envoie par défaut une télémétrie anonyme de catégories et de compteurs, désactivable par la variable OPENSHELL_TELEMETRY_ENABLED=false.
Questions fréquentes
OpenShell est-il open source ?
Oui, sous licence Apache 2.0, dans le dépôt GitHub NVIDIA/OpenShell. Des SDK Python, TypeScript, Go et Rust permettent de piloter une gateway depuis une application.
Faut-il un GPU ou un DPU NVIDIA pour l'utiliser ?
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 matérielle optionnelle de la plateforme, requiert un DPU BlueField-4.
Comment OpenShell protège-t-il les clés d'API ?
L'agent ne voit qu'une valeur de substitution. Le superviseur vérifie que la politique réseau et le rattachement de l'identifiant autorisent la requête, puis injecte la vraie clé hors de la sandbox, uniquement vers le point d'accès prévu.
Le prouveur de politique couvre-t-il tout ?
Non. Sa vérification de frontière porte sur le système de fichiers, les processus, Landlock, le réseau et les requêtes REST. Face à des règles GraphQL ou MCP, il indique qu'il ne peut pas conclure.
Sources
- NVIDIA — dépôt officiel OpenShell (README, licence Apache 2.0, documentation) · 2026-09-29
OpenShell is the safe, private runtime for fleets of autonomous AI agents.
- NVIDIA — releases OpenShell (v0.1.0 du 25/09/2026, v0.1.2 du 28/09/2026) · 2026-09-29
- NVIDIA Docs — Overview of NVIDIA OpenShell · 2026-09-29
NVIDIA OpenShell is an open-source runtime for executing fleets of autonomous AI agents in sandboxed environments with kernel-level isolation.
- NVIDIA Technical Blog — Add Runtime Controls to AI Agents with NVIDIA OpenShell (Watson, Golshan) · 2026-09-28
The proposal remains pending for human review by default, and the agent cannot approve its own request.
- NVIDIA Newsroom — NVIDIA Announces NemoClaw · 2026-03-16
NVIDIA OpenShell dans vos projets
Échanger avec SFEIRArticles liés
NVIDIA OpenShell : confiner Claude Code, Codex et OpenClaw par une politique YAML
OpenShell, le runtime open source de NVIDIA, enferme chaque agent dans une sandbox sans réseau direct et fait passer ses requêtes par un superviseur qui applique une politique YAML. Version 0.1.2 au 28 septembre 2026 : ce qui se déploie aujourd'hui, et ses limites.
NVIDIA Open Agent Safety Platform : sécuriser les agents IA hors de l'agent
Le 28 septembre 2026, NVIDIA a lancé une plateforme ouverte qui place les contrôles des agents IA hors de leur portée : OpenShell côté logiciel, Sentry côté silicium. Elle arrive après un été d'évasions de sandbox chez OpenAI, Anthropic, Meta et Google.
NVIDIA Sentry : la sécurité des agents IA passe par le silicium
Sentry, la couche matérielle de l'Open Agent Safety Platform de NVIDIA, surveille les agents IA depuis un DPU BlueField-4. Conception de référence sans date de disponibilité, elle pose une question de souveraineté : la garantie la plus forte n'existe que sur du matériel NVIDIA.
Déploiements durcis : NVIDIA NemoClaw, Archestra et Docker/VPS durci
Si l'entreprise décide d'utiliser OpenClaw, elle doit le faire dans un cadre durci. Trois options selon la maturité : NVIDIA NemoClaw (isolation kernel, encore en alpha), Archestra (RBAC/SSO) ou un déploiement Docker/VPS durci maison.
Déployer Hermès Agent en environnement maîtrisé : backends sandboxés et persistance serverless
Hermès Agent propose six backends d'exécution (local, Docker, SSH, Singularity, Modal, Daytona) qui déterminent où les commandes s'exécutent, et donc le rayon d'explosion en cas de dérapage. Le backend par défaut n'isole rien : comment choisir et durcir chaque backend pour la production.