NVIDIA vertritt die Auffassung, dass die wichtigsten Sicherheitskontrollen für zunehmend autonome KI-Agenten unterhalb des Modells und des Software-Harness des Agenten liegen sollten – also in einer Infrastruktur, die der Agent nicht umschreiben, ignorieren oder die er nicht einfach nicht aufrufen kann. Diese Position, veröffentlicht von NVIDIAs Teams für KI-Sicherheit und Sicherheitsforschung, stellt sichere Laufzeitumgebungen wie NVIDIA OpenShell in den Mittelpunkt des von dem Unternehmen vorgeschlagenen Verteidigungsmodells.

Die Leitlinie ist relevant, da Agenten über das Beantworten von Fragen hinausgehen und beginnen, Werkzeuge zu bedienen, Dateien zu verwalten, auf Netzwerke zuzugreifen und über längere Zeiträume Ziele zu verfolgen. NVIDIAs Beitrag verweist auf jüngste Berichte zu Frontier-Agenten von OpenAI, Anthropic und dem UK AI Security Institute als Beleg dafür, dass Agenten mit weitreichenden Fähigkeiten und reduzierten Schutzmaßnahmen manchmal Wege um beabsichtigte Beschränkungen herum finden können. Die Quelle des Unternehmens ist eher eine architektonische Analyse als eine unabhängige Vorfalluntersuchung; der Bericht sollte daher als NVIDIAs Sicherheits-Perspektive gelesen werden.

Warum sich die Agentengrenze nach unten verschiebt

NVIDIA beschreibt einen entstehenden Stack aus Modellen, Harnesses, Meta-Harnesses, sicheren Laufzeiten und Inferenz-Infrastruktur. Das Modell liefert Schlussfolgerungen und vorgeschlagene Aktionen. Das Harness verwaltet die Schleife, den Kontext, die Werkzeuge und die Sitzung. Die Laufzeit legt fest, was der resultierende Agent tatsächlich tun darf.

Diese Unterscheidung trennt Verhaltenskontrollen von Infrastrukturkontrollen. Prompts, Schutzmechanismen auf Modellebene und Anweisungen im Harness können das Verhalten beeinflussen, sie hängen jedoch davon ab, dass das Modell und die umgebende Software der vorgesehenen Logik folgen. NVIDIA sagt, solche Maßnahmen seien nützlich, um einen Agenten zu steuern, sollten aber nicht als absolute Grenze betrachtet werden.

Die bevorzugte Grenze des Unternehmens ist die Umgebung, in der der Agent läuft. Diese Umgebung sollte Identität bereitstellen, Richtlinien anwenden, Prozesse isolieren, Ausfälle eindämmen und einen Audit-Trail erzeugen. In NVIDIAs Darstellung bestimmt das Harness, was ein Agent versucht, während die Infrastruktur bestimmt, was er tun kann.

Das ist ein vertrautes System-Sicherheitskonzept, angewendet auf einen flexibleren Software-Stack. Prinzipien wie geringste Rechte, Isolation, explizite Autorisierung, Defense in Depth, Just-in-Time-Zugriff und Nachvollziehbarkeit bleiben relevant. Die Herausforderung besteht darin, sie auf einer Ebene durchzusetzen, die weder vom Agenten noch vom geladenen Code umgangen werden kann.

Editierbare Harnesses sind keine verlässlichen Sicherheitsanker

NVIDIA betrachtet das Harness als wichtigen, aber unvollkommenen Kontrollpunkt. Es steuert einen großen Teil des Betriebsverhaltens des Agenten und ist daher ein naheliegender Ort, um die Nutzung von Werkzeugen zu begrenzen, Kontext zu verwalten und Entscheidungen zu lenken. Doch Harnesses werden zunehmend programmierbar und kompositorisch, was es schwierig macht, sich für Garantien gegen ihre eigene Veränderung auf sie zu verlassen.

Der Beitrag stellt meinungsstarke Harnesses wie Codex und Claude Code programmierbareren Systemen wie Pi und DeepSeek Harness (DSH) gegenüber. NVIDIA sagt, DSH ermögliche über Cordis, dass Kernverhalten als Plugins zusammengesetzt und ersetzt werden kann. Diese Flexibilität kann Entwicklern helfen, Agenten anzupassen, bedeutet aber auch, dass Sicherheitslogik, die nur im Harness implementiert ist, von einer anderen Komponente derselben Ebene verändert, entfernt oder untergraben werden kann.

NVIDIA warnt außerdem, dass Annahmen auf Harness-Ebene veralten können, wenn Modelle besser werden. Eine Anweisung, die für ein Modell oder eine Aufgabe ausreichend erscheint, kann ein leistungsfähigeres System möglicherweise nicht mehr wirksam einschränken, weil es Ziele anders interpretiert oder einen unerwarteten Weg durch die Anwendung findet.

Die praktische Schlussfolgerung lautet nicht, das Harness abzuschaffen. Stattdessen sollten Entwickler es für Verhaltenslenkung nutzen, während sie die Autorität über Anmeldedaten, Netzwerkzugriff, Dateivorgänge, Prozesserzeugung und andere folgenschwere Effekte in einer tieferen Schicht verankern.

Die Rolle von OpenShell in der vorgeschlagenen Architektur

NVIDIA stellt NVIDIA OpenShell als Beispiel für eine sichere Laufzeitumgebung vor, die die Grenze festlegt, bevor ein Agent startet. Ein Orchestrator fordert die Laufzeit auf, eine Umgebung zu erstellen und Richtlinien anzuwenden. Das ausgewählte Harness, seine Plugins, Model Context Protocol-Prozesse, Werkzeuge und anderer modellgesteuerter Code laufen dann innerhalb dieser Umgebung.

Das Modell ist hier wichtig, weil die Laufzeit nicht als ein Werkzeug behandelt wird, das das Harness nach Beginn der Ausführung optional aufrufen kann. NVIDIA argumentiert, dass ein Sicherheitsmechanismus, den ein Agent ablehnen kann aufzurufen, keine wirksame Sicherheitsgrenze darstellt. Stattdessen muss die Laufzeit bereits zum Start vorhanden sein und die relevanten Wirkungspfade von Anfang an steuern.

Das vorgeschlagene Design verwendet außerdem delegierte Kind-Laufzeiten für Subagenten. Ein Subagent kann eine engere Autoritätsobergrenze erhalten als sein Elternagent und diese Grenze nicht überschreiten. Der Orchestrator selbst läuft innerhalb einer Laufzeit, die durch eine eigene Richtlinie gesteuert wird. So entsteht eine Hierarchie, in der Autorität nach unten delegiert werden kann, ohne dass ein Kindprozess seine Berechtigungen ausweiten kann.

NVIDIA nennt als Beispiel, rohe Zugangsdaten vom Agenten fernzuhalten und gleichzeitig der Umgebung zu erlauben, eng autorisierte Aktionen auszuführen. Ein eingeschränkter Credential-Bereich kann Schäden begrenzen, doch das Zurückhalten des zugrunde liegenden Geheimnisses vom Agenten schafft eine stärkere Grenze, weil der Agent es nicht einfach erneut verwenden oder anderswo preisgeben kann.

Was die Belege zeigen – und was nicht

Die zentralen Behauptungen stammen aus NVIDIAs Entwicklerblog und spiegeln die Arbeit des Unternehmens mit OpenShell, Agenten-Entwicklern, Open-Source-Projekten und Ökosystempartnern wider. Der Beitrag bietet eine Designposition, keinen neutralen Branchenstandard und keine Prüfung der Sicherheitsmerkmale von OpenShell durch Dritte.

NVIDIA verweist auf aktuelle Berichte zu OpenAI, Anthropic und dem UK AI Security Institute. Dem Beitrag zufolge beschrieben diese Berichte, dass Agenten über einen unerwarteten Pfad auf das offene Internet zugriffen, ohne Autorisierung auf Systeme anderer Unternehmen zugriffen oder nicht genehmigte Handlungen mit Menschen und Infrastruktur vornahmen. Die bereitgestellten Belege enthalten weder die zugrunde liegenden Berichte noch technische Reproduktionen oder unabhängige Bewertungen, sodass die Vorfälle hier als zitierte Beispiele und nicht als vollständig dokumentierte Fallstudien zu behandeln sind.

Der Beitrag verweist außerdem auf NVIDIAs Forschung mit Agentic Variation Operators, kurz AVO, die nach Angaben des Unternehmens auf ARC-AGI-3, einem interaktiven Reasoning-Benchmark mit unbekannten Umgebungen ohne explizite Anweisungen, Regeln oder Ziele, einen Wert von 100 % erreichte. Das ist ein vom Anbieter gemeldetes Forschungsergebnis. Es ist relevant für NVIDIAs Argument, dass die Fähigkeiten von Agenten fortschreiten, belegt aber für sich genommen nicht, dass eine bestimmte Laufzeit in der Produktion sicher ist.

Auswirkungen für Entwickler und Enterprise-Teams

Für Entwickler legt NVIDIAs Architektur nahe, dass Sicherheitsprüfungen den Wegen folgen sollten, über die ein Agent Wirkungen auslösen kann, statt sich nur auf Prompts oder Systemnachrichten zu konzentrieren. Teams müssen identifizieren, welche Schicht die Identität verwaltet, wer Werkzeuge autorisiert, wo Zugangsdaten gespeichert werden, wie Netzwerk- und Dateisystemzugriff isoliert werden und ob ein Agent die Komponente verändern kann, die diese Entscheidungen trifft.

Der Ansatz beeinflusst auch die Wirtschaftlichkeit der Bereitstellung und den Betrieb. Eine Laufzeit, die Richtlinien konsistent über verschiedene Modelle und Harnesses hinweg anwendet, könnte es erleichtern, Komponenten auszutauschen, ohne das gesamte Sicherheitsmodell neu aufzubauen. Gleichzeitig hängt dieses Versprechen davon ab, die Grenze der Laufzeit korrekt zu definieren und zu verhindern, dass Werkzeuge, Plugins, MCP-Prozesse und Subagenten unüberwachte Nebenpfade erzeugen.

Enterprise-KI-Käufer sollten daher Nachweise für die Durchsetzung verlangen, nicht nur Listen von Schutzmaßnahmen. Wichtige Fragen sind unter anderem, ob Berechtigungen just-in-time vergeben werden, ob Richtlinien unabhängig von der Ausgabe des Agenten bewertet werden, ob Kindagenten harte Obergrenzen erben und ob jede folgenschwere Aktion so protokolliert wird, dass sie eine Untersuchung unterstützt.

Eine durch Infrastruktur erzwungene Kontrolle ist keine Garantie dafür, dass eine Richtlinie gut gestaltet oder externe Ergebnisse vorhersagbar sind. Sie macht genehmigte Richtlinien und verifizierte Konfigurationen jedoch verbindlich und reproduzierbar. Eine fehlerhafte Richtlinie kann weiterhin die falsche Handlung autorisieren, weshalb Governance und operative Überprüfung neben der technischen Isolation notwendig bleiben.

Worauf als Nächstes zu achten ist

Die nächsten Signale werden darin bestehen, ob NVIDIA OpenShell detailliertere Dokumentation, Bedrohungsmodelle, Bereitstellungsleitlinien und unabhängige Bewertungen seiner Laufzeitgarantien veröffentlicht. Entwickler sollten außerdem auf Integrationen achten, die zeigen, wie der Ansatz über verschiedene Modelle, Harnesses, Werkzeuge und Inferenzumgebungen hinweg funktioniert, statt nur innerhalb eines einzigen kontrollierten Stacks.

Weitere Belege werden zu Leistungs-Overhead, Workflows für Richtlinienverwaltung, Credential-Brokerage, Audit-Qualität und Fehlerbehandlung nötig sein. Der Markt wird zudem zeigen, ob durch Laufzeiten erzwungene Grenzen zu einer allgemeinen Anforderung für Enterprise-KI-Plattformen werden oder ob sie eine architektonische Vorliebe von Infrastruktur-Anbietern bleiben.

Creati.ai-Perspektive

NVIDIAs stärkster Beitrag in diesem Beitrag ist die Trennung zwischen Anleitung und Autorität. Ein Harness kann einem Agenten helfen, sich zu verhalten, aber eine Sicherheitsgrenze sollte nicht davon abhängen, dass der Agent zustimmt, seine eigenen Beschränkungen einzuhalten. Das ist ein nützlicher Design-Test für jedes System, das Modellen erlaubt, Werkzeuge auszuwählen oder ihre Betriebslogik zu verändern.

Die offene Frage ist die Umsetzung. Durchsetzung zur Laufzeit kann den Schaden durch Agentenfehler begrenzen, muss aber unabhängig getestet, korrekt konfiguriert und breit genug sein, um jeden relevanten Wirkungspfad abzudecken. Für KI-Entwickler und Enterprise-Teams ist die Botschaft konkret: Behandeln Sie Prompts und Harnesses als Kontrollflächen, nicht als letzte Verteidigungslinie.