Runtime sandboxé pour agents IA autonomes avec des politiques YAML déclaratives appliquant des contraintes sur le système de fichiers, le réseau et les processus, ainsi qu'une injection d'identifiants liée aux points de terminaison.
OpenShell est le runtime sûr et privé pour les agents IA autonomes. Il fournit des environnements d'exécution en bac à sable qui protègent vos données, vos identifiants et votre infrastructure — régis par des politiques YAML déclaratives qui empêchent les accès non autorisés aux fichiers, l'exfiltration de données et l'activité réseau non contrôlée.
OpenShell est conçu selon une approche « agent-first ». Il fournit des compétences d'agent publiques pour utiliser et exploiter OpenShell, ainsi que des workflows distincts adaptés au dépôt pour les contributeurs et les mainteneurs.
Binaire (recommandé) :```bash curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
L'installateur installe la dernière version stable par défaut. Pour installer une version spécifique, définissez `OPENSHELL_VERSION`. Une [version `dev`](https://github.com/NVIDIA/OpenShell/releases/tag/dev) est également disponible et suit le dernier commit sur `main`.
Le paquet `openshell` sur PyPI fournit uniquement le SDK Python. Il n'installe pas la CLI `openshell`. Ajoutez le SDK à un projet Python avec [uv](https://docs.astral.sh/uv/) :```bash
uv add openshell
Helm chart :
Expérimental — le chemin de déploiement Kubernetes est en cours de développement actif. Attendez-vous à des aspérités et à des changements cassants.
Déployez la passerelle OpenShell dans un cluster Kubernetes à partir du chart OCI publié sur GHCR :```bash helm install openshell oci://ghcr.io/nvidia/openshell/helm-chart
Voir [`deploy/helm/openshell/README.md`](https://github.com/nvidia/openshell/blob/main/deploy/helm/openshell/README.md) pour les versions disponibles, les conventions de tag de développement et la configuration.
Pour déployer OpenShell sur OpenShift, voir [`deploy/helm/openshell/README.md#install-on-openshift`](https://github.com/nvidia/openshell/blob/main/deploy/helm/openshell/README.md#install-on-openshift).
### Créer un sandbox```bash
openshell sandbox create -- claude # or opencode, codex, copilot
Le conteneur sandbox inclut les outils suivants par défaut :
Pour plus de détails, voir https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base.
Chaque sandbox démarre avec un accès sortant minimal. Vous ouvrez un accès supplémentaire avec une courte politique YAML que le proxy applique au niveau de la méthode HTTP et du chemin, sans redémarrer quoi que ce soit.```bash
openshell sandbox create
sandbox$ curl -sS https://api.github.com/zen curl: (56) Received HTTP code 403 from proxy after CONNECT
sandbox$ exit openshell policy set demo --policy examples/sandbox-policy-quickstart/policy.yaml --wait
openshell sandbox connect demo sandbox$ curl -sS https://api.github.com/zen Anything added dilutes everything else.
sandbox$ curl -sS -X POST https://api.github.com/repos/octocat/hello-world/issues -d '{"title":"oops"}' {"error":"policy_denied","detail":"POST /repos/octocat/hello-world/issues not permitted by policy"}
Voir le [guide complet](https://github.com/nvidia/openshell/blob/main/examples/sandbox-policy-quickstart) ou exécuter la démo automatisée :```bash
bash examples/sandbox-policy-quickstart/demo.sh
OpenShell isole chaque sandbox dans son propre conteneur avec un routage de sortie appliqué par politique. Une passerelle légère coordonne le cycle de vie des sandboxes, et chaque connexion sortante est interceptée par le moteur de politique, qui effectue l'une des trois actions suivantes :
OpenShell exécute un plan de contrôle de passerelle qui gère le cycle de vie des sandboxes via un pilote de calcul configuré. Les plateformes de calcul prises en charge incluent Docker, Podman, MicroVM et Kubernetes.
OpenShell applique une défense en profondeur sur quatre domaines de politique :
Les politiques sont des fichiers YAML déclaratifs. Les sections statiques (système de fichiers, processus) sont verrouillées à la création ; la politique réseau et les attachements de fournisseurs peuvent être mis à jour sur une sandbox en cours d'exécution.
Les agents ont besoin d'identifiants — clés API, jetons, comptes de service. OpenShell les gère en tant que providers : des ensembles d'identifiants nommés qui sont injectés dans les sandboxes à la création. La CLI découvre automatiquement les identifiants pour les agents reconnus (Claude, Codex, OpenCode, Copilot) depuis votre environnement shell, ou vous pouvez créer des providers explicitement avec openshell provider create. Les identifiants ne fuient jamais dans le système de fichiers de la sandbox ; ils sont injectés en tant que variables d'environnement à l'exécution.
L'accès à l'inférence utilise le même flux de travail de provider. Attachez un provider compatible avec l'inférence à une sandbox, appelez le point de terminaison natif du provider et sélectionnez le modèle dans le client. Les profils de provider fournissent la politique de point de terminaison et lient les espaces réservés d'identifiants à la destination autorisée.
Expérimental — Le passthrough GPU fonctionne sur les hôtes pris en charge mais est en cours de développement actif. Attendez-vous à des imperfections et à des changements cassants.
OpenShell peut transmettre les GPU de l'hôte dans les sandboxes pour l'inférence locale, le fine-tuning ou toute charge de travail GPU. Ajoutez --gpu lors de la création d'une sandbox :```bash
openshell sandbox create --gpu --from [gpu-enabled-sandbox] -- claude
Les sandboxes GPU basées sur Docker sélectionnent automatiquement CDI lorsqu'il est disponible et, sinon, se rabattent sur le chemin de requête GPU NVIDIA de Docker (`--gpus all`).
**Prérequis :** les pilotes NVIDIA et le [NVIDIA Container Toolkit](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html) doivent être installés sur l'hôte. L'image de sandbox elle-même doit inclure les pilotes et bibliothèques GPU appropriés pour votre charge de travail — l'image `base` par défaut ne le fait pas. Consultez l'[exemple BYOC](https://github.com/NVIDIA/OpenShell/tree/main/examples/bring-your-own-container) pour créer une image de sandbox personnalisée avec prise en charge du GPU.
## Agents pris en charge
| Agent | Source | Notes |
| ------------------------------------------------------------- | -------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| [Claude Code](https://docs.anthropic.com/en/docs/claude-code) | [`base`](https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base) | Fonctionne immédiatement. Le fournisseur utilise `ANTHROPIC_API_KEY`. |
| [OpenCode](https://opencode.ai/) | [`base`](https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base) | Fonctionne immédiatement. Le fournisseur utilise `OPENAI_API_KEY` ou `OPENROUTER_API_KEY`. |
| [Codex](https://developers.openai.com/codex) | [`base`](https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base) | Fonctionne immédiatement. Le fournisseur utilise `OPENAI_API_KEY`. |
| [GitHub Copilot CLI](https://docs.github.com/en/copilot/github-copilot-in-the-cli) | [`base`](https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base) | Fonctionne immédiatement. Le fournisseur utilise `GITHUB_TOKEN` ou `COPILOT_GITHUB_TOKEN`. |
| [OpenClaw](https://openclaw.ai/) | [NemoClaw](https://github.com/NVIDIA/NemoClaw) | Exécutez OpenClaw de manière plus sécurisée dans NVIDIA OpenShell avec le blueprint NemoClaw. |
| [Hermes Agent](https://github.com/NousResearch/hermes-agent) | [NemoClaw](https://github.com/NVIDIA/NemoClaw) | Exécutez Hermes Agent de manière plus sécurisée dans NVIDIA OpenShell avec le blueprint NemoClaw. |
| [Ollama](https://ollama.com/) | [Community](https://github.com/NVIDIA/OpenShell-Community) | Lancez avec `openshell sandbox create --from ollama`. |
| [Pi](https://pi.dev/) | [Community](https://github.com/NVIDIA/OpenShell-Community) | Lancez avec `openshell sandbox create --from pi`. |
## Commandes clés
| Commande | Description |
| ---------------------------------------------------------- | ----------------------------------------------- |
| `openshell sandbox create -- <agent>` | Créer une sandbox et lancer un agent. |
| `openshell sandbox connect [name]` | Se connecter en SSH à une sandbox en cours d'exécution. |
| `openshell sandbox list` | Lister toutes les sandboxes. |
| `openshell provider create --type [type] --from-existing` | Créer un fournisseur d'identifiants à partir des variables d'environnement. |
| `openshell sandbox provider attach <sandbox> <provider>` | Attacher un fournisseur à une sandbox en cours d'exécution. |
| `openshell policy set <name> --policy file.yaml` | Appliquer ou mettre à jour une politique sur une sandbox en cours d'exécution. |
| `openshell policy get <name>` | Afficher la politique active. |
| `openshell logs [name] --tail` | Diffuser les logs de la sandbox. |
| `openshell term` | Lancer l'interface utilisateur de terminal en temps réel pour le débogage. |
Consultez la [documentation complète](https://docs.nvidia.com/openshell/latest) pour les guides de commandes, les tutoriels et le matériel de référence.
## Interface utilisateur de terminal
OpenShell inclut un tableau de bord de terminal en temps réel pour surveiller les gateways, les sandboxes et les fournisseurs — inspiré de [k9s](https://k9scli.io/).```bash
openshell term
Le TUI vous offre une vue en direct, pilotée au clavier, de votre passerelle et de vos sandboxes. Naviguez avec Tab pour changer de panneau, j/k pour parcourir les listes, Enter pour sélectionner, et : pour le mode commande. L'état de la passerelle et le statut des sandboxes s'actualisent automatiquement toutes les deux secondes.
Utilisez --from pour créer des sandboxes à partir du catalogue OpenShell Community ou d'une image de conteneur :```bash
openshell sandbox create --from gemini # community catalog
docker build -t my-sandbox:latest ./my-sandbox-dir # Docker gateway
openshell sandbox create --from my-sandbox:latest # Docker built image
podman build -t localhost/my-sandbox:latest ./my-sandbox-dir # Podman gateway
openshell sandbox create --from localhost/my-sandbox:latest # Podman built image
openshell sandbox create --from registry.io/img:v1 # container image
Construisez avec le moteur de conteneurs utilisé par votre passerelle locale. Pour une passerelle distante, poussez l'image vers un registre depuis lequel la passerelle peut la récupérer.
Consultez le catalogue [OpenShell Community](https://github.com/NVIDIA/OpenShell-Community) et l'[exemple BYOC](https://github.com/NVIDIA/OpenShell/tree/main/examples/bring-your-own-container) pour plus de détails.
## Utiliser OpenShell avec votre agent
OpenShell fournit quatre compétences portables pour les utilisateurs et les opérateurs : les workflows CLI (`openshell-cli`), le dépannage de la passerelle (`debug-openshell-cluster`), le dépannage de l'inférence (`debug-inference`) et la génération de politiques (`generate-sandbox-policy`). Installez-les avec l'Agent Skills CLI :```bash
npx skills add NVIDIA/OpenShell
Ces compétences publiques et installables résident dans skills/ et utilisent l'aide de la CLI installée et la documentation publiée comme sources de vérité. Elles ne nécessitent pas de checkout du code source d'OpenShell.
OpenShell est développé en utilisant les mêmes workflows pilotés par agents qu'il permet. Les compétences des contributeurs et des mainteneurs résident séparément dans .agents/skills/ ; elles automatisent le travail sur le dépôt OpenShell et ne sont pas incluses lorsque les utilisateurs installent les compétences publiques :
create-spike ; un humain l'accepte avec state:accepted ou un placement dans la roadmap, ou le refuse. Le travail accepté peut rester sous responsabilité humaine ou entrer dans le workflow optionnel et contrôlé par un humain de planification et d'implémentation agent:*.triage-issue. Les agents établissent la validité technique et l'impact ; les humains décident si le projet doit agir et où le travail se situe dans la roadmap.review-security-issue produit une évaluation de sévérité et un plan de remédiation. fix-security-issue l'implémente.sync-agent-infra, update-docs-from-commits et d'autres workflows internes maintiennent la cohérence entre le code, la documentation et l'infrastructure des agents.L'implémentation par les agents est dirigée par des humains : un utilisateur peut demander directement une phase, ou les mainteneurs peuvent utiliser le workflow optionnel agent:* pour mettre en file d'attente et approuver la planification et l'implémentation. Voir AGENTS.md pour la documentation complète de la chaîne de workflows.
npx skills add NVIDIA/OpenShellrfcOpenShell est conçu agent-first. Les issues doivent inclure un récit utilisateur, un énoncé du problème, un impact et des critères d'acceptation. L'impact doit expliquer les conséquences du comportement actuel et pourquoi les contournements existants sont insuffisants. Les demandes de fonctionnalités nécessitent également une conception proposée au niveau du workflow et des alternatives ; les rapports de bugs ajoutent des étapes de reproduction, des détails sur l'environnement et les journaux pertinents. Une fois le travail autorisé via le workflow du projet ou une demande directe, les contributeurs doivent utiliser les compétences dans .agents/skills/ pour étudier le code et le comportement actuels, implémenter le changement et le vérifier. Si une issue contient des diagnostics antérieurs, vérifiez-les plutôt que de vous y fier. Voir CONTRIBUTING.md pour le tableau complet des compétences d'agents, le workflow de contribution et la configuration de développement.
OpenShell collecte des données de télémétrie anonymes pour aider à améliorer le projet pour les développeurs. Ces données ne sont pas utilisées pour suivre le comportement individuel des utilisateurs. Elles nous aident à comprendre l'utilisation agrégée des workflows de sandbox, de fournisseurs et de politiques afin que nous puissions prioriser les améliorations produit et partager les tendances d'utilisation avec la communauté.
Désactivez la télémétrie à l'exécution en définissant OPENSHELL_TELEMETRY_ENABLED=false sur le déploiement de la passerelle. Pour les installations Helm, définissez server.telemetryEnabled=false. OpenShell propage ce paramètre de déploiement dans les environnements du superviseur de sandbox afin que la collecte de télémétrie côté sandbox soit également désactivée.
Vous pouvez également compiler la télémétrie entièrement hors du binaire. Le support de télémétrie est une fonctionnalité Cargo telemetry activée par défaut, et chaque crate qui la porte définit également un alias defaults-without-telemetry couvrant toutes les autres fonctionnalités par défaut. Compilez des artefacts sans télémétrie avec --no-default-features --features defaults-without-telemetry :```shell
cargo build --release -p openshell-gateway --no-default-features --features defaults-without-telemetry
cargo build --release -p openshell-sandbox --no-default-features --features defaults-without-telemetry
cargo build --release -p openshell-driver-vm --no-default-features --features defaults-without-telemetry
Les binaires résultants ne contiennent aucun point de terminaison de télémétrie, aucun client HTTP de télémétrie et aucun code d'émission. Une fois la télémétrie compilée en dehors, la passerelle n'émet rien et signale la télémétrie désactivée aux sandboxes qu'elle lance. Cargo n'a aucun moyen de soustraire une seule fonctionnalité par défaut, donc `defaults-without-telemetry` doit être associé à `--no-default-features` ; le passer seul laisse les valeurs par défaut en place et fait échouer la compilation plutôt que de produire un binaire qui émet encore.
La passerelle expose également des fonctionnalités Cargo distinctes pour ses pilotes de calcul intégrés : `compute-driver-kubernetes`, `compute-driver-docker`, `compute-driver-podman`, `compute-driver-vm` et `compute-driver-mxc`. Désactivez l'ensemble des fonctionnalités par défaut, puis activez uniquement les pilotes et le mode de télémétrie requis par le binaire cible. Par exemple :```shell
# Docker only, with telemetry support.
cargo build --release -p openshell-gateway --no-default-features --features telemetry,compute-driver-docker
# Docker and VM only, with telemetry compiled out.
cargo build --release -p openshell-gateway --no-default-features --features compute-driver-docker,compute-driver-vm
# Windows MXC only, with telemetry support and bundled Z3.
cargo build --release -p openshell-gateway --no-default-features --features telemetry,compute-driver-mxc,bundled-z3
Les builds standards conservent leur ensemble de pilotes de plateforme via la fonctionnalité de compatibilité par défaut in-tree-compute-drivers. Sous Windows, compute-driver-mxc sélectionne MXC ; les quatre autres fonctionnalités installent des stubs de pilotes non pris en charge. Sur les autres plateformes, MXC est exclu.
Les événements de télémétrie se limitent à des catégories opérationnelles anonymes et à des comptages, tels que les résultats du cycle de vie du bac à sable, les compartiments de profils de fournisseurs, les comptages de décisions de politique et les catégories agrégées de refus d'activité réseau. La télémétrie d'OpenShell ne collecte pas les noms ou identifiants de bacs à sable, les noms d'hôtes, les chemins de fichiers, les chemins de binaires, les invites, les identifiants, les noms de fournisseurs, les noms de modèles ou le contenu utilisateur.
Le refus de participation ne s'applique qu'à la télémétrie émise par OpenShell. Les services tiers, fournisseurs de modèles, points de terminaison d'inférence, agents ou outils que vous configurez et utilisez avec OpenShell peuvent avoir leurs propres conditions et pratiques de confidentialité.
Nous publions des tendances d'utilisation agrégées issues de cette télémétrie toutes les deux semaines. Consultez les rapports de télémétrie de la communauté pour le dernier résumé.
Ce logiciel récupère, accède ou interagit automatiquement avec des matériaux externes. Ces matériaux récupérés ne sont pas distribués avec ce logiciel et sont régis uniquement par des conditions et licences distinctes. Vous êtes seul responsable de trouver, d'examiner et de respecter toutes les conditions et licences applicables, ainsi que de vérifier la sécurité, l'intégrité et l'adéquation de tout matériau récupéré pour votre cas d'usage spécifique. Ce logiciel est fourni « EN L'ÉTAT », sans garantie d'aucune sorte. L'auteur ne fait aucune déclaration ni garantie concernant les matériaux récupérés, et n'assume aucune responsabilité pour toute perte, dommage, responsabilité ou conséquence juridique découlant de votre utilisation ou de votre incapacité à utiliser ce logiciel ou tout matériau récupéré. Utilisez ce logiciel et les matériaux récupérés à vos propres risques.
Ce projet est sous licence Apache License 2.0.
| Catégorie | Outils |
|---|
| Agent | claude, opencode, codex, copilot |
| Langage | python (3.14), node (22) |
| Développeur | gh, git, vim, nano |
| Réseau | ping, dig, nslookup, nc, traceroute, netstat |
| Composant | Rôle |
|---|
| Gateway | API de plan de contrôle qui coordonne le cycle de vie des sandboxes et agit comme frontière d'authentification. |
| Sandbox | Environnement d'exécution isolé avec supervision de conteneur et routage de sortie appliqué par politique. |
| Policy Engine | Applique les contraintes de système de fichiers, de réseau et de processus depuis la couche applicative jusqu'au noyau. |
| Provider Access | Points de terminaison définis par profil, politique de binaires et injection d'identifiants liés aux points de terminaison pour les API de modèles et autres services. |
| Couche | Ce qu'elle protège | Quand elle s'applique |
|---|
| Filesystem | Empêche les lectures/écritures en dehors des chemins autorisés. | Verrouillée à la création de la sandbox. |
| Network | Bloque les connexions sortantes non autorisées. | Rechargeable à chaud à l'exécution. |
| Process | Bloque l'escalade de privilèges et les appels système dangereux. | Verrouillée à la création de la sandbox. |
| Providers | Accorde les identifiants liés aux points de terminaison et l'accès réseau. | Rechargeable à chaud à l'exécution. |