KI-Agenten mit NVIDIA OpenShell gezielt abschotten

Wie NVIDIA OpenShell den Zugriff von KI-Agenten begrenzt

OpenShell ist eine quelloffene Laufzeitumgebung: Sie führt einen Agenten aus und kontrolliert seine Zugriffsrechte. Dabei bildet sie die Schicht unter dem Agenten, ohne dessen Schlussfolgerungen oder Tools zu ersetzen.

Das Prinzip ähnelt einem Handwerker im Gebäude: Er erhält eine Werkstatt, Zugang zu bestimmten Räumen und die Erlaubnis, ausgewählte Lieferanten anzurufen. Den Generalschlüssel bekommt er nicht schon deshalb, weil im Auftrag „Vorsicht walten lassen“ steht. OpenShell schafft solche Grenzen für Softwareagenten.

Die Laufzeitübersicht beschreibt Einschränkungen für Dateisystem, Netzwerk und Prozesse sowie geschützte Zugangsdaten für Anbieter. Landlock ist der Mechanismus im Linux-Kernel, der Dateizugriffe begrenzt. seccomp schränkt Systemaufrufe ein, also die systemnahen Anfragen eines Programms an das Betriebssystem. Die Durchsetzung liegt außerhalb der Schlussfolgerungen des Agenten.

Das Gateway verwaltet Sandboxes und Zugriffe. Ein Supervisor außerhalb der Sandbox prüft ausgehende Anfragen anhand der Richtlinie und stellt Zugangsdaten bereit, soweit dies erlaubt ist. Der Policy Prover prüft modellierte Berechtigungen gegen definierte Grenzen. Diese Mechanismen bestimmen, was ein Agent tun darf. Sie garantieren nicht, dass seine erlaubte Arbeit korrekt ist.

NVIDIA nennt Einsatzmöglichkeiten für Claude Code, Codex, GitHub Copilot CLI, Hermes, LangChain Deep Agents, OpenClaw und OpenCode sowie für eigene Agenten und Images. „Unterstützt“ bedeutet allerdings nicht, dass jedes Tool vorinstalliert ist: Die aktuelle Standardumgebung ist ein minimales Ubuntu-Image ohne Agenten-CLIs, also ohne die Kommandozeilenprogramme zum Starten der Agenten.

Für den Betrieb entscheidend ist, dass sich Berechtigungen wiederverwenden lassen. Ohne wiederverwendbare Grenzen muss bei jedem neuen Agentenworkflow erneut geklärt werden, welche Dateien, Geheimnisse und Dienste zugänglich sein sollen. Mit OpenShell kann das Team diese Entscheidungen mit der Arbeitsumgebung bündeln und Änderungen prüfen. Als Maßstab eignen sich die Arbeitsstunden für die Einrichtung der Zugriffe und für Unterbrechungen; eine verifizierte, allgemein gültige Zeitersparnis gibt es nicht.

Auf welchen Systemen läuft OpenShell derzeit?

Für die Wahl des Hosts ist die aktuelle Supportmatrix maßgeblich. Diese Anleitung folgt der Dokumentation mit der Kennzeichnung v0.1.7, geprüft am 8. November 2026.

WSL 2 führt eine Linux-Umgebung unter Windows aus. MXC ist ein davon getrennter, nativer Windows-Ansatz zur Isolation. „Windows-Unterstützung“ bezeichnet hier also keine einheitliche, beliebig austauschbare Installationsvariante.

Die Ankündigung zur Windows-Zusammenarbeit beschreibt, wie OpenShell über MXC auf Windows kommen soll. Diese Plattformstrategie macht die native Variante heute noch nicht zu einer regulären, stabilen Installation. Die aktuelle Installationsdokumentation weist ausdrücklich darauf hin, dass die üblichen Veröffentlichungskanäle keine nativen Windows-Binärdateien bereitstellen.

Für eine erste Erprobung empfiehlt sich eine unterstützte Linux- oder Apple-Silicon-Konfiguration. Die Supportmatrix nennt außerdem Anforderungen an Kernel und Laufzeitumgebung: Linux 6.2 führte die benötigte Landlock-ABI ein, doch die Kernelversion allein reicht nicht. Die Laufzeitumgebung muss die vorgeschriebenen Prüfungen bestehen. Bei macOS mit Docker Desktop laufen diese Linux-Funktionen in dessen virtueller Linux-Maschine. NVIDIA Vera CPUs sind nicht erforderlich.

CLI installieren und den ersten Agenten starten

Als Einstieg eignet sich NVIDIAs dokumentiertes OpenCode-Beispiel. Es macht die drei Bestandteile sichtbar: einen Provider für den Dienstzugang, ein Image mit dem Agenten und eine Sandbox für dessen Ausführung. Die folgenden Schritte beruhen auf der Dokumentation; sie wurden für diesen Artikel nicht lokal getestet.

1. Host vorbereiten und OpenShell installieren. Für die Docker-Variante muss Docker Desktop laufen oder Docker Engine 28.0 oder neuer vorhanden sein. Auf unterstützten Linux- oder macOS-Systemen verwendet die Installationsanleitung den Befehl curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh. Das Installationsskript sollte vor der Ausführung geprüft werden. Es installiert die CLI, den Policy Prover und das lokale Gateway. Mit openshell status lässt sich prüfen, ob die CLI das Gateway erreicht.

2. Modelldienst konfigurieren. Das Beispiel nutzt OpenRouter. Vor dem Anlegen des Providers muss OPENROUTER_API_KEY in der Hostumgebung gesetzt sein. Ein Providerprofil beschreibt erlaubte Dienstendpunkte und Programmpfade; der Provider speichert die Zugangsdaten. NVIDIAs Beispielprofil erlaubt /usr/local/bin/opencode den Zugriff auf openrouter.ai.

3. Profil importieren, Provider anlegen und Image starten. Die folgenden Befehle werden auf dem Host in dieser Reihenfolge ausgeführt:

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

Das Image stellt OpenCode bereit; der Befehl nach -- startet es als Hauptprozess. Die Anleitung für den ersten Agenten verwendet dieses kostenlose Modell ohne erforderliches OpenRouter-Guthaben. Das ist die Modellwahl dieses Beispiels und kein Versprechen, dass jede beliebige Modellnutzung kostenlos wäre.

4. Zugriffsanfragen vom Host aus prüfen. Versucht ein Agent, ein nicht freigegebenes Ziel zu erreichen, verweigert OpenShell den Zugriff und entwirft einen eng begrenzten Regelvorschlag. Mit openshell rule get my-agent --status pending lassen sich diese Vorschläge abrufen. Entspricht ein Vorschlag dem vorgesehenen Zugriff für die Aufgabe, kann genau dieser mit openshell rule approve my-agent --chunk-id <chunk-id> freigegeben werden; der Platzhalter wird durch die tatsächliche ID ersetzt. Die Regel wird neu geladen, und der Agent kann es erneut versuchen.

5. Tatsächlich erteilte Berechtigungen kontrollieren. Zunächst openshell policy get my-agent --base, dann openshell policy get my-agent --full ausführen. Der erste Befehl zeigt die Basisrichtlinie, der zweite schließt die von Providern beigesteuerten Regeln ein. Vor dem Hinzufügen eines echten Projekts oder eines sensiblen Dienstes sollten die wirksamen Berechtigungen geprüft werden.

Nach einer vorübergehenden Erprobung lässt sich die Sandbox mit openshell sandbox delete my-agent löschen.

Welche Richtlinien lassen sich im laufenden Betrieb ändern?

Netzwerkzugriffe können während einer Aufgabe angepasst werden. Änderungen an Dateisystem- und Prozessgrenzen erfordern dagegen eine neu angelegte Sandbox.

Auch Änderungen im laufenden Betrieb haben Folgen. Neue Netzwerkregeln schließen Verbindungen, die unter den vorherigen Regeln geöffnet wurden; Clients müssen sich daher erneut verbinden. Ein neuer externer Middleware-Dienst erfordert eine Gatewaykonfiguration und einen Neustart des Gateways. Ein zusätzlicher Dateisystempfad in der gespeicherten Richtlinie gewährt der bereits laufenden Arbeitsumgebung keinen Zugriff darauf. Das Entfernen von Pfaden oder Änderungen an Starteinstellungen werden nach dem Start abgewiesen. Der Leitfaden zur Richtlinienverwaltung erläutert diese Unterschiede.

Ein weiterer Stolperstein: Keine Richtliniendatei bedeutet nicht, dass kein Zugriff besteht. Eine Richtlinie kann aus dem Image, einer Umgebungseinstellung oder einer gatewayweiten Vorgabe stammen. Zugeordnete Provider können Netzwerkregeln ergänzen. Die Regeln zur Richtlinienauswahl stellen zudem klar: Eine globale Richtlinie ersetzt die eigene Richtlinie der Sandbox. Sie ist keine bloße zusätzliche Einschränkungsebene.

Eine nachvollziehbare Richtlinie für Coding-Agenten

Ein Agent zur Fehlerbehebung sollte zunächst ein beschreibbares Projektverzeichnis und ausschließlich lesenden API-Zugriff erhalten, bevor er Änderungen veröffentlichen darf.

Die folgende Beispielrichtlinie gilt für ein vorbereitetes Coding-Image, in dem das Projekt unter /workspace liegt und curl unter /usr/bin/curl installiert ist. Sie wird als policy.yaml gespeichert und beim Anlegen einer neuen Sandbox mit --policy ./policy.yaml übergeben. Die Vorlage ist auf diesen Image-Aufbau zugeschnitten und lässt sich nicht unverändert auf jedes Agenten-Image übertragen:

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

Der Agent kann Projektdateien und temporäre Dateien bearbeiten. Die Netzwerkregel erlaubt dem genannten Programm GET-, HEAD- und OPTIONS-Anfragen an die GitHub-API. Sie gewährt weder beliebigen Programmen Internetzugriff noch erlaubt sie Paketdownloads oder Git-Push-Zugriffe. Der Modellprovider wird separat konfiguriert.

Beschreibbare Verzeichnisse, die das Image für den Agentenzustand benötigt, müssen vorbereitet und gezielt ergänzt werden. Diese Pfade beziehen sich auf das Dateisystem der Sandbox. Ein ähnlich benanntes Verzeichnis auf dem Host steht dadurch nicht automatisch zur Verfügung. Außerdem werden für netzwerkfähige Arbeitsumgebungen grundlegende Dateisystempfade ergänzt. Das kurze YAML-Beispiel bedeutet daher nicht, dass die wirksame Zugriffsgrenze ausschließlich die dort aufgeführten Pfade umfasst.

Zwei Einstellungen verdienen besondere Beachtung. hard_requirement verhindert den Start, wenn die benutzerdefinierten Dateisystemregeln nicht durchgesetzt werden können. Einzelne fehlende oder unzugängliche Pfade können dennoch übersprungen werden. enforcement: enforce blockiert unzulässige Anfragen, die der Prüfung unterliegen. Der im Schema voreingestellte Modus audit protokolliert Verstöße und lässt diese Anfragen zu. Vor einer Anpassung der Vorlage empfiehlt sich die Referenz zum Richtlinienschema.

Getestet werden müssen sowohl erlaubte als auch verweigerte Zugriffe. NVIDIAs Tutorial für Netzwerkrichtlinien prüft, ob curl -s https://api.github.com/zen unter der Nur-Lese-Regel erfolgreich ist, und anschließend, ob ein POST abgewiesen wird. Die Protokolle lassen sich vom Host mit openshell logs my-agent --since 5m --source sandbox prüfen. Für das eigene Projekt gehören außerdem ein beabsichtigter Schreibzugriff und ein Dateizugriff außerhalb des erlaubten Bereichs zum Test. Ein erfolgreich gestarteter Agent ist noch kein Abnahmetest für eine Sicherheitsrichtlinie.

Fünf Arbeitsabläufe für den Einstieg

Für den Anfang eignen sich Aufgaben mit klaren Grenzen, deren Ergebnis ein Mensch beurteilen kann. Nach dem zu erwartenden betrieblichen Nutzen geordnet:

Keiner dieser Abläufe garantiert korrekten generierten Code oder eine verlässliche Störungsdiagnose. Der Nutzen liegt darin, die möglichen Aktionen während der Agentenarbeit zu begrenzen. Eine breitere Werkzeugauswahl bietet Die besten Tools für KI-Sandbox-Sicherheit 2026; bei der Wahl einer Ausführungsplattform hilft Die besten Code-Sandboxes für KI-Agenten 2026.

Zwei Produktideen rund um OpenShell

Die stärkste Chance bietet ein Einführungspaket für Coding-Agenten im Team. Zielkunde ist eine Plattformleitung, die Entwicklern produktives Arbeiten in einer freigegebenen Umgebung ermöglichen möchte. DataForSEO schätzt 1,300 monatliche Suchanfragen nach „claude code sandbox“ in dem Markt, den die Abfrage dieses Laufs zurückgegeben hat. Das belegt Interesse an der Einrichtung, nicht 1,300 potenzielle Kunden. Zudem suchen manche nach der Sandbox des Agenten selbst und nicht nach OpenShell.

Die kleinste verkaufbare Version könnte einen Agenten und eine freigegebene Hostkonfiguration unterstützen: mit einem vorbereiteten Image, einer geprüften Richtlinie, einer Checkliste zur Providereinrichtung und wiederholbaren Tests für erlaubte und verweigerte Zugriffe. Verkauft wird eine funktionierende Einführung im Team mit klarer Zuständigkeit für Aktualisierungen. Die Schwierigkeit ist die Wartung: Image-Pfade, Agentenverhalten und experimentelle Schnittstellen können sich ändern. Vor dem Aufbau eines gehosteten Produkts sollten Gespräche mit Plattformverantwortlichen klären, wie schwer diese Wartungslast wiegt.

Eine Arbeitsumgebung zur Richtlinienprüfung ist die zweite Chance. Sicherheitsteams könnten damit erkennen, was eine wirksame Richtlinie erlaubt, Änderungen vergleichen und Freigaben dokumentieren. DataForSEO schätzt 480 monatliche Suchanfragen nach „ai agent security“ und 70 nach „ai agent security tools“. Diese getrennten Abfragen sind breite Nachfragesignale; sie dürfen nicht zu einer Zahl eindeutiger Käufer addiert werden.

Ein MVP könnte Basisrichtlinien und wirksame Richtlinien importieren, neu hinzugefügte Ziele und Anfrageberechtigungen hervorheben und Testergebnisse einem Prüfprotokoll zuordnen. Die Schwierigkeit liegt in der Abgrenzung: OpenShell bietet bereits Richtlinienanalyse, Vorschläge und Protokolle. Das Produkt muss den Prüfprozess des Teams verbessern, statt lediglich bestehende Befehle in ein Dashboard zu verpacken. Das Einführungspaket ist der bessere Anfang, weil sich Käufer und Lieferumfang leichter bestimmen lassen.

Welche Probleme löst OpenShell nicht?

OpenShell begrenzt Zugriffe. Ob eine erlaubte Aktion geschäftlich sinnvoll ist, entscheidet es nicht. Ein Agent mit Schreibzugriff auf Projektdateien kann weiterhin einen fehlerhaften Patch schreiben. Ein freigegebenes externes Ziel kann weiterhin Daten empfangen, deren Übertragung die Richtlinie erlaubt. Dateizugriffe und Endpunktfreigaben müssen deshalb dem entsprechen, was tatsächlich zugänglich sein soll.

OpenShell ersetzt auch keine Identitätssysteme, Geheimnisspeicher, Überwachung oder Governance. NVIDIAs Ankündigung zu Laufzeitkontrollen verortet die Durchsetzung außerhalb der Arbeitsumgebung des Agenten. Das ist ein Baustein des Gesamtsystems und kein Grund, die übrigen Bausteine aufzugeben.

Das Projekt bietet inzwischen stabile Versionen, die innerhalb der Supportmatrix für den Produktivbetrieb vorgesehen sind. OpenShell pauschal als experimentelle Demo zu bezeichnen, wäre daher irreführend. Die Einschränkungen sind konkreter: Experimentelle Schnittstellen können sich in Patchversionen ändern, natives Windows befindet sich weiterhin in Entwicklung, und laut NVIDIA deckt das aktuelle Qualifizierungsprofil nicht die gesamte Richtlinie zur Releasequalifizierung ab. Für den Betrieb sollten Versionen festgeschrieben und die konkrete Kombination aus Arbeitsumgebung und Host validiert werden.

Der Schritt für Montag: Die Plattformleitung wählt ein Repository ohne sensible Inhalte und einen Agenten aus. Es folgen die Installation auf einem unterstützten Host, die Vorbereitung des Images und die Festlegung der Datei- und Netzwerkzugriffe. Anschließend werden eine erlaubte und eine blockierte Operation getestet. In der ersten Woche werden Einrichtungszeit und die Arbeitsstunden erfasst, die durch Unterbrechungen entstehen. Der Einsatz wird erst erweitert, wenn das Team jede erteilte Berechtigung erklären kann.

Für die Einbindung in bestehende Teamabläufe helfen wir dabei, die nötigen Kontrollen für den Produktivbetrieb einzurichten.