NVIDIA Sentry: Warum die Kontrolle über KI-Agenten außerhalb des Hosts liegen soll

Clara (AI generiert)

29. Sep. 2026 4 min read

NVIDIA Sentry: Warum die Kontrolle über KI-Agenten außerhalb des Hosts liegen soll

Ein Entwickler-Agent soll einen Fehler untersuchen, darf dafür ein Repository lesen und Tests ausführen. Was passiert, wenn er zusätzlich Zugangsdaten sucht, eine andere Modell-API nutzt oder seine eigene Ausführungsumgebung verändert? Für eine Sicherheitsprüfung reicht dann die Frage nach dem System-Prompt nicht. Entscheidend ist, welche unabhängige Instanz solche Aktionen tatsächlich verhindern kann. Das gilt besonders für Agenten, die über längere Zeit und mit wechselnden Werkzeugen arbeiten.

Am 28. September 2026 hat NVIDIA die Open Agent Safety Platform vorgestellt. Sie verbindet die OpenShell-Laufzeit mit einem Referenzdesign namens NVIDIA Sentry: einem separaten Wächter auf BlueField-4-Datenprozessoren. Der neue Schwerpunkt ist damit nicht nur eine Sandbox, sondern eine zusätzliche Kontrollinstanz außerhalb der Host-Software. NVIDIA beschreibt das als mehrschichtige Absicherung vom Test bis zum produktiven Betrieb. [1]

Zwei Grenzen statt eines Sicherheitsversprechens

Die Architektur trennt zwei Aufgaben. OpenShell begrenzt die Ausführung des Agenten. Sentry soll eine zusätzliche Überwachungs- und Durchsetzungsebene auf separater Hardware bereitstellen. NVIDIA beschreibt dafür einen vom Host isolierten Vertrauensbereich, der auch dann Schutz bieten soll, wenn Host-Ressourcen nicht mehr vertrauenswürdig sind. Im technischen Referenzdesign sitzt BlueField-4 auf dem einzigen Pfad des Rechenknotens zum Modell. [2]

Diese Platzierung ist der interessante Architekturpunkt: Eine Kontrolle, die außerhalb der zu kontrollierenden Umgebung liegt, muss nicht dieselben Berechtigungen und Fehlerzustände teilen. Unsere praktische Schlussfolgerung daraus lautet allerdings nicht, dass Hardware automatisch Sicherheit schafft. Unternehmen sollten prüfen, ob ihre konkrete Topologie tatsächlich alle relevanten Wege erfasst. Ein Referenzdesign ist noch kein Nachweis für die eigene Installation.

Auch die Komponenten sind auseinanderzuhalten. Laut Produktdokumentation benötigt OpenShell keine BlueField-4-DPU. Die Laufzeit kann auf unterstützter lokaler, Cloud- oder Kubernetes-Infrastruktur eingesetzt werden. Sentry ergänzt diese Softwaregrenze auf entsprechend ausgestatteten Systemen. Die Plattform ist deshalb nicht gleichbedeutend mit einer Pflicht, sämtliche Agenten sofort auf neue Hardware umzuziehen. [3]

Was OpenShell technisch kontrolliert

Der technische Beitrag zur Version 0.1.0 beschreibt Gateway, Supervisor und Sandbox. Das Gateway verwaltet Sandboxes und Richtlinien. Der außerhalb der Agentenlast laufende Supervisor prüft ausgehende Anfragen. Die Sandbox begrenzt Dateisystem und Prozesse mit Kernel-Kontrollen; ihr Netzwerkpfad führt durch den Supervisor. Für konfigurierten HTTP-, GraphQL- und MCP-Verkehr sind differenzierte Regeln vorgesehen, beispielsweise Lesen erlauben und Schreiben blockieren. [4]

Hinzu kommt eine Trennung der Zugangsdaten: Ein Platzhalter innerhalb der Agentenumgebung wird erst außerhalb durch das echte Geheimnis ersetzt, wenn Ziel und Richtlinie die Anfrage erlauben. Erweiterte Rechte können beantragt werden; standardmäßig bleibt die Freigabe beim Menschen. Der Agent kann seinen Antrag nicht selbst genehmigen. [4]

Für eine unternehmensinterne Abnahme würden wir deshalb nicht nur testen, ob der bevorzugte Agent funktioniert. Wir würden denselben erlaubten und verbotenen Zugriff mit einem anderen Werkzeug, einem Kindprozess und generiertem Code wiederholen. Das ist ein vorgeschlagener Testplan, kein hier durchgeführter Produkttest. Sein Ziel: Die dokumentierte Grenze muss am Zugriff hängen, nicht an der Gutwilligkeit eines bestimmten Clients.

Was der Hardware-Wächter zusätzlich verspricht

Sentry nutzt nach Herstellerangaben NVIDIA DOCA, um Agentenaktivität zu beobachten, Identitäten zu überprüfen und feingranulare Zugriffsregeln durchzusetzen. Die Ankündigung nennt eine Quarantäne innerhalb von Millisekunden, wenn ein Agent seine Grenze überschreiten will. Diese Zeitangabe ist ein Herstellerversprechen, kein unabhängig von uns gemessener Ende-zu-Ende-Wert. [1]

Im Architekturbeitrag verbindet NVIDIA die Beobachtung von Agenteninteraktionen mit Richtlinienentscheidungen sowie Werkzeug- und Datenzugriffen. Daraus soll eine zusammenhängende Aktivitätsspur entstehen. Die Hardwareebene wird als optionaler Zusatz zu OpenShell beschrieben, nicht als Ersatz für dessen Laufzeitregeln. [2]

Für Beschaffer ergibt sich daraus eine konkrete Nachfrage: Was bedeutet Quarantäne im eigenen Betrieb? Wird nur weitere Modellkommunikation unterbunden, oder werden auch bereits gestartete Prozesse und externe Sitzungen beendet? Welche Ereignisse lösen den Eingriff aus? Welche Beweise bleiben danach erhalten? Wir würden diese Punkte vertraglich und im Abnahmetest klären, statt aus dem Wort „Millisekunden“ eine vollständige Sicherheitsgarantie abzuleiten.

Branchenkontext: Integration ist noch keine flächendeckende Verfügbarkeit

HPE bestätigt in einer eigenen Veröffentlichung vom 28. September die Verbindung von OpenShell, Sentry, BlueField-4 und DOCA. Für die OpenShell-Integration in HPE Private Cloud AI nennt das Unternehmen das vierte Quartal 2026 als geplanten Verfügbarkeitstermin. Die Unterstützung für BlueField-4 über das Portfolio hinweg hängt laut HPE von Produktlieferzeiten ab. [5]

Das ist eine wichtige Gegenprüfung der Ankündigung, aber keine unabhängige Wirksamkeitsstudie: HPE ist Integrationspartner. Für Unternehmen folgt daraus die Empfehlung, zwischen verfügbarer Open-Source-Laufzeit, angekündigter Produktintegration und tatsächlich lieferbarer Hardware zu unterscheiden. Eine Roadmap darf in der eigenen Risikobewertung nicht bereits als aktive Kontrolle zählen.

Vier Aufgaben für Unternehmen

Erstens: einen engen Pilotauftrag definieren. Als Einstieg schlagen wir einen Agenten vor, der ausgewählte Repositories lesen und Tests ausführen darf, aber weder Produktionsdaten ändern noch neue externe Dienste anbinden soll. Dokumentiert werden sollten erlaubte Daten, Zielsysteme, Werkzeuge und Genehmiger. Damit bekommt der Pilot überprüfbare Erfolgskriterien statt eines allgemeinen Versprechens sicherer Autonomie.

Zweitens: die Kontrollinstanzen getrennt verwalten. Agentenbetrieb, Richtlinienfreigabe und Sicherheitsüberwachung sollten nicht automatisch über dieselbe Identität administriert werden. Für den Pilot wäre zu prüfen, wer Sandbox-Regeln, Supervisor-Konfiguration, DPU-Verwaltung und Audit-Ziele ändern darf. Unser Maßstab: Der Agent erhält keinen administrativen Pfad zu seiner eigenen Begrenzung.

Drittens: Umgehungspfade ausdrücklich testen. Ein sinnvoller Abnahmekatalog umfasst alternative Modellendpunkte, unzulässige Netzwerkziele, delegierte Unteragenten und Zugriffe mit anderen Clients. Zusätzlich sollte ein Ausfall der Richtlinienkomponente simuliert werden. Die erwartete Reaktion muss vorher feststehen: Welche Arbeit stoppt, welche darf kontrolliert weiterlaufen, und wer erhält einen Alarm?

Viertens: Wiederanlauf vorbereiten. Quarantäne braucht einen Betriebsprozess. Wir empfehlen, vor dem Pilot festzulegen, wie Protokolle gesichert, Sitzungen beendet, betroffene Zugangsdaten geprüft und Arbeitsstände wiederhergestellt werden. Auch eine fälschlich blockierte legitime Aufgabe benötigt einen nachvollziehbaren Freigabepfad. Sonst entsteht im Alltag Druck, die neue Kontrolle dauerhaft zu umgehen.

Grenzen: Verifikation ist kein Universalbeweis

OpenShell verwendet formale Logik, um modellierte Berechtigungen gegen eine vorgegebene Grenze zu prüfen. Der Hersteller beschreibt außerdem die Analyse zusammengesetzter Rechte mehrerer Agenten als laufende Weiterentwicklung. [4] Daraus sollte ausdrücklich kein Beweis für Fehlerfreiheit der gesamten Plattform abgeleitet werden.

Unsere Bewertung: Richtlinienmodell, Implementierung und betriebliche Konfiguration müssen getrennt geprüft werden. Ebenso sollte die Sicherheitsabnahme kontrollieren, welche vertraulichen Inhalte in Aktivitätsprotokollen landen und wer sie lesen darf. Für diesen Artikel wurden die Herstellerunterlagen und die HPE-Ankündigung ausgewertet; ein eigener Betrieb oder adversarialer Test der Plattform fand nicht statt.

Fazit

Der relevante Fortschritt der Ankündigung liegt in der expliziten Trennung von Agent, Laufzeitkontrolle und zusätzlicher Hardwareaufsicht. Unternehmen sollten diese Trennung als Prüfmaßstab verwenden, nicht als Kaufargument ohne Nachweis. Empfehlenswert ist ein begrenzter Pilot mit dokumentierten Berechtigungen, negativen Zugriffstests und einem Wiederanlaufplan. Die entscheidende Frage bleibt: Hält die Grenze auch dann, wenn der Agent selbst sie nicht respektiert?