Ein Container ist ein Raum – kein Berechtigungssystem
KI-Agenten stellen ein erhebliches neues Risiko dar: Entwickler gewähren Tools wie Claude Code oder Codex routinemäßig umfassenden Zugriff auf sensible Repositories, APIs und Anmeldedaten und lassen sie dann unbeaufsichtigt laufen. Dieser Komfort geht oft zu Lasten der Sicherheit, da der Nutzen eines Agenten direkt mit seinem Zugriff auf kritische Ressourcen verknüpft ist.
Gewöhnliche Container sind zwar effektiv bei der Host-Isolierung, können aber nicht zwischen nuancierten Aktionen unterscheiden. Eine GitHub-Verbindung erlaubt beispielsweise sowohl das Lesen von Daten als auch das Vornehmen destruktiver Änderungen. Der Container sieht nur den Datenverkehr an dieselbe Adresse und kann nicht unterscheiden, ob ein Agent lediglich Code durchsucht oder aktiv Issues öffnet.
NVIDIA OpenShell, eine neue Open-Source-Sandbox, adressiert diese Lücke. Geschrieben in Rust und lizenziert unter Apache 2.0, kontrolliert OpenShell, was ein Agent mit seinem Zugriff tun kann, nicht nur, ob er eine Ressource erreichen kann. Entscheidend ist, dass es keine NVIDIA GPU benötigt und auf Standard-Hardware läuft.
Das Policy-First-Design von OpenShell erzwingt eine granulare Kontrolle über Dateizugriffe, Systemaufrufe und Netzwerkverbindungen. Es arbeitet mit einer Default-Deny-Haltung, was bedeutet, dass Agenten nichts tun können, bis dies explizit erlaubt wurde. Diese fein abgestimmte Durchsetzung ist ein bedeutender Sprung über die grundlegende Containerisierung hinaus.
Der Türsteher prüft jeden Ausgang
OpenShell bildet drei Kernkomponenten ab: Das Gateway fungiert als Schnittstelle und Steuerungsebene; der Supervisor erzwingt Richtlinien und vermittelt Anmeldedaten; und die Sandbox bietet die eingeschränkte Umgebung, in der der Agent ausgeführt wird. Der einzige Ausgangspfad der Sandbox führt über den Supervisor, wodurch sichergestellt wird, dass alle externen Interaktionen vermittelt werden.
Das Default-Deny-Verhalten ist zentral für das Sicherheitsmodell von OpenShell. Dateisystem- und Prozessbeschränkungen auf Kernelebene blockieren von Anfang an unbefugte Pfade und Privilegieneskalationen. Jede Netzwerkanfrage des Agenten muss den Supervisor passieren, der sie anhand vordefinierter Richtlinien prüft.
Stellen Sie sich eine Richtlinie vor, die es der curl-Binary erlaubt, schreibgeschützte Anfragen an die GitHub API zu stellen. Der Supervisor erlaubt dies. Wenn jedoch dieselbe curl-Binary versucht, eine nicht genehmigte POST-Anfrage zum Erstellen eines Issues zu senden, verweigert der Supervisor dies. Diese Richtlinien werden live über openshell policy update aktualisiert, ohne die Sandbox neu zu starten, und jede Verweigerung wird protokolliert, was einen klaren Audit-Trail bietet.
Entscheidend ist, dass der Agent niemals direkt mit Anmeldedaten umgeht. Der Supervisor injiziert Token nur für genehmigte Anfragen, was eine Exfiltration durch Prompt Injection verhindert. Selbst die DNS-Auflösung erfolgt über den Supervisor, was die Sichtbarkeit und Kontrolle des Agenten einschränkt. Dieses Design stellt sicher, dass selbst bei einer Kompromittierung des Agenten keine Schlüssel gestohlen werden können.
Der clevere Teil: Ihr Agent besitzt niemals den Schlüssel
Das genialste Feature von OpenShell ist das Credential Masking: Der Agent hält niemals direkt sensible API-Schlüssel oder Token. Stattdessen behält der Supervisor diese Geheimnisse und injiziert sie nur in genehmigte ausgehende Anfragen, die mit der festgelegten Richtlinie übereinstimmen. Dieses Design reduziert die Angriffsfläche für Prompt Injection erheblich, da es keine Anmeldedaten gibt, die der Agent preisgeben könnte.
Bevor Richtlinienänderungen live gehen, verwendet OpenShell einen Z3 Solver als formalen Verifizierer. Diese mathematische Engine bewertet vorgeschlagene Richtlinienänderungen und berechnet den vollen Umfang des neu gewährten Zugriffs. Diese proaktive Prüfung hilft dabei, riskante Regeln aufzudecken, wie z. B. unbeabsichtigte Platzhalter oder zu weitreichende Berechtigungen, und verhindert deren Implementierung.
Während Alternativen existieren – Docker bietet grundlegende Isolierung, die Sandbox-Runtime von Anthropic bietet ein schlankeres Setup und gehostete Lösungen wie E2B oder Daytona bieten verwaltete Ausführung – besetzt OpenShell eine eigene Nische. Es legt den Schwerpunkt auf selbst gehostete, richtlinienbasierte Agentensteuerung, die auf Container-Runtimes wie Docker, Podman oder Kubernetes läuft. Für diejenigen, die sich für die zugrunde liegende Architektur und Open-Source-Beiträge interessieren, ist das Projekt unter NVIDIA/OpenShell auf GitHub verfügbar.
OpenShell stellt einen Wandel dar, weg von der einfachen Frage „Kann der Agent darauf zugreifen?“ hin zu „Was darf der Agent damit tun?“. Die Telemetrieberichte von NVIDIA zeigen, dass OpenShell in zwei Wochen diesen Sommer über 550.000 Sandboxes erstellt und 4,2 Millionen Agenten-Aktionen blockiert hat, was seine aktive Rolle bei der Durchsetzung von Agenten-Grenzen unterstreicht.
Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.
eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte
Nützliche Leitplanken, kein Sicherheitskraftfeld
OpenShell bietet nützliche Leitplanken, kein Sicherheitskraftfeld. Sein frühes Stadium ist offensichtlich: Trotz des großen Interesses aus dem Ökosystem von Cisco, CrowdStrike, Google Cloud und Microsoft Security befindet sich das Projekt in Version 0.1.5 und ist als „Early Preview“ gekennzeichnet. Telemetrie ist standardmäßig aktiviert und zählt Ereignisse anonym, kann jedoch über eine Umgebungsvariable deaktiviert werden.
Mac-Benutzer sollten beachten, dass OpenShell-Sandboxes Linux-basiert sind und innerhalb der virtuellen Maschine von Docker Desktop laufen. Dies erfordert Kernel-Funktionen wie Landlock und aktivierte Host-Netzwerke, was standardmäßig oft deaktiviert ist. Der eigene doctor-Befehl von NVIDIA meldet möglicherweise einen grünen Status, dennoch wird ein Test empfohlen.
Die interne Telemetrie von NVIDIA berichtet von einer erstaunlichen Aktivität: über 550.000 Sandbox-Erstellungen und 4,2 Millionen blockierte Agenten-Aktionen innerhalb eines Zeitraums von zwei Wochen. Diese Zahlen verdeutlichen das Ausmaß der Agenten-Überschreitungen, die OpenShell abfängt. NVIDIA berichtete jedoch auch, dass im selben Zeitraum etwa 12 % der Sandbox-Erstellungen fehlschlugen; dies sind unternehmenseigene Telemetriedaten, keine unabhängige Prüfung.
Für einfacheres lokales Programmieren mit Tools wie Claude Code könnten ein einfacher Container oder die Anthropic Sandbox Runtime mit weniger Einrichtungsaufwand ausreichen. Aber für Agenten, die mit echten Anmeldedaten arbeiten oder lang laufende, unbeaufsichtigte Aufgaben ausführen, sind die pro-Anfrage-Regeln und die Maskierung von Anmeldedaten von OpenShell von unschätzbarem Wert. Ein sorgfältiges Richtliniendesign bleibt entscheidend, da Sandboxing Risiken mindert, aber nicht alle potenziellen Schwachstellen eliminieren kann.
Häufig gestellte Fragen
Was ist NVIDIA OpenShell?
OpenShell ist eine Open-Source-Runtime zur Einschränkung des Datei-, Prozess- und Netzwerkzugriffs von KI-Agenten durch Richtlinien, die außerhalb des Agenten durchgesetzt werden.
Benötigt OpenShell eine NVIDIA GPU?
Nein. Das Video zeigt, wie es auf einem Mac läuft; OpenShell ist nicht von NVIDIA GPU-Hardware abhängig.
Wie unterscheidet sich OpenShell von Docker?
Docker isoliert einen Container, während OpenShell fein abgestufte Kontrollen hinzufügt, einschließlich Regeln dafür, welcher Prozess auf bestimmte Netzwerk-Endpunkte und Operationen zugreifen darf.
Verhindert OpenShell jedes Sicherheitsrisiko durch KI-Agenten?
Nein. Es begrenzt, worauf ein Agent zugreifen kann, ist aber keine vollständige Sicherheitsgarantie; Konfiguration, Isolationsgrenzen und Software-Reife spielen weiterhin eine wichtige Rolle.