NVIDIA skizziert einen Sicherheits-Stack für KI-Agenten

NVIDIA hat kürzlich klargestellt: Die Sicherheit von KI-Agenten lässt sich nicht dadurch lösen, dass ein Modell einfach „gründlicher nachdenkt". Das Unternehmen betrachtet dieses Thema als reines Engineering-Problem, das vier Dinge zugleich erfordert: klar definierte Sicherheitsanforderungen, durchsetzbare Kontrollen, einen benannten Verantwortlichen für jede Kontrolle und den Nachweis, dass diese Schutzmaßnahmen in der Praxis tatsächlich funktionieren.

Auf Basis realer Agenten-Einsätze nennt NVIDIA fünf wiederkehrende Sicherheitsprobleme. Erstens unautorisierter Datenzugriff: Ein Agent stößt auf bösartige Anweisungen, die in einem Dokument versteckt sind, und versucht daraufhin, Kundendaten an ein nicht autorisiertes Ziel zu exportieren. Zweitens Privilegieneskalation: Der Agent erlangt Berechtigungen, die über die ihm zugewiesene Aufgabe hinausgehen. Drittens Umgehung der Zugriffskontrolle: Der Agent versucht, Zugangsdaten außerhalb seines eigentlichen Berechtigungsbereichs zu erhalten. Viertens Störung der Überwachung: Versuche, Berechtigungen zu ändern oder die Sicherheitsüberwachung selbst zu stören. Fünftens Probleme mit der Integrität von Werkzeugen: kompromittierte oder manipulierte Skills oder Abhängigkeiten, auf die sich der Agent verlässt.

Nicht nur das Modell, sondern der gesamte Stack

NVIDIA strukturiert das Problem in drei Schichten. Die Modellschicht liefert die grundlegende Denkfähigkeit. Die Harness-Schicht organisiert Kontext, Werkzeuge und Arbeitsabläufe. Die Laufzeitumgebung schließlich ist die Infrastruktur, die die Aktionen des Agenten tatsächlich ausführt. Keine dieser drei Schichten ist für sich allein ausreichend sicher — das gesamte Gefüge hängt zudem davon ab, dass Code, Daten, Identitäten, Dienste und Infrastruktur korrekt zusammenwirken.

Das konkrete Beispiel von NVIDIA sieht so aus: Ein Agent, der Kundendatensätze aktualisiert, stößt auf bösartige Anweisungen, die in einem angehängten Dokument versteckt sind, und versucht, Daten ohne Genehmigung zu exportieren. In NVIDIAs Konzept blockiert eine Netzwerkrichtlinie außerhalb der eigenen Entscheidungsschleife des Agenten diese Übertragung, während ein geschütztes Audit-Log den Versuch für eine spätere Untersuchung festhält. Um dieses Beispiel herum listet NVIDIA fünf Anforderungen auf, die für jeden Agenten-Einsatz notwendig sind: durchsetzbare Grenzen, die unabhängig von der Entscheidung des Agenten gelten; eine individuelle Identität für jeden Agenten, die nur die für seine Aufgabe erforderlichen Zugangsdaten trägt; klare Richtlinien, die festlegen, auf welche Informationen ein Agent zugreifen und welche Aktionen er genehmigen darf; geschützte Audit-Logs für jeden Werkzeugaufruf und jede Autorisierungsentscheidung; und eine verpflichtende menschliche Freigabe, bevor ein Agent eine Handlung mit erheblichen Folgen ausführt.

Warum die Durchsetzung außerhalb des Agenten sitzen muss

[Analyse] Der rote Faden in NVIDIAs Rahmenwerk ist, dass eine Kontrolle nur dann zählt, wenn der Agent sie nicht durch eigenes Schlussfolgern umgehen kann. Das ist eine grundlegend andere Haltung, als darauf zu hoffen, dass ein Modell „es besser weiß" — sie behandelt das Modell so, wie eine Zero-Trust-Netzwerkarchitektur ein Client-Gerät behandelt: standardmäßig nicht vertrauenswürdig, und niemals selbst die Instanz, die seine eigene Grenze durchsetzt. Im Beispiel mit den Kundendatensätzen war es nicht das Urteil des Modells, das den Exfiltrationsversuch stoppte, sondern die Netzwerkrichtlinie. Das deckt sich mit einer Lehre, die die traditionelle Anwendungssicherheit schon vor Jahrzehnten bei Browsern und Endgeräten gelernt hat: Der Durchsetzungspunkt muss dort liegen, wo eine kompromittierte Komponente ihn nicht erreichen kann — sei es eine Firewall, eine IAM-Schicht (Identity and Access Management) oder, wie bei NVIDIA OpenShell, eine Richtlinienschicht, die die Ausführungsumgebung des Agenten umschließt.

[Analyse] Die von NVIDIA genannte Liste von Werkzeugen liest sich weniger wie ein Produktkatalog als wie eine Arbeitsteilung über den gesamten Stack hinweg. NVIDIAs eigenes OpenShell liefert die Durchsetzungs-Laufzeitumgebung. Cisco DefenseClaw fügt darüber eine Governance-Schicht hinzu. JFrog scannt und verifiziert die Skills eines Agenten, bevor sie ausgeführt werden dürfen. Spectra Assure von ReversingLabs und VulnHunter von Capital One gehen das Problem der Lieferkette und der Code-Integrität aus zwei verschiedenen Richtungen an: Malware-Erkennung in Softwarepaketen auf der einen Seite, KI-gestütztes Scannen der Codesicherheit auf der anderen. CrowdStrike SafeMind und Prisma AIRS von Palo Alto Networks wiederum validieren aus der Angreiferperspektive, indem sie Verteidigungsmaßnahmen durch Angriffssimulationen und kontinuierliches Red-Teaming testen. Kein einziger Anbieter auf dieser Liste deckt den gesamten Stack ab, und genau das ist vermutlich der Punkt: Eine Referenzarchitektur, an die sich verschiedene Spezialisten anschließen können, ist beständiger als ein einzelnes Unternehmen, das eine Ende-zu-Ende-Lösung verspricht — denn Agentensicherheit erstreckt sich über Identität, Code, Laufzeit und Überwachung, Bereiche, die traditionell von unterschiedlichen Teams verantwortet werden.

[Analyse] Für ein Unternehmen, das heute Agenten einsetzt, ist der praktische Ausgangspunkt, den NVIDIAs eigene Liste nahelegt, ein Audit und kein Einkauf. Verfügt jeder Agent über eine eigene, eingeschränkte Identität statt über gemeinsam genutzte Dienstanmeldedaten? Gibt es ein Richtliniendokument — nicht nur einen System-Prompt —, das festlegt, was jeder Agent berühren darf? Werden Werkzeugaufrufe und Autorisierungsentscheidungen an einem Ort protokolliert, den der Agent selbst nicht verändern kann? Und gibt es einen Menschen in der Schleife, bevor eine Aktion ausgeführt wird, die sich nicht ohne Weiteres rückgängig machen lässt? Diese vier Fragen entsprechen direkt den fünf von NVIDIA genannten Anforderungen und lassen sich prüfen, ohne eines der genannten Drittanbieterprodukte einzuführen.