Ein erfolgreicher Injection-Angriff bedeutet Preisgabe aller Anmeldeinformationen
APTI-Keys in Umgebungsvariablen zu speichern, war über zwei Jahrzehnte der Standard in der Serverentwicklung. Am 28. September 2026 veröffentlicht NVIDIA die Open Agent Safety Platform und macht diesen Standard zur Tabu-Zone im Agenten-Zeitalter. Die Plattform besteht aus zwei Komponenten: der Open-Source-Software OpenShell (Apache 2.0, GitHub-Repository NVIDIA/OpenShell) und dem Referenzsystem Sentry, das auf BlueField-4 DPUs (Data Processing Units) läuft und als out-of-band Watchdog die Agenten auf der Haupt-CPU überwacht. Laut Herstellerangaben kann es unkontrollierte Agenten in Millisekunden isolieren.
Repository-Status: Implementierung in Rust, mit Modulen wie core, supervisor, credential-gateway, policy-engine und egress-gateway unter crates; 18.2k Stars, 1.852 Commits; stabile Version 0.1.x mit etwa einer Version alle drei Wochen. Die hohe Commit-Dichte kombiniert mit dem Rhythmus von drei Wochen pro Version deuten auf eine schnelle Entwicklung hin – Produktionsanwender sollten für Interface-Änderungen entsprechende Ressourcen einplanen.
Das Design-Prinzip von OpenShell lässt sich auf einen Satz reduzieren: Agentenverhalten ist unvorhersehbar, also schränkt man deren Zugriffsbereich ein und verlagert die Autorisierungsprüfung aus dem Modellkontext in den Kernel. Der Wettbewerb im Agenten-Runtime-Bereich verschiebt sich damit – von “Wie diszipliniert ist das Modell?” hin zu “Wie weit kann eine Überschreitung von Rechten gehen?”.
Anmeldeinformationen in den Gateway, nicht in den Kontext
Die tägliche Arbeit von autonomen Agenten umfasst das Ausführen von Shell-Befehlen, das Schreiben von Dateien und das Senden von Netzwerkanfragen. Anmeldeinformationen befinden sich typischerweise in Umgebungsvariablen, Konfigurationsdateien oder .env-Dateien. Ein erfolgreicher Prompt-Injection-Angriff oder auch nur eine Fehlentscheidung des Modells kann dazu führen, dass der Agent mit allen Anmeldeinformationen handelt. Die Explosionsradius entspricht dem ihm zugewiesenen Berechtigungsset – die Reduzierung der Berechtigungen reduziert den Explosionsradius. Dies ist der Ausgangspunkt des gesamten OpenShell-Designs.
Prompt-basierte Barrieren haben bei feindlichen Eingaben keine erzwungene Gültigkeit. System-Prompt-Einschränkungen hängen von der Kooperationsbereitschaft des Modells ab – Angreifer müssen es nur dazu bringen, seine Meinung zu ändern. Kernel-level-Berechtigungsgrenzen ignorieren die Meinungen des Modells und lehnen Systemaufrufe direkt ab. Der Unterschied zwischen Barrieren und Grenzen liegt im Durchsetzungsmechanismus: der eine beruht auf der Kooperationsbereitschaft des Modells, der andere auf dem Kernel.
Abbildung: Screenshot der OpenShell-Befehlszeilenschnittstelle – Agenten-Aktionen werden erst nach erfolgreicher Prüfung durch die Policy ausgeführt. Quelle: OpenShell-Repository-Dokumentation
Kernel-level-Policy-Durchsetzung ist der erste Schlüsselmechanismus. Policies wirken auf Kernel-Ebene, unabhängig von Laufzeitbibliotheken oder Containerkonfigurationen. Jede Aktion des Agenten innerhalb der Grenzen muss eine Policy-Prüfung durchlaufen. Container lösen das Problem der Prozessisolierung und Image-Distribution, OpenShell beantwortet eine andere Frage: Wird jeder Zugriff des Agenten auf Anmeldeinformationen, Dateien und Netzwerke während der Laufzeit autorisiert?
Der Anmeldeinformations-Gateway ist der zweite Schlüsselmechanismus. APTI-Keys und Tokens werden dem Anmeldeinformations-Gateway (credential gateway) zur Verwahrung übergeben und bei ausgehenden Anfragen injiziert. Die Anmeldeinformationen gelangen niemals in den Kontext des Agenten oder auf sein Dateisystem. Im Vergleich zur herkömmlichen Methode “Keys in .env” wird die Angriffsfläche von der gesamten Maschine auf eine Gateway-Komponente reduziert. Das Modell kann getäuscht werden, aber ein getäuschtes Modell hat keinen Zugriff auf die Schlüssel.
Auch ausgehender Verkehr wird kontrolliert: Der Egress-Gateway lässt nur Ziele auf der Whitelist zu, alles andere ist unerreichbar. Dateisystem und Netzwerkziele zeigen nur die Verzeichnisse und Adressen, die der Agent sehen sollte.
Abbildung: OpenShell-Architektur – Agent, Supervisor, Anmeldeinformations-Gateway, Policy-Engine und Egress-Gateway sind eigenständige Module. Anmeldeinformationen und Policy-Entscheidungen erfolgen außerhalb des Agenten-Kontexts. Quelle: OpenShell-Repository-Dokumentation
Policy-Änderungen müssen formale Verifizierung durchlaufen, bevor sie in Kraft treten
Ein fehlerhafter Policy-Eintrag entspricht einem Loch in der Sicherheit. OpenShell blockiert Policy-Änderungen hinter der formalen Verifizierung: Neue Policies müssen vor ihrer Aktivierung eine formale Verifizierung durchlaufen, um sicherzustellen, dass die Semantik der Erwartung entspricht. Ähnliche Sandbox-Tools bieten diesen Schritt selten – die meisten Lösungen bleiben im Zustand “Policy als Code, Änderung sofort wirksam”.
Die Supervisor-Komponente verwaltet die Erstellung, Überwachung und Beendigung von Agenten und bildet die Lebenszyklusverwaltung. Das SDK unterstützt Python, TypeScript, Go und Rust, Kubernetes-Deployment erfolgt über Helm, der Integrationsweg ist vollständig.
Die formale Verifizierung hat ihre Grenzen: Sie bekämpft “falsch geschriebene Policies”, aber nicht “richtig, aber zu enge Policies”. Zu enge Policies verhindern, dass der Agent seine Arbeit erledigen kann, und der Betriebsdruck führt dazu, dass die Regeln gelockert werden. Sobald die Absicht gelockert wird, führt selbst die strengste Verifizierung nur zur präzisen Ausführung einer lockeren Absicht. Die Sicherheitsverantwortung verschiebt sich vom Code auf die Policy-Autoren, die Policy selbst wird zum neuen Audit-Objekt.
Abbildung: Sandbox-Zwangspunkte – Policies wirken an den Grenzen Dateisystem, Netzwerk, Anmeldeinformationen und ausgehender Verkehr, wobei jede Grenze einer eigenen Komponente entspricht. Quelle: OpenShell-Repository-Dokumentation
Watchdog auf BlueField-4 DPU: Isolation in Millisekunden
Das Sentry-Referenzdesign verlagert den Watchdog aus dem Host-System. Es läuft auf der BlueField-4 DPU, überwacht out-of-band die auf der Haupt-CPU laufenden Agenten und kann laut Herstellerangaben unkontrollierte Agenten in Millisekunden isolieren. Im Demoumgebung wurde auch eine Vera-CPU eingesetzt.
Out-of-band ist der Schlüssel dieses Designs. In-band-Überwachung teilt sich denselben Kernel und Vertrauensbereich wie das überwachte Objekt – bei einem Host-Kompromittiert geht auch die Überwachung unter. Die DPU hat eigene Rechenleistung und Netzwerkpfade, sodass der Agent auf der Haupt-CPU im Falle eines Kontrollverlusts nicht auf den Watchdog selbst zugreifen kann. Die Isolationszeit wird in Millisekunden gemessen, das Zeitfenster für bösartige Aktivitäten entsprechend – vorausgesetzt, die Firmware und Software-Stack auf der DPU-Seite halten stand, und der Watchdog selbst wird zum neuen hochwertigen Angriffsziel.
Die offizielle Pressemitteilung listet gleichzeitig 12 Branchenpartner und Integratoren auf, darunter Cloud-Anbieter und Sicherheitsfirmen. Die Positionierung in der Ökologie ist eindeutig: NVIDIA möchte “Agenten in einer laufzeitgebundenen Umgebung” zur Standard-Bereitstellungsform machen, ähnlich wie Hypervisor bei virtuellen Maschinen.
Versionsnummer 0.1.x ist ehrlicher als “broadly available”
Die Versionsnummer kühlt zunächst einmal ab. OpenShell befindet sich derzeit in der stabilen Version 0.1.x, bei einem Veröffentlichungsrythmus von etwa drei Wochen, aber die offizielle Formulierung lautet “now broadly available”. Der Rhythmus von drei Wochen pro Version ist bereits ein Signal: Interfaces und Semantik sind noch im Wandel, die Integration in die Produktion erfordert Migrationskosten; zwischen den Worten “broadly available” und 0.1.x liegt Beurteilungsraum für die Anwender.
Der zweite Kälteschlag: Die Sandbox reduziert den Explosionsradius, beseitigt aber nicht das Risiko. Die Kernel-Ebene, der Anmeldeinformations-Gateway und die Policy-Engine selbst werden zu neuen Vertrauensbasen – ein Problem bei diesen bedeutet einen Grenzausfall. Die Angriffsfläche verlagert sich, aber das Gesamtvolumen bleibt unverändert – zu auditierende Objekte erweitern sich vom “Agenten-Anwendung” auf die “Sandbox-Laufzeit”.
Der Richtungsstreit ist auch noch nicht entschieden. Anthropics Claude Managed Agents und andere Plattformen bringen die Sandbox in die Cloud-Dienste, wo Benutzer ihre eigenen Grenzen nicht einrichten müssen. OpenShell geht den Weg der selbst gehosteten, auditierbaren Laufzeit. Die Voraussetzungen für beide Wege sind unterschiedlich: Teams, bei denen die Daten nicht das verlassen dürfen und die eigene Audit-Spuren benötigen, werden die letztere Option wählen; Teams ohne spezialisierte Betriebsfähigkeiten für Grenzen werden Managed Services bevorzugen, um Aufwand zu sparen. Die Entscheidung hängt von Compliance-Anforderungen und Betriebsfähigkeiten ab, beide Wege haben ihre Berechtigung.
Software kostenlos, Hardware wie gehabt
Die Geschäftsrechnung muss klar sein. OpenShell wird unter Apache 2.0 als Open Source veröffentlicht, was die Compliance-Hürden für die Agenten-Bereitstellung senkt; das Sentry-Referenzdesign ist an BlueField-4 DPUs und Vera-CPUs gebunden. Die Software wird kostenlos verteilt, die Sicherheits-Hardware wird pro Stück verkauft – eine Wiederholung des alten CUDA-Modells: Öko-Tools kostenlos, Rechenleistung kostenpflichtig. Die Sandbox-Laufzeit selbst erzeugt keine Einnahmen – wo die Grenze läuft, dort wird das Geld verdient.
Diese Vorgehensweise ist auch für die Benutzer nachvollziehbar: Die Wahl von OpenShell ergibt eine auditierbare Grenze und eine klare Hardware-Einkaufsliste; die Wahl einer Managed Platform ergibt einen wartungsfreien Betrieb. Die beiden Lieferformen rechnen sich jeweils für sich, allein die Open-Source-Lizenz des Repositories verrät nicht die Gesamtstrategie des Geschäftsmodells.
Zurück zur anfänglichen Grenzlinie. Prompt-Barrieren kontrollieren, was das Modell sagt, Kernel-Grenzen kontrollieren, was Prozesse tun können; die erste hängt von der Kooperationsbereitschaft des Modells ab, die zweite von der Richtigkeit der Policy. Nachdem NVIDIA sowohl die Open-Source-Laufzeit als auch den DPU-Watchdog vorgestellt hat, hat der Schwerpunkt der KI-Agenten-Sicherheit sich von “dem Modell gehorsam machen” zu “verhindern, dass Überschreitungen weit gehen” verlagert. Ob das Modell die Kontrolle verliert, bleibt ungewiss, aber wie weit Prozesse gehen können, ist nun messbar und auditierbar – dies ist das eigentliche Neue in der Veröffentlichung vom 28. September, und der Teil, den die Versionsnummer 0.1.x noch nicht umsetzen konnte.
Referenzlinks:
- NVIDIA-Offizielle Pressemitteilung
- OpenShell-Repository-README
- OpenShell-Architektur-Dokumentation
