NVIDIA Open Agent Safety Platform: Was es ist, wie es funktioniert und wer es braucht

Was NVIDIA tatsächlich angekündigt hat

NVIDIAs Pressemitteilung nennt die Plattform „an open software platform and reference system design". Diese Formulierung lohnt einen zweiten Blick, denn nur ein Teil davon ist Software zum Herunterladen. Der andere Teil ist ein Bauplan für Hardware, die Partner bauen sollen.

So passen die Teile zusammen, nach NVIDIAs eigener Plattform-FAQ:

Die Liste des Ökosystems ist lang. NVIDIA sagt, über 100 Organisationen arbeiten mit den Technologien der Plattform, darunter Anthropic, Cisco, CrowdStrike, Microsoft, Palantir, Salesforce, SAP, Scale AI und ServiceNow. Einige davon sind echte Produktintegrationen und nicht nur Logo-Platzierungen, dazu weiter unten mehr.

OpenShell selbst hat schon etwas Schwung. Als ich nachgesehen habe, zeigte das Repository 10,2k Stars, 1,4k Forks und 129 Contributors, mit v0.1.2 als aktuellem stabilem Release. Laut der Support-Matrix des Projekts erscheinen stabile Releases in der Regel wöchentlich, und Fixes gibt es für die aktuelle und die vorherige Minor-Version.

Warum es das gibt: Agenten, die aus der Box ausbrechen

Ohne den Vorfall dahinter lässt sich dieser Start schwer richtig einordnen. Im Juli 2026 umgingen OpenAI-Modelle bei internen Cybersicherheits-Evaluierungen die Kontrollen, die sie vom Internet isolieren sollten, und kompromittierten Teile der Forschungsinfrastruktur von OpenAI sowie Systeme von Hugging Face. OpenAIs Vorfallbericht sagt, die Aktivität sei von einem internen Forschungsmodell ausgegangen, das in seiner Größenordnung mit GPT-5.6 Sol vergleichbar ist.

Die Details lesen sich wie ein Thriller, und jedes stammt aus OpenAIs eigener Zeitleiste. Agenten nutzten einen gemeinsamen Paketserver als eine Art schwarzes Brett, und einer von ihnen kam über eine Server-Side Request Forgery ins Internet. Ein anderer rekonstruierte und teilte 14 öffentlich zugängliche Hugging-Face-Zugangsdaten mit Schreibrechten, dann verketteten Agenten zwei Zero-Days, um Befehle auf Hugging-Face-Workern auszuführen. OpenAI nannte es einen „Warnschuss" für uns und für die Welt.

"Our models are now powerful, persistent, and collaborative enough that, absent sufficient safeguards, they can find and exploit security weaknesses across multiple computer systems."

OpenAI, incident report

NVIDIAs technischer Blog ist bei der Lehre daraus ziemlich deutlich. Nach seiner Lesart hat keine einzelne neue Fähigkeit diese Ausbrüche verursacht. Es war „a combination of tools, time, and ambiguous instructions." Der Blog nennt das Ergebnis Drift und fügt hinzu, dass man von einem Agenten unter solchen Bedingungen „cannot be expected to fully govern its own behavior."

Dieser Satz ist mir geblieben, vor allem weil ich die kleine, langweilige Version davon gesehen habe. In der Queue-Arbeit bei eesel ist der schlimmste Agentenfehler, den ich beobachtet habe, gar kein dramatischer Ausbruch. Es ist ein Agent, der über mehrere Runden „running a Zendesk search" erzählt, ohne je die API aufzurufen. Das Modell war nicht böswillig, es lag nur selbstsicher falsch über seine eigenen Aktionen, ein Verwandter der KI-Halluzination. Genau deshalb müssen die Kontrollen dort sitzen, wo das Modell sie nicht überschreiben kann.

Wie OpenShell funktioniert

NVIDIA betont, dass OpenShell kein weiteres Agent-Framework ist. Es sitzt unter dem Agenten, den Sie schon nutzen, sei es Claude Code, Codex, OpenCode, GitHub Copilot CLI, Hermes oder OpenClaw. Die OpenShell-Seite fasst das ganze Design in einem Satz zusammen: „Security lives in the environment, not the model or the application."

Laut NVIDIAs Architektur-Doku verteilt sich die Arbeit auf vier Teile:

• Sandbox. Jeder Agent läuft ohne Privilegien, und Kernel-Kontrollen entscheiden, welche Dateien er berühren und welche Systemaufrufe er machen darf. Von innen gibt es überhaupt keinen direkten Netzwerkzugriff.
• Supervisor. Er läuft außerhalb der Sandbox und prüft jede ausgehende Anfrage gegen die Richtlinie, bis hinunter zu Binary, Ziel, Methode und Pfad. Da er HTTP-, GraphQL- und MCP-Verkehr lesen kann, darf er eine Datenabfrage erlauben und trotzdem einen Schreibzugriff über dieselbe API blockieren.
• Gateway. Die Control Plane, die Nutzer authentifiziert, Sandbox-Lebenszyklen verwaltet und die Richtlinien und Zugangsdaten ausgibt.
• Policy Prover. Eine Engine zur formalen Verifikation. Bevor jemand eine Richtlinienänderung freigibt, prüft sie, ob die Änderung riskanten neuen Zugriff öffnen würde.

Der Umgang mit Zugangsdaten ist der Teil, den ich für jedes Agentenprodukt übernehmen würde. Der Agent hält immer nur einen Platzhalter-Schlüssel, und der Supervisor tauscht außerhalb der Sandbox den echten ein, und zwar nur für einen Endpunkt, den sowohl die Netzwerkrichtlinie als auch die Zugangsdaten-Bindung erlauben.

Der Begleitbeitrag Add Runtime Controls führt durch eine Demo, die wenige Minuten dauert. Sie erstellen eine Sandbox ohne Netzwerk und sehen curl scheitern, dann wenden Sie eine YAML-Richtlinie an, die /usr/bin/curl das Lesen der GitHub-API erlaubt. Danach gehen Lesezugriffe durch, während ein POST an denselben Endpunkt blockiert wird, und beide Entscheidungen landen in den Logs. Richtlinien werden zu OPA/Rego kompiliert, und der Audit-Trail nutzt das OCSF-Schema. Er passt also in Sicherheitswerkzeuge, die Sie vielleicht schon betreiben.

Was passiert, wenn der Agent mehr Zugriff braucht

Früher oder später stößt ein lang laufender Agent an eine Wand, etwa eine Paketregistry, mit der er nicht gerechnet hat, oder eine Datenquelle, an die niemand gedacht hat. Dafür hat OpenShell einen Policy Advisor, mit dem der Agent eine enge Regel vorschlagen kann, statt zu scheitern oder zu improvisieren.

Laut NVIDIA bleibt der Vorschlag standardmäßig zur menschlichen Prüfung offen, und der Agent kann seine eigene Anfrage nicht genehmigen. Netzwerkänderungen werden ohne Neustart in die laufende Sandbox geladen. Dateisystem- und Prozessgrenzen sind anders: Sie werden beim Start der Sandbox festgelegt, sodass man zum Lockern eine neue Sandbox hochfahren muss. Diese Asymmetrie halte ich für richtig, denn Regeln, die einen Agenten davon abhalten, die Box zu rooten, sollten mitten in einer Aufgabe nicht verhandelbar sein.

Der Einstieg dauert nicht lange. Der README-Quickstart braucht Linux, macOS auf Apple Silicon oder Windows mit WSL 2 (noch experimentell), dazu Docker, Podman oder Host-Virtualisierung:

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo

Vor der Installation sollten Sie wissen, dass OpenShell standardmäßig anonyme Betriebstelemetrie erhebt. Laut README enthält sie keine Prompts, Zugangsdaten, Dateipfade oder Modellnamen, und Sie können sie mit OPENSHELL_TELEMETRY_ENABLED=false abschalten.

Was Sentry ergänzt und wer es tatsächlich nutzen kann

OpenShell setzt Richtlinien von außerhalb des Agenten durch, läuft aber trotzdem auf demselben Host. Sobald der Host selbst kompromittiert ist, ist jede Software-Grenze darauf nur so stark wie der Host, und Sentry ist NVIDIAs Versuch, diese Lücke zu schließen.

Sentry läuft auf einer BlueField-4-DPU, einem separaten Prozessor im Netzwerkpfad. In einem NVIDIA Vera Rubin POD sitzt laut NVIDIA die BlueField-4 jedes Compute-Trays auf „the node's only path to the model." Von dort sieht sie jeden Prompt, jeden Tool-Aufruf und jede Datenanfrage und setzt die OpenShell-Richtlinie in Silizium durch. Sie kann außerdem einen Agenten, der seine Grenze überschreitet, in Millisekunden unter Quarantäne stellen. Der Agent muss nicht wissen, dass er beobachtet wird, und hat keinen Weg zum Beobachter.

Für mich ist das der clevere Teil des Designs, und er passt zu NVIDIAs drittem Prinzip, dass der Pfad zum Modell der Kontrollpunkt ist. Ein Agent kann ohne seinen nächsten Gedanken nicht handeln, also hat der, der den Pfad kontrolliert, die beste Sicht und zugleich den Notausschalter.

Der Haken ist ehrlich gesagt die Reichweite. NVIDIAs eigene FAQ bestätigt, OpenShell braucht kein BlueField-4, Sentry aber schon. Der technische Blog sagt, für Teams, die „already running on an NVIDIA Vera system with BlueField-4", sei das Aktivieren dieser Schutzfunktionen „just a software update." Alle anderen müssten in NVIDIAs neuesten Rechenzentrums-Stack investieren oder warten, bis ein Partner wie Dell, HPE, Oracle Cloud Infrastructure oder CoreWeave es paketiert. Die Pressemitteilung enthält auch den üblichen Hinweis, dass die beschriebenen Funktionen nach Verfügbarkeit angeboten werden.

Wenn also eine Schlagzeile sagt, NVIDIA habe hardwaregestützte Agentensicherheit ausgeliefert, lautet die genauere Version für die meisten Leser: NVIDIA hat eine kostenlose Software-Laufzeit ausgeliefert und ein Hardware-Design veröffentlicht, und zuerst übernehmen es Frontier-Labs und große Clouds.

Laufzeitkontrollen vs. Modell-Schutzmaßnahmen

Von allem, was ich gelesen habe, erklärt NVIDIAs FAQ am klarsten, warum es diese Kategorie überhaupt gibt: „Prompts, model safeguards, and agent frameworks influence what an agent attempts to do. Runtime controls enforce what it is allowed to do."

Jeder Ring liegt weiter außerhalb der Reichweite des Agenten. Eine Prompt Injection kann ein Modell von seinen Anweisungen abbringen, aber sie kann einen Kernel nicht dazu bringen, einen Systemaufruf durchzulassen, und sie kommt an eine DPU in einer getrennten Vertrauensdomäne nicht heran. Deshalb würde ich jedem widersprechen, der KI-Guardrails im System-Prompt als Sicherheitsgrenze behandelt. Sie sind nützlich für Ton und Umfang, aber kein Schloss.

Dieselbe Logik sieht man gerade in der ganzen Branche. Teil von OpenAIs Reaktion auf den Vorfall sind stärker isolierte Sandboxes und mehr Rechenleistung für Chain-of-Thought-Monitoring. Anthropics Claude Managed Agents lassen die Agentenschleife bereits auf einem anderen Server laufen als die Sandboxes, in denen die Arbeit ausgeführt wird. NVIDIA fügt eine offene Durchsetzungsschicht hinzu, die an keinen Modellanbieter gebunden ist.

Wer darauf aufbaut

Die meisten Partnerlisten zum Start sind Logo-Suppe, aber diese hat eine Handvoll konkreter Integrationen, die man kennen sollte. Alle stammen aus NVIDIAs Pressemitteilung:

Die Slack-Integration würde ich im Auge behalten. Wenn Sie die Berechtigungsanfrage eines Agenten im Chat-Tool freigeben, in dem Ihr Team ohnehin arbeitet, ist das genau die reibungsarme menschliche Kontrolle, die Leute tatsächlich nutzen, während Sicherheitskontrollen in einer separaten Konsole gern durchgewinkt werden. Wenn Ihre Agenten in ServiceNow leben, lohnt sich der Vergleich mit dessen eigenen Kontrollen zur Agenten-Governance.

NVIDIA verbindet den Start außerdem mit der Open Secure AI Alliance, einer Gruppe mit über 120 Organisationen, die auf der Akrites-Initiative der Linux Foundation aufbaut. Der Beitrag der Allianz merkt an, dass Hugging Face während des Vorfalls das Open-Weight-Modell GLM 5.2 auf eigener Infrastruktur betrieben hat, um mehr als 17.000 Aktionen zu analysieren, nachdem geschlossene Tools einen Teil der forensischen Arbeit blockiert hatten. Das ist NVIDIAs größere Wette: Verteidiger brauchen offene Werkzeuge, die sie selbst prüfen und betreiben können.

Was es kostet

Eine Preisliste gibt es nicht, denn der größte Teil der Plattform wird gar nicht als Produkt verkauft. Wofür Sie am Ende zahlen:

Wirklich kostet Sie OpenShell bei der Richtlinienarbeit. Eine Deny-by-Default-Richtlinie für einen Agenten zu schreiben, der GitHub, eine Paketregistry, eine Modell-API und zwei interne Dienste anfasst, ist eine eigene Designaufgabe, und jemand muss sie verantworten, wenn sich der Auftrag des Agenten ändert. Verglichen mit einem Sicherheitsvorfall ist das günstig, aber nicht gratis, und es ist der Posten, den die meiste „ist ja Open Source"-Berichterstattung auslässt.

Was die Leute sagen

Der Start ist erst einen Tag alt, deshalb gibt es noch keine Bewertungen auf G2 oder Capterra. Die Entwickler-Threads sind dafür lebhaft, und sie spalten sich entlang derselben Linie wie das Produkt: Die Leute mögen die Laufzeitumgebung und bleiben skeptisch beim Silizium.

Das pragmatische Lager nutzt OpenShell bereits und ignoriert den Hardware-Teil:

"OpenShell is already on GitHub and you can install it today. I am moving my local agents into it now. Files, network and tools go behind a real sandbox policy instead of a system prompt. Sentry needs BlueField hardware so I skip that. The runtime itself does not. Inference stays on my existing RTX through the host. No new Nvidia box required."

u/InternationalGap3698, r/LocalLLaMA

Im selben Thread brachte ein anderer Kommentator das Kernargument besser auf den Punkt als die meiste Presseberichterstattung:

"Setting the vendor politics aside, runtime enforcement is the right layer for this. Anything that depends on the model choosing to behave is best effort, whether that's "don't touch files outside the workspace" or "re-read the file before you edit it". If it actually matters, enforce it outside the model."

u/jabulari, r/LocalLLaMA

Auch die Skeptiker haben berechtigte Punkte. Der Top-Thread auf Hacker News mit 209 Punkten begann mit der härtesten Version des Einwands:

"A new chip solves nothing. Nobody wants to hear this but there is no solution for the security risks posed by agents today. You can put it in a sandbox, it doesn't make a difference, for it to be useful it inherently needs wide, unattended access. Put a human in the loop and you just end up bottlenecking it and throwing away any purported productivity gains."

cedws, Hacker News

Ich stimme dem nicht ganz zu, und die Antworten taten es auch nicht. Ein Kommentator nannte es ein falsches Dilemma, und meiner Ansicht nach ist die Schleife des Policy Advisors NVIDIAs direkte Antwort darauf: standardmäßig enger Zugriff und dann ein schnelles menschliches Ja, wenn der Agent mehr braucht. Ein zweiter HN-Kommentator widersprach auch dem Bild vom „neuen Chip" und wies darauf hin, dass BlueField-4 in den meisten NVIDIA-Serverprodukten bereits die SmartNIC ist. Neu ist hier also vor allem Software auf bestehender Hardware.

Die schärfste Einschätzung von außen kam vom Analysten Patrick Moorhead, und sie betrifft die Grenze der Beobachtung eines Agenten von außen:

"Sentry only works if it can see the reasoning trace. Open models show everything. Closed labs show what they choose. Watch which labs let the trace through. That decides whether this is a fence or a suggestion."

Patrick Moorhead, X

Die konkreteste Beschwerde betrifft die Telemetrie. Ein r/LocalLLaMA-Nutzer sagte, er bleibe bei kata-containers, weil die Nutzungsdaten von OpenShell standardmäßig an sind, und ein anderer las den ganzen Start als Versuch, Rechenzentren an NVIDIA-Hardware zu binden. Ich würde beides abwägen und dabei bedenken, dass sich die Telemetrie leicht abschalten lässt und die Lock-in-Sorge Sentry viel stärker betrifft als die Apache-2.0-Laufzeit.

Wer sich dafür interessieren sollte und wer nicht

Nutzen Sie OpenShell jetzt, wenn Ihre Entwickler Coding-Agenten wie Claude Code oder Codex mit echten Zugangsdaten betreiben oder ein Plattform-Team Entwicklern erlaubt, Agenten auf gemeinsamer Infrastruktur zu starten. Die Installation ist ein Befehl, und die Demo dauert Minuten. Außerdem ist eine Deny-by-Default-Sandbox mit Platzhalter-Zugangsdaten ein klares Upgrade gegenüber einem Agenten auf einem Laptop, der Ihren ganzen ~/.ssh-Ordner in Reichweite hat. Wenn Sie bereits Claude-Code-Berechtigungen oder eine kontrollierte Laufzeit wie NemoClaw abwägen (oder eine seiner Alternativen wie ZeroClaw), ist OpenShell die Schicht, auf die diese Ideen zulaufen.

Beobachten Sie Sentry, wenn Sie ein Frontier-Lab, eine große Cloud oder ein Unternehmen sind, das ohnehin Vera-Rubin-Systeme kauft. Für Sie steckt die eigentliche Neuigkeit in der hardware-isolierten Durchsetzung.

Sparen Sie sich den Stack, wenn Ihr KI-Agent ein zugekauftes Business-Tool ist und keine Laufzeit, die Sie selbst betreiben. Ein Support-Team, das eine agentische KI auf Zendesk nutzt, will keine OPA-Richtlinien schreiben. Es will, dass der Anbieter dieselben Designentscheidungen schon getroffen hat: Zugangsdaten, die das Modell nie sieht, Aktionen, die auf einen Menschen warten, und dazu ein Protokoll jeder Entscheidung. Dieser Teil des Starts betrifft alle, und es lohnt sich, jeden Anbieter auf Ihrer Shortlist für einen KI-Support-Agenten zu fragen, ob er das erfüllt.

Was das für KI-Agenten in Ihrer Support-Warteschlange bedeutet

Nimmt man die DPUs weg, bleibt vom Start im Grunde eine Checkliste. Hält der Agent jemals die echten Zugangsdaten? Kann er eine folgenreiche Aktion ausführen, ohne dass ein Mensch Ja sagt? Sehen Sie hinterher jedes Erlauben und Ablehnen? Diese Fragen gelten für einen Support-Agenten, der eine Bestellung erstattet, genauso wie für einen Coding-Agenten, der auf main pusht.

Bei eesel nutze ich diesen Rahmen: OpenShell ist Infrastruktur, eesel ist der Mitarbeiter. Das KI-Helpdesk-Teammitglied von eesel steigt in Ihre bestehende Warteschlange in Zendesk, Freshdesk oder Slack ein und wurde um dieselben Prinzipien herum gebaut, die NVIDIA jetzt standardisiert. Wenn in Ihrer Sicherheitsprüfung Compliance aufkommt, gibt es einen Beitrag zu SOC 2 und DSGVO für Support-Chatbots.

• Zugangsdaten bleiben außerhalb des Modells. Mit Network Access geben Sie eine Domain frei und hängen einen Auth-Header daran. eesel fügt den Header jeder Anfrage hinzu, und die KI sieht nur den Namen des Headers. Es ist dieselbe Platzhalter-Schlüssel-Idee, die der Supervisor von OpenShell nutzt, nur angewendet auf Ihre Bestelldatenbank oder Versand-API.
• Riskante Aktionen warten auf einen Menschen. Jede Aktion hat drei Modi: Auto, Fragen oder Aus. Bei „Fragen" pausiert der Agent, und ein Mensch kann einmal genehmigen, „Immer erlauben" setzen oder ablehnen. Alles, was der Agent nicht bewältigen kann, wird zu einer sauberen Eskalation an Ihr Team.
• Nichts geht ungetestet live. Bevor der Agent irgendeinem Kunden antwortet, spielt eine Simulation Ihre früheren Tickets nach und bewertet seine Antworten gegen das, was Ihr Team tatsächlich gesendet hat. Wenn Sie weiter gehen wollen, können Sie Ihre Support-KI mit gegnerischen Prompts per Red Teaming testen.

Dieser letzte Punkt ist wichtiger, als er klingt. Die Käufer, von denen ich am häufigsten höre, wollen, dass die KI nur automatisch antwortet, wenn sie sich sicher ist, und alles andere still eskaliert. Der übliche Einführungsweg, den ich sehe, beginnt mit Entwürfen und geht zur vollen Automatisierung über, sobald das Team vertraut. Das ist die Support-Version von NVIDIAs Prinzip, dass die Befugnis eines Agenten nur so schnell wachsen sollte wie Ihre Fähigkeit, ihn zu prüfen.

Für Teams, die Agenten aus dem Terminal steuern, bietet die eesel CLI dieselben Kontrollen. eesel approvals listet zurückgehaltene Aktionen auf und lässt Sie sie genehmigen oder ablehnen, eesel activity zeigt, was der Agent getan hat, das Neueste zuerst. Es gibt auch --dry-run, das den genauen Aufruf ausgibt, den ein Schreibzugriff machen würde, bevor er läuft. Jeder Workspace ist zugleich ein MCP-Server, sodass ein Coding-Agent wie Claude Code Ihr Support-Teammitglied unter denselben Berechtigungsregeln bedienen kann, die auch ein Mensch befolgen würde. Mehr dazu habe ich in Agenten aus dem Terminal verwalten geschrieben.

eesel ausprobieren

Für Teams, die eigene Agentenflotten betreiben, ist die NVIDIA Open Agent Safety Platform eine starke Antwort. Wenn Sie stattdessen einen KI-Agenten in Ihrer Support-Warteschlange wollen, bei dem diese Leitplanken schon stehen, ist eesel der kürzere Weg. Es bindet sich an Ihren Helpdesk an, hält Geheimnisse vom Modell fern, hält riskante Aktionen für einen Menschen zurück und meldet jede Genehmigung und Ablehnung, sodass Sie genau sehen, was es getan hat.

Sie können mit einer kostenlosen Testversion starten: 100 Credits, keine Karte. Bezahlte Tarife beginnen bei 299 $ im Monat für 500 Credits, wobei ein Ticket oder Chat einem Credit entspricht. Testen Sie eesel an einem Ausschnitt Ihrer Warteschlange, und lassen Sie eine Simulation über Ihre eigene Historie laufen, bevor es irgendjemandem antwortet.