NVIDIA OpenShell 0.1.0 bringt Laufzeitkontrollen für KI-Agenten, ohne dass sie neu geschrieben werden müssen

Warum der Zugriff von Agenten durchgesetzt werden muss

NVIDIA beschreibt Agenten als Systeme, denen man ein Ziel vorgeben kann, die Code schreiben, Werkzeuge nutzen und weiterarbeiten, sobald neue Informationen vorliegen. Das ermöglicht Anwendungen, die Softwarefehler untersuchen, Experimente durchführen und geschäftskritische Aktionen sowie Recherchen über Tage oder Wochen erledigen.

Nützliche Agenten brauchen Zugang zu Arbeitsumgebungen, Rechenressourcen, Daten, Zugangsdaten und externen Diensten. Laut NVIDIA schafft ein breiterer Zugriff aber auch folgenreichere Fehlermöglichkeiten, vom Verändern von Produktivdaten über die Preisgabe vertraulicher Informationen bis hin zu Handlungen jenseits der zugewiesenen Aufgabe. OpenShell soll es Teams ermöglichen, genau die Fähigkeiten freizugeben, die eine Aufgabe erfordert, während die Berechtigungen außerhalb der Agenten-Workload durchgesetzt werden.

NVIDIA zufolge unterstützt OpenShell Codex, Claude Code, Pi, Hermes und künftige Frameworks. Es bildet die Laufzeitschicht der umfassenderen NVIDIA Open Agent Safety Platform, die den Schutz auf die Ebenen Anwendung, Laufzeit und Infrastruktur ausweitet.

So ist OpenShell aufgebaut

Die Kontrolle übernehmen drei Komponenten. Das OpenShell Gateway verwaltet die Lebenszyklen und Richtlinien vieler Sandboxes. Der OpenShell Supervisor ist jeder Sandbox zugeordnet, läuft außerhalb der Agenten-Workload und prüft ausgehende Anfragen anhand der Richtlinie. Die OpenShell Sandbox führt die Workload mit Kontrollen auf Kernel-Ebene für Dateisystem und Prozesse aus und hat keinen Netzwerkpfad außer über den Supervisor.

Die Sandbox nutzt Kontrollmechanismen des Betriebssystemkerns, um zu begrenzen, welche Dateien eine Workload lesen oder ändern darf, und um zu verhindern, dass sie zusätzliche Systemrechte erlangt. Beim Netzwerkzugriff kann der Supervisor konfigurierten Datenverkehr über HTTP, GraphQL und das Model Context Protocol (MCP) inspizieren. So kann etwa eine Datenabfrage passieren, während ein Schreibzugriff über dieselbe API blockiert wird.

Laut NVIDIA bleiben diese Kontrollen bestehen, wenn der Agent eine Shell startet, generierten Code ausführt, Kindprozesse anstößt oder die Delegation von Aufgaben an Sub-Agenten vorschlägt. Richtlinienentscheidungen werden in einem Audit-Protokoll im Open Cybersecurity Schema Framework (OCSF) festgehalten. Wird eine Anfrage blockiert, kann OpenShell eine aussagekräftige Fehlermeldung zurückgeben, die dem Agenten hilft zu entscheiden, wie er weiter vorgeht.

• Unterstützung mandantenfähiger Plattformen mit getrennten Arbeitsbereichen, Berechtigungen und Dienstzugriffen auf gemeinsam genutzter Infrastruktur.
• Formale Richtlinienverifikation, die menschlichen und KI-Prüfern zeigt, ob angeforderte Berechtigungen innerhalb definierter Sicherheitsgrenzen bleiben.
• Erweiterbare Sicherheit und Governance, die Sicherheitsdienste von Drittanbietern, Governance-Systeme und eigene Prüfungen anbindet.
• Dienstzugriff mit geschützten Zugangsdaten: Die echten Credentials bleiben außerhalb der Agenten-Workload und werden an autorisierte Anfragen gebunden.
• Ausführung auf CPU und GPU in Containern, VMs und Kubernetes-Umgebungen.

Richtlinien-Demo mit der GitHub-API

NVIDIA führt ein Beispiel mit curl und einem nicht authentifizierten Endpunkt der GitHub REST API vor, sodass weder ein API-Schlüssel noch ein Sprachmodell nötig ist. Zunächst wird eine Sandbox mit einer Richtlinie ohne Netzwerkzugang erstellt, und eine Anfrage an den öffentlichen Endpunkt schlägt fehl. Logs auf dem Host zeigen, welches Programm die Anfrage gestellt hat und warum sie blockiert wurde.

Anschließend wird die Sandbox-Richtlinie ohne Neustart der Sandbox durch eine ersetzt, die schreibgeschützten Zugriff auf die GitHub REST API erlaubt. Richtlinien werden in YAML verfasst und zu OPA/Rego kompiliert, das OpenShell für jede ausgehende Anfrage auswertet. Mit der Protokolleinstellung rest inspiziert OpenShell HTTP-Anfragen, erlaubt Lesezugriffe und blockiert Schreibzugriffe. Eine GET-Anfrage gelingt, eine POST-Anfrage wird blockiert, und laut NVIDIA würde ein Agent, der dieselben Befehle ausführt, auf dieselben Einschränkungen stoßen.

Bei den Zugangsdaten autorisiert OpenShell nach Angaben von NVIDIA den Zugriff auf Modell-APIs oder private Dienste, während die echten Credentials außerhalb der Agenten-Workload bleiben. Das echte Credential wird außerhalb der Workload und nur für einen autorisierten Endpunkt eingesetzt. Sowohl der Netzwerkzugriff als auch die Credential-Bindung müssen die Anfrage erlauben, und die Autorisierung für einen Dienst macht das Credential nicht für einen anderen verfügbar.

Einsatz in der Praxis und Bedeutung

NVIDIA nennt drei Anwender. Cadence nutzt OpenShell für das Chipdesign mit dem ChipStack Autonomous RTL Design Engineer. Slack baut auf OpenShell eine On-Demand-Agentenplattform zur Automatisierung von Aufgaben auf. Gecko Robotics setzt es ein, um Agenten zu steuern, die Entscheidungen auf physischen Robotern treffen.

NVIDIA erklärt zudem, der Policy Prover nutze formale Logik, um zu verifizieren, dass modellierte Berechtigungen innerhalb definierter Grenzen bleiben, und um Aktionen zu identifizieren, die diese überschreiten. Teams können lokal mit einer Sandbox entwickeln und anschließend in gemeinsam genutzter Infrastruktur bereitstellen, mit Arbeitsbereichen, Compute-Treibern für Docker und Kubernetes sowie vertrauenswürdiger Middleware für Identitätsdienste.

Für Teams, die langlebige Agenten betreiben, liegt das Versprechen darin, API-Operationen einzuschränken, Zugangsdaten zu schützen und Berechtigungsänderungen zu prüfen, ohne den Agenten selbst zu verändern. NVIDIA verweist Entwickler auf eine Schnellstartanleitung, das GitHub-Repository und den Kanal #openshell-dev im CNCF-Slack.