Sandbox-Laufzeitumgebung für autonome KI-Agenten mit deklarativen YAML-Richtlinien, die Dateisystem-, Netzwerk- und Prozessbeschränkungen durchsetzen, sowie endpunktgebundener Anmeldedaten-Injektion.
OpenShell ist die sichere, private Laufzeitumgebung für autonome KI-Agenten. Sie bietet sandboxed Ausführungsumgebungen, die Ihre Daten, Anmeldeinformationen und Infrastruktur schützen – gesteuert durch deklarative YAML-Richtlinien, die unbefugten Dateizugriff, Datenexfiltration und unkontrollierte Netzwerkaktivität verhindern.
OpenShell ist agent-first konzipiert. Es werden öffentliche Agent-Skills für die Nutzung und den Betrieb von OpenShell bereitgestellt, sowie separate repository-aware Workflows für Mitwirkende und Maintainer.
Binär (empfohlen):```bash curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
Der Installer installiert standardmäßig die neueste stabile Version. Um eine bestimmte Version zu installieren, setze `OPENSHELL_VERSION`. Ein [`dev`-Release](https://github.com/NVIDIA/OpenShell/releases/tag/dev) ist ebenfalls verfügbar, das dem neuesten Commit auf `main` folgt.
Das `openshell`-Paket auf PyPI stellt nur das Python SDK bereit. Es installiert nicht die `openshell` CLI. Füge das SDK mit [uv](https://docs.astral.sh/uv/) zu einem Python-Projekt hinzu:```bash
uv add openshell
Helm-Chart:
Experimentell — der Kubernetes-Deployment-Pfad befindet sich in aktiver Entwicklung. Mit rauen Kanten und brechenden Änderungen ist zu rechnen.
Stelle das OpenShell-Gateway aus dem im GHCR veröffentlichten OCI-Chart in einem Kubernetes-Cluster bereit:```bash helm install openshell oci://ghcr.io/nvidia/openshell/helm-chart
Siehe [`deploy/helm/openshell/README.md`](https://github.com/nvidia/openshell/blob/main/deploy/helm/openshell/README.md) für verfügbare Versionen, Dev-Tag-Konventionen und Konfiguration.
Für die Bereitstellung von OpenShell auf OpenShift siehe [`deploy/helm/openshell/README.md#install-on-openshift`](https://github.com/nvidia/openshell/blob/main/deploy/helm/openshell/README.md#install-on-openshift).
### Eine Sandbox erstellen```bash
openshell sandbox create -- claude # or opencode, codex, copilot
Der Sandbox-Container enthält standardmäßig die folgenden Tools:
Weitere Details finden Sie unter https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base.
Jede Sandbox startet mit minimalem ausgehenden Zugriff. Sie öffnen zusätzlichen Zugriff mit einer kurzen YAML-Richtlinie, die der Proxy auf HTTP-Methoden- und Pfadebene durchsetzt, ohne dass etwas neu gestartet werden muss.```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"}
Siehe die [vollständige Schritt-für-Schritt-Anleitung](https://github.com/nvidia/openshell/blob/main/examples/sandbox-policy-quickstart) oder führe die automatisierte Demo aus:```bash
bash examples/sandbox-policy-quickstart/demo.sh
OpenShell isoliert jede Sandbox in ihrem eigenen Container mit richtlinienkonformem Egress-Routing. Ein leichtgewichtiges Gateway koordiniert den Sandbox-Lebenszyklus, und jede ausgehende Verbindung wird von der Policy Engine abgefangen, die eine von drei Aktionen ausführt:
| Komponente | Rolle |
|---|
OpenShell betreibt eine Gateway-Control-Plane, die den Sandbox-Lebenszyklus über einen konfigurierten Compute-Treiber verwaltet. Unterstützte Compute-Plattformen umfassen Docker, Podman, MicroVM und Kubernetes.
OpenShell wendet Defense in Depth über vier Richtliniendomänen an:
Richtlinien sind deklarative YAML-Dateien. Statische Abschnitte (Dateisystem, Prozess) werden bei der Erstellung gesperrt; Netzwerkrichtlinien und Provider-Anbindungen können auf einer laufenden Sandbox aktualisiert werden.
Agenten benötigen Anmeldedaten — API-Schlüssel, Tokens, Service Accounts. OpenShell verwaltet diese als Provider: benannte Anmeldedaten-Bundles, die bei der Erstellung in Sandboxes injiziert werden. Die CLI erkennt Anmeldedaten für bekannte Agenten (Claude, Codex, OpenCode, Copilot) automatisch aus Ihrer Shell-Umgebung, oder Sie können Provider explizit mit openshell provider create erstellen. Anmeldedaten gelangen niemals in das Sandbox-Dateisystem; sie werden zur Laufzeit als Umgebungsvariablen injiziert.
Der Inferenzzugriff verwendet denselben Provider-Workflow. Hängen Sie einen inferenzfähigen Provider an eine Sandbox an, rufen Sie den nativen Endpunkt des Providers auf und wählen Sie das Modell im Client aus. Provider-Profile tragen die Endpunktrichtlinie bei und binden Anmeldedaten-Platzhalter an das autorisierte Ziel.
Experimentell — GPU-Passthrough funktioniert auf unterstützten Hosts, befindet sich jedoch in aktiver Entwicklung. Rechnen Sie mit Ecken und Kanten sowie Breaking Changes.
OpenShell kann Host-GPUs in Sandboxes durchreichen für lokale Inferenz, Fine-Tuning oder jede GPU-Workload. Fügen Sie --gpu beim Erstellen einer Sandbox hinzu:```bash
openshell sandbox create --gpu --from [gpu-enabled-sandbox] -- claude
Docker-gestützte GPU-Sandboxes wählen automatisch CDI aus, wenn verfügbar, und fallen andernfalls auf den NVIDIA-GPU-Anfragepfad von Docker zurück (`--gpus all`).
**Voraussetzungen:** NVIDIA-Treiber und das [NVIDIA Container Toolkit](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html) müssen auf dem Host installiert sein. Das Sandbox-Image selbst muss die entsprechenden GPU-Treiber und Bibliotheken für Ihre Workload enthalten — das Standard-`base`-Image tut dies nicht. Siehe das [BYOC-Beispiel](https://github.com/NVIDIA/OpenShell/tree/main/examples/bring-your-own-container) zum Erstellen eines benutzerdefinierten Sandbox-Images mit GPU-Unterstützung.
## Unterstützte Agents
| Agent | Quelle | Hinweise |
| ------------------------------------------------------------- | -------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| [Claude Code](https://docs.anthropic.com/en/docs/claude-code) | [`base`](https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base) | Funktioniert sofort. Provider verwendet `ANTHROPIC_API_KEY`. |
| [OpenCode](https://opencode.ai/) | [`base`](https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base) | Funktioniert sofort. Provider verwendet `OPENAI_API_KEY` oder `OPENROUTER_API_KEY`. |
| [Codex](https://developers.openai.com/codex) | [`base`](https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base) | Funktioniert sofort. Provider verwendet `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) | Funktioniert sofort. Provider verwendet `GITHUB_TOKEN` oder `COPILOT_GITHUB_TOKEN`. |
| [OpenClaw](https://openclaw.ai/) | [NemoClaw](https://github.com/NVIDIA/NemoClaw) | Führen Sie OpenClaw sicherer innerhalb von NVIDIA OpenShell mit dem NemoClaw-Blueprint aus. |
| [Hermes Agent](https://github.com/NousResearch/hermes-agent) | [NemoClaw](https://github.com/NVIDIA/NemoClaw) | Führen Sie Hermes Agent sicherer innerhalb von NVIDIA OpenShell mit dem NemoClaw-Blueprint aus. |
| [Ollama](https://ollama.com/) | [Community](https://github.com/NVIDIA/OpenShell-Community) | Starten mit `openshell sandbox create --from ollama`. |
| [Pi](https://pi.dev/) | [Community](https://github.com/NVIDIA/OpenShell-Community) | Starten mit `openshell sandbox create --from pi`. |
## Wichtige Befehle
| Befehl | Beschreibung |
| ---------------------------------------------------------- | ----------------------------------------------- |
| `openshell sandbox create -- <agent>` | Erstellt eine Sandbox und startet einen Agent. |
| `openshell sandbox connect [name]` | SSH-Verbindung zu einer laufenden Sandbox herstellen. |
| `openshell sandbox list` | Listet alle Sandboxes auf. |
| `openshell provider create --type [type] --from-existing` | Erstellt einen Credential-Provider aus Umgebungsvariablen. |
| `openshell sandbox provider attach <sandbox> <provider>` | Hängt einen Provider an eine laufende Sandbox an. |
| `openshell policy set <name> --policy file.yaml` | Wendet eine Richtlinie auf eine laufende Sandbox an oder aktualisiert sie. |
| `openshell policy get <name>` | Zeigt die aktive Richtlinie an. |
| `openshell logs [name] --tail` | Streamt Sandbox-Logs. |
| `openshell term` | Startet die Echtzeit-Terminal-UI zum Debuggen. |
Siehe die [vollständige Dokumentation](https://docs.nvidia.com/openshell/latest) für Befehlshandbücher, Tutorials und Referenzmaterial.
## Terminal-UI
OpenShell enthält ein Echtzeit-Terminal-Dashboard zur Überwachung von Gateways, Sandboxes und Providern — inspiriert von [k9s](https://k9scli.io/).```bash
openshell term
Die TUI bietet dir eine live, tastaturgesteuerte Ansicht deines Gateways und deiner Sandboxes. Navigiere mit Tab, um zwischen Panels zu wechseln, mit j/k, um durch Listen zu navigieren, mit Enter, um auszuwählen, und mit :, um in den Befehlsmodus zu gelangen. Der Gateway-Zustand und der Sandbox-Status werden alle zwei Sekunden automatisch aktualisiert.
Verwende --from, um Sandboxes aus dem Katalog der OpenShell Community oder aus einem Container-Image zu erstellen:```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
Baue mit der Container-Engine, die von deinem lokalen Gateway verwendet wird. Für ein Remote-Gateway pushe das Image in eine Registry, von der das Gateway pullen kann.
Siehe den [OpenShell Community](https://github.com/NVIDIA/OpenShell-Community)-Katalog und das [BYOC-Beispiel](https://github.com/NVIDIA/OpenShell/tree/main/examples/bring-your-own-container) für Details.
## OpenShell mit Deinem Agenten Verwenden
OpenShell bietet vier portable Skills für Benutzer und Betreiber: CLI-Workflows (`openshell-cli`), Gateway-Fehlerbehebung (`debug-openshell-cluster`), Inferenz-Fehlerbehebung (`debug-inference`) und Richtliniengenerierung (`generate-sandbox-policy`). Installiere sie mit der Agent Skills CLI:```bash
npx skills add NVIDIA/OpenShell
Diese öffentlichen, installierbaren Skills befinden sich in skills/ und verwenden die installierte CLI-Hilfe und die veröffentlichte Dokumentation als ihre Quelle der Wahrheit. Sie erfordern keinen OpenShell-Quellcode-Checkout.
OpenShell wird mit denselben agentengesteuerten Workflows entwickelt, die es ermöglicht. Mitwirkenden- und Maintainer-Skills befinden sich separat in .agents/skills/; sie automatisieren die Arbeit am OpenShell-Repository und sind nicht enthalten, wenn Benutzer die öffentlichen Skills installieren:
create-spike; ein Mensch akzeptiert es mit state:accepted oder Roadmap-Platzierung oder lehnt es ab. Akzeptierte Arbeit kann in menschlicher Verantwortung bleiben oder in den optionalen, menschlich gesteuerten agent:*-Planungs- und Implementierungsworkflow übergehen.triage-issue bewertet. Agents stellen technische Validität und Auswirkung fest; Menschen entscheiden, ob das Projekt handeln sollte und wo die Arbeit auf der Roadmap einzuordnen ist.review-security-issue erstellt eine Schweregradbewertung und einen Behebungsplan. fix-security-issue setzt diesen um.sync-agent-infra, update-docs-from-commits und andere interne Workflows halten Code, Dokumentation und Agent-Infrastruktur konsistent.Die Agent-Implementierung ist menschlich gesteuert: Ein Benutzer kann eine Phase direkt anfordern, oder Maintainer können den optionalen agent:*-Workflow nutzen, um Planung und Implementierung einzureihen und zu genehmigen. Siehe AGENTS.md für die vollständige Dokumentation der Workflow-Kette.
npx skills add NVIDIA/OpenShellrfc verfolgt werdenOpenShell ist agent-first aufgebaut. Issues sollten eine User Story, Problembeschreibung, Auswirkung und Akzeptanzkriterien enthalten. Die Auswirkung sollte die Konsequenzen des aktuellen Verhaltens erläutern und warum bestehende Workarounds unzureichend sind. Feature-Anfragen erfordern zusätzlich einen vorgeschlagenen Entwurf auf Workflow-Ebene und Alternativen; Fehlerberichte ergänzen Reproduktionsschritte, Umgebungsdetails und relevante Logs. Sobald die Arbeit durch den Projekt-Workflow oder eine direkte Anfrage autorisiert ist, sollten Mitwirkende die Skills in .agents/skills/ verwenden, um den aktuellen Code und das Verhalten zu untersuchen, die Änderung zu implementieren und sie zu verifizieren. Wenn ein Issue frühere Diagnosen enthält, verifizieren Sie diese, anstatt sich auf sie zu verlassen. Siehe CONTRIBUTING.md für die vollständige Agent-Skills-Tabelle, den Beitrags-Workflow und das Entwicklungssetup.
OpenShell erfasst anonyme Telemetrie, um das Projekt für Entwickler zu verbessern. Diese Daten werden nicht verwendet, um individuelles Nutzerverhalten zu verfolgen. Sie helfen uns, die aggregierte Nutzung von Sandbox-, Provider- und Policy-Workflows zu verstehen, damit wir Produktverbesserungen priorisieren und Nutzungstrends mit der Community teilen können.
Deaktivieren Sie die Telemetrie zur Laufzeit, indem Sie OPENSHELL_TELEMETRY_ENABLED=false im Gateway-Deployment setzen. Bei Helm-Installationen setzen Sie server.telemetryEnabled=false. OpenShell propagiert diese Deployment-Einstellung in die Sandbox-Supervisor-Umgebungen, sodass auch die sandboxseitige Telemetrieerfassung deaktiviert wird.
Sie können Telemetrie auch vollständig herauskompilieren. Telemetrie-Unterstützung ist ein standardmäßig aktiviertes Cargo-Feature telemetry, und jedes Crate, das es enthält, definiert auch einen Alias defaults-without-telemetry, der alle anderen Standard-Features abdeckt. Erstellen Sie telemetriefreie Artefakte mit --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
Die resultierenden Binärdateien enthalten keinen Telemetrie-Endpunkt, keinen Telemetrie-HTTP-Client und keinen Emissionscode. Wenn die Telemetrie herauskompiliert wird, gibt das Gateway nichts aus und meldet den von ihm gestarteten Sandboxes, dass die Telemetrie deaktiviert ist. Cargo bietet keine Möglichkeit, ein einzelnes Standard-Feature abzuziehen, daher muss `defaults-without-telemetry` mit `--no-default-features` kombiniert werden; wenn es allein übergeben wird, bleiben die Standardeinstellungen bestehen und der Build schlägt fehl, anstatt eine Binärdatei zu erzeugen, die weiterhin emittiert.
Das Gateway stellt außerdem separate Cargo-Features für seine integrierten Compute-Treiber bereit: `compute-driver-kubernetes`, `compute-driver-docker`, `compute-driver-podman`, `compute-driver-vm` und `compute-driver-mxc`. Deaktivieren Sie den Standard-Featuresatz und aktivieren Sie dann nur die Treiber und den Telemetriemodus, die von der Ziel-Binärdatei benötigt werden. Zum Beispiel:```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
Reguläre Builds behalten ihren Plattform-Treibersatz durch das standardmäßige Kompatibilitätsmerkmal in-tree-compute-drivers bei. Unter Windows wählt compute-driver-mxc MXC aus; die anderen vier Merkmale installieren Stubs für nicht unterstützte Treiber. Auf anderen Plattformen ist MXC ausgeschlossen.
Telemetrie-Ereignisse sind auf anonyme operative Kategorien und Zählungen beschränkt, wie etwa Ergebnisse des Sandbox-Lebenszyklus, Buckets von Anbieterprofilen, Anzahlen von Richtlinienentscheidungen und aggregierte Kategorien von Netzwerkaktivitätsverweigerungen. Die OpenShell-Telemetrie erfasst keine Sandbox-Namen oder -IDs, Hostnamen, Dateipfade, Binärpfade, Prompts, Anmeldedaten, Anbieternamen, Modellnamen oder Benutzerinhalte.
Das Abmelden gilt nur für Telemetrie, die von OpenShell ausgegeben wird. Dienste Dritter, Modellanbieter, Inferenz-Endpunkte, Agenten oder Tools, die Sie konfigurieren und mit OpenShell verwenden, können eigene Bedingungen und Datenschutzpraktiken haben.
Wir veröffentlichen alle zwei Wochen aggregierte Nutzungstrends aus dieser Telemetrie. Die neueste Zusammenfassung finden Sie in den Community-Telemetrieberichten.
Diese Software ruft automatisch externe Materialien ab, greift darauf zu oder interagiert damit. Diese abgerufenen Materialien werden nicht mit dieser Software vertrieben und unterliegen ausschließlich separaten Bedingungen und Lizenzen. Sie sind allein dafür verantwortlich, alle geltenden Bedingungen und Lizenzen zu finden, zu prüfen und einzuhalten sowie die Sicherheit, Integrität und Eignung aller abgerufenen Materialien für Ihren spezifischen Anwendungsfall zu überprüfen. Diese Software wird „AS IS“ (wie besehen) bereitgestellt, ohne jegliche Gewährleistung. Der Autor gibt keine Zusicherungen oder Gewährleistungen in Bezug auf abgerufene Materialien und übernimmt keine Haftung für Verluste, Schäden, Verbindlichkeiten oder rechtliche Konsequenzen aus Ihrer Nutzung oder Unfähigkeit zur Nutzung dieser Software oder abgerufener Materialien. Nutzen Sie diese Software und die abgerufenen Materialien auf eigenes Risiko.
Dieses Projekt ist unter der Apache License 2.0 lizenziert.
| Kategorie | Tools |
|---|
| Agent | claude, opencode, codex, copilot |
| Sprache | python (3.14), node (22) |
| Entwickler | gh, git, vim, nano |
| Netzwerk | ping, dig, nslookup, nc, traceroute, netstat |
| Gateway | Control-Plane-API, die den Sandbox-Lebenszyklus koordiniert und als Authentifizierungsgrenze fungiert. |
| Sandbox | Isolierte Laufzeitumgebung mit Container-Überwachung und richtlinienkonformem Egress-Routing. |
| Policy Engine | Erzwingt Dateisystem-, Netzwerk- und Prozessbeschränkungen von der Anwendungsschicht bis zum Kernel. |
| Provider Access | Profildefinierte Endpunkte, Binary-Richtlinie und endpunktgebundene Anmeldedaten-Injektion für Modell-APIs und andere Dienste. |
| Schicht | Was geschützt wird | Wann sie gilt |
|---|
| Dateisystem | Verhindert Lese-/Schreibzugriffe außerhalb erlaubter Pfade. | Bei der Sandbox-Erstellung gesperrt. |
| Netzwerk | Blockiert unbefugte ausgehende Verbindungen. | Zur Laufzeit hot-reloadbar. |
| Prozess | Blockiert Privilegieneskalation und gefährliche Syscalls. | Bei der Sandbox-Erstellung gesperrt. |
| Provider | Gewährt endpunktgebundene Anmeldedaten und Netzwerkzugriff. | Zur Laufzeit hot-reloadbar. |