NVIDIA: KI-Sicherheit ist ein Ingenieurproblem, lösbar mit prüfbaren Kontrollen in jeder Schicht des Agenten-Stacks
In einem Beitrag im NVIDIA-Blog argumentiert Saša Zdjelar, KI-Sicherheit sei ein Ingenieurproblem. Es braucht definierte Sicherheitsanforderungen, durchsetzbare Kontrollen, benannte Verantwortliche und Belege, dass der Schutz wirkt. Der Beitrag teilt einen KI-Agenten in drei Schichten: das Modell, das Harness für Kontext, Werkzeuge und Abläufe sowie die Laufzeitumgebung, in der Aktionen laufen. Jede Schicht braucht eigene Kontrollen. Eine Sicherheitsgrenze muss auch dann halten, wenn der Agent falsch entscheidet. Vorgestellt werden die offene Laufzeit NVIDIA OpenShell und Werkzeuge von Partnern wie Cisco, JFrog, CrowdStrike und Palo Alto Networks.
Am 21. September 2026 veröffentlichte NVIDIA in seinem Blog einen Beitrag von Saša Zdjelar mit einem klaren Titel: KI-Sicherheit ist ein Ingenieurproblem. Die zentrale Aussage lautet, dass Sicherheit nicht bei Schlagworten und Prompts stehen bleiben darf. Sie muss zu definierten Sicherheitsanforderungen, durchsetzbaren Kontrollen, benannten Verantwortlichen und Belegen werden, dass der Schutz wirkt. Mit wachsender Leistungsfähigkeit der KI müsse die Branche die Sicherheitstechnik beschleunigen, den Zugang zu Verteidigungswerkzeugen erweitern und schneller teilen, was funktioniert. Der Beitrag beginnt mit einer einfachen Tatsache: Technik ändert sich, die Grundlagen der Sicherheit bleiben. Internet und Cloud haben verändert, wie Software arbeitet. Die Kernpflichten blieben gleich: Identität feststellen, Zugriff steuern, Angriffsfläche begrenzen und prüfen, dass der Schutz wirkt. KI-Agenten bringen neue Fähigkeiten mit. Sie schlussfolgern, nutzen Werkzeuge und passen ihre Aktionen an die Daten an, auf die sie stoßen. Diese Fähigkeiten heben die alten Prinzipien nicht auf. Sie verlangen, dass man die Prinzipien unter neuen Betriebsbedingungen anwendet. Der Beitrag ist ehrlich über den Druck: Organisationen wollen die Produktivität der KI, während die Praxis, solche Systeme zu steuern und zu schützen, noch entsteht.
Der Schlüssel zum ganzen Text ist die Sicht auf den gesamten Stack. Anwendungen hängen von Code, Daten, Identitäten, Diensten und Infrastruktur ab, und Sicherheit hängt davon ab, wie diese Teile zusammenspielen. KI-Agenten erweitern dieses System. Der Beitrag teilt einen Agenten in drei Schichten. Modelle liefern Fähigkeiten. Harnesses ordnen Kontext, Werkzeuge und Abläufe. Laufzeitumgebungen stellen die Infrastruktur bereit, in der Aktionen ausgeführt werden. Jede Schicht trägt Sicherheitspflichten, und Kontrollen sind auf allen Ebenen nötig, weil Daten, Anweisungen und Aktionen durch das ganze System laufen. Keine einzelne Schicht kann alles auffangen. Der Beitrag macht das an einem Szenario greifbar. Ein Agent aktualisiert einen Kundendatensatz. In einem angehängten Dokument stößt er auf bösartige Anweisungen und versucht, Kundendaten an ein nicht autorisiertes Ziel zu exportieren. Eine Netzwerkrichtlinie soll den Transfer blockieren. Geschützte Protokolle sollen den versuchten Werkzeugaufruf, die Autorisierungsentscheidung und das Ergebnis festhalten, damit das Sicherheitsteam erkennt, welches Werkzeug benutzt wurde und welches Ziel der Agent erreichen wollte. Dann folgt die Frage der Feinheit von Berechtigungen: Das Recht, einen Kundendatensatz zu ändern, darf nicht automatisch das Recht einschließen, diese Daten zu exportieren. Ein Agent kann zusätzlichen Zugriff anfordern, ihn aber nicht selbst genehmigen.
Daraus folgt der stärkste Satz des Beitrags: Eine Sicherheitsgrenze muss auch dann halten, wenn ein Agent falsch entscheidet. Grenzen dürfen also nicht vom Urteil des Agenten abhängen. Die Umgebung, in der der Agent läuft, muss Dateien, Netzwerkziele und Prozesse unabhängig von seinem Denken begrenzen. Anweisungen und Schutzmaßnahmen können das Verhalten lenken, doch Sicherheit braucht zusätzlich durchsetzbare Grenzen. Der Beitrag nennt mehrere technische Anforderungen. Jeder Agent braucht eine nachvollziehbare Identität und Zugangsdaten, die auf seine Aufgabe beschränkt sind. Organisationen brauchen klare Richtlinien dazu, auf welche Informationen Agenten zugreifen, welche Systeme sie ändern und welche Aktionen eine Freigabe verlangen. Folgenreiche Aktionen und Berechtigungsänderungen erfordern weiterhin menschliche Freigabe. Teams müssen außerdem Herkunft und Integrität der Werkzeuge, Fähigkeiten und Abhängigkeiten prüfen, die Agenten nutzen. Auch der Tag nach einem Vorfall wird behandelt. Geschützte Aufzeichnungen von Werkzeugaufrufen, Autorisierungsentscheidungen und Ergebnissen helfen Ermittlern, das Geschehen zu rekonstruieren. Klare Verfahren zum Entziehen von Zugriff und zum Eindämmen von Vorfällen machen diese Belege handlungsfähig. Protokolle sind dazu da, die Reaktion auf Fakten zu stützen. Auf Produktseite verweist NVIDIA auf NVIDIA OpenShell, eine offene, sichere Laufzeit. Sie setzt Richtlinien außerhalb der Reichweite des Agenten durch, bietet eine Ausführung in einer Sandbox und steuert, wie Agenten auf Daten, Netzwerk und Systemressourcen zugreifen. Laut Beitrag bauen Partner der Open Secure AI Alliance auf OpenShell auf. Ciscos DefenseClaw ergänzt eine Governance-Schicht. JFrog integriert sich mit OpenShell, um Fähigkeiten von Agenten zu prüfen und zu verifizieren und Richtlinien dazu durchzusetzen, welche Fähigkeiten Agenten nutzen dürfen. Das zweite Hauptthema sind Belege. Vor dem Einsatz brauchen Teams den Nachweis, dass Kontrollen Versuche blockieren, Zugangsdaten außerhalb des Agentenbereichs zu erlangen oder sensible Daten an ein nicht autorisiertes Ziel zu senden. Tests sollen auch Versuche abdecken, Berechtigungen zu ändern oder die Überwachung zu stören, und sie werden nach wesentlichen Änderungen an Modellen, Werkzeugen oder Abläufen wiederholt. Ein benannter Verantwortlicher entscheidet anhand der Ergebnisse, ob das System bereit ist, und sorgt dafür, dass fehlgeschlagene Tests zu Korrekturen führen. Fehler aus Test oder Betrieb werden reproduziert, untersucht und behoben. Jeder Befund wird zu einem wiederholbaren Test, mit dem sich prüfen lässt, dass die Korrektur auch in künftigen Versionen hält. Der Beitrag nennt CrowdStrike SafeMind, das Abwehr durch wiederholte Angriffssimulationen testet und stärkt, und Palo Alto Networks Prisma AIRS für kontinuierliches Red Teaming, während sich Modelle und Anwendungen ändern.
Das dritte Thema sind die Werkzeuge der Verteidiger. Wer Fehler untersucht, braucht leistungsfähige Werkzeuge, die zu Aufgabe, Daten und Umgebung passen. Laut Beitrag decken offene und geschlossene Modelle einander ergänzende Bedürfnisse ab. Geschlossene Modelle bieten verwaltete Fähigkeiten und Dienste. Offene Modelle erlauben Verteidigern, relevante Komponenten zu untersuchen, Strategien anzupassen und auf Infrastruktur zu arbeiten, die sie selbst kontrollieren. Bei einem Vorfall hilft diese Kontrolle, einen Fehler zu reproduzieren, eine Korrektur an den eigenen Systemen zu testen und sensible Belege in der eigenen Umgebung zu behalten. Leistungsfähige KI kann helfen, Schwachstellen zu finden, Korrekturen zu validieren und Angriffe zu untersuchen. Ihr Wert sollte an reproduzierbaren Befunden, überprüfbaren Korrekturen und schnellerer Reaktion gemessen werden. Beispiele sind Capital Ones VulnHunter für KI-gestützte Codesicherheit und ReversingLabs Spectra Assure für die KI-gestützte Analyse von Softwarepaketen, um Schadsoftware und Manipulation zu erkennen. Der Schlussabschnitt, der den Vorteil durch offene Zusammenarbeit zu den Verteidigern verschieben will, wirbt dafür, Belege zu teilen, was gescheitert ist und welche Kontrollen wirkten. Der uns vorliegende Quellenauszug bricht dort mitten im Satz ab, deshalb gehen wir auf diesen Teil nicht weiter ein.
Ein Vorbehalt ist wichtig. Der Beitrag ist ein Rahmen- und Positionstext. Er nennt keine Leistungs-Benchmarks, keine Kosten und keine gemessene Risikoreduktion, daher lässt sich aus dem Text nicht beurteilen, wie stark die Maßnahmen helfen. Was folgt, ist unsere Analyse, keine Aussage der Quelle. Für Entwickler lautet die direkteste Lehre, Berechtigungsmodell und Isolation außerhalb des Agenten anzusiedeln: eine eigene Identität und Zugangsdaten mit geringsten Rechten für jeden Agenten, und Netzwerk- und Dateigrenzen, die die Laufzeit durchsetzt, nicht der Systemprompt. Für Unternehmen heißt das, für jeden Agenteneinsatz einen Verantwortlichen zu benennen, bestandene Red-Team-Tests zur Freigabebedingung zu machen und jeden Vorfall in einen Regressionstest zu verwandeln. Für das Ökosystem zeigt das Bild aus OpenShell und Partnern eine Arbeitsteilung: Die Laufzeit erzwingt, während Governance-Schichten, Lieferkettenprüfung und kontinuierliches Red Teaming die übrigen Rollen füllen. Die Herausforderungen sind klar. Erstens müssen Richtlinien fein genug sein, um das Ändern zu erlauben, den Export aber nicht, und feine Richtlinien kosten Pflegeaufwand. Zweitens bleibt das Lieferkettenrisiko: Die Herkunftsprüfung von Fähigkeiten und Abhängigkeiten braucht gemeinsame Standards im Ökosystem. Drittens bedeutet kontinuierliches Testen laufende Kosten, und der Beitrag sagt nicht, wer sie trägt. Viertens stammt der Beitrag von einem Anbieter, der verwandte Plattformen verkauft, und Leser sollten den Rahmen an ihrer eigenen Umgebung prüfen. Dennoch ist es eine Richtung, die der ganzen Branche nützt, Sicherheit als überprüfbare, zurechenbare Ingenieurarbeit zu verstehen und nicht als einmaliges Versprechen.