SAP und NVIDIA konkretisieren die technische Absicherung autonomer KI-Agenten

SAP hatte die Richtung bereits im Mai vorgegeben: KI-Agenten sollen künftig tiefer in Geschäftsprozesse eingreifen, aber nicht ohne kontrollierte Laufzeitumgebung. Mit der am 28. September vorgestellten NVIDIA Open Agent Safety Platform bekommt dieser Ansatz nun eine technisch greifbarere Basis. OpenShell, die quelloffene Runtime-Komponente der Plattform, ist laut NVIDIA breit verfügbar. SAP bettet OpenShell in die SAP Business AI Platform ein und arbeitet gemeinsam mit NVIDIA an der Härtung für Enterprise- und regulierte Szenarien.

Damit bekommt die Sicherheit von KI-Agenten eine zusätzliche Ebene: Neben fachlichen Berechtigungen tritt eine technische Grenze für die tatsächliche Ausführung. Sobald Agenten Daten lesen, Systeme ansprechen und Aktionen ausführen, müssen Unternehmen nicht nur definieren, was ein Agent tun darf. Sie müssen technisch erzwingen können, welche Ressourcen, Modelle, Daten und Werkzeuge er tatsächlich erreichen kann – und nachvollziehen können, was er im Betrieb getan hat.

Fachliche Erlaubnis und technische Durchsetzbarkeit

Die zentrale Unterscheidung lässt sich aus Anwendersicht auf zwei Fragen verdichten: Darf der Agent eine Aktion fachlich ausführen? Und kann er technisch tatsächlich nur das tun, was erlaubt wurde? SAP ordnet diese Aufgaben unterschiedlichen Kontrollschichten zu.

Der SAP AI Agent Hub ergänzt diese Architektur als Governance-Baustein für AI Assets. Seine konkrete Rolle im Zusammenspiel mit OpenShell sollte jedoch getrennt von der aktuell von SAP und NVIDIA beschriebenen Runtime-Architektur betrachtet werden.

Warum OpenShell für SAP-Anwender relevant ist

Bei agentischer KI ist die Sicherheitslogik anspruchsvoller als bei klassischen Anwendungen: Ein Agent kann Werkzeuge kombinieren, Zwischenschritte selbst wählen und in mehreren Systemen handeln. Welche neuen Governance-Fragen dadurch entstehen, haben wir bereits am Beispiel von Agentic AI in SAP-Geschäftsprozessen eingeordnet. NVIDIA setzt deshalb auf eine zusätzliche Laufzeitgrenze außerhalb des Agentenmodells. OpenShell soll Richtlinien während der Ausführung durchsetzen und Agenten in isolierten Umgebungen betreiben.

SAP beschreibt die eigene Rolle eine Ebene darüber: Die Joule Studio Runtime soll Geschäftsrollen, Berechtigungen, Freigaben und Prozesskontext berücksichtigen, bevor eine Aktion ausgeführt wird. OpenShell kontrolliert anschließend die technische Ausführung. Für Unternehmen entsteht damit eine Trennung zwischen der Frage „Darf der Agent das fachlich?“ und „Kann der Agent technisch nur das tun, was erlaubt wurde?“

Gerade in Finance, HR, Beschaffung oder Supply Chain ist diese Trennung relevant. Dort können Agenten nicht nur Informationen aufbereiten, sondern Buchungen vorbereiten, Bestellungen auslösen, Daten verändern oder Entscheidungen anstoßen. Mit wachsender Autonomie steigt deshalb die Bedeutung von Minimalrechten, nachvollziehbaren Freigaben, Audit-Trails und technischen Grenzen außerhalb des Agenten selbst.

Was tatsächlich verfügbar ist – und was noch nicht

Die Produktstände müssen sauber getrennt werden. NVIDIA bezeichnet OpenShell seit dem 28. September als breit verfügbar. SAP sagt zugleich, eigene Entwickler arbeiteten an OpenShell mit und die Laufzeit werde in die SAP Business AI Platform eingebettet. Die weitergehende Verbindung von OpenShell-Isolation mit SAP-Autorisierungsmodellen, IAM und Audit-Trails beschreibt SAP jedoch als laufende Arbeit.

Auch NVIDIA Sentry ist noch kein fertiger SAP-Baustein. NVIDIA stellt Sentry derzeit als Referenz-Systemdesign vor, das auf BlueField-4-DPUs außerhalb der eigentlichen Agentenlaufzeit überwachen soll. Für CIOs und Security-Verantwortliche ist deshalb entscheidend, „OpenShell eingebettet“ nicht mit einer vollständig produktionsreifen End-to-End-Sicherheitsarchitektur gleichzusetzen.

Verfügbarkeit, Betriebsmodell, unterstützte Infrastrukturen und die tatsächliche Verzahnung mit SAP-IAM, Governance- und Audit-Prozessen müssen für den jeweiligen Einsatzfall geprüft werden.

Die eigentliche Architekturfrage: Wer kontrolliert den KI-Agenten?

Mit der neuen Sicherheitsarchitektur wird adressiert, dass Agentic AI eine zusätzliche Kontrollschicht zwischen Fachprozess und Infrastruktur benötigt. Für SAP-Anwender verschiebt sich damit auch die Governance-Diskussion: Nicht nur der Agent selbst muss bewertet werden, sondern die gesamte Kette aus Identität, Berechtigung, Tool-Zugriff, Modellaufruf, Datenzugriff, Laufzeit und Protokollierung. Mit wachsender Autonomie wird deshalb auch die Frage wichtiger, wie Unternehmen Vertrauen und Kontrolle im Autonomous Enterprise organisieren.

Das ist besonders relevant in heterogenen Landschaften. OpenShell ist Open Source und NVIDIA positioniert die Plattform für ein breites Ökosystem. Damit zeichnet sich zumindest technisch die Möglichkeit ab, Sicherheitsprinzipien über SAP- und Nicht-SAP-Agenten hinweg zu vereinheitlichen. Ob daraus in der Praxis eine konsistente, herstellerübergreifende Governance entsteht, ist derzeit offen und hängt davon ab, wie tief sich die einzelnen Laufzeiten und Berechtigungssysteme integrieren lassen.

Welche Fragen Unternehmen jetzt klären sollten

• Welche Agenten dürfen produktiv handeln – und welche bleiben auf Assistenz oder Vorschläge begrenzt?
• Wo werden Identitäten, Rollen und Minimalrechte für Agenten verwaltet?
• Welche Daten, APIs, MCP-Server und Tools darf ein Agent technisch erreichen?
• Wie werden Aktionen, Freigaben und Regelverletzungen revisionssicher protokolliert?
• Wie greifen Joule Studio Runtime, OpenShell sowie die Governance- und Audit-Komponenten im eigenen Zielbild zusammen?
• Welche Komponenten sind produktiv verfügbar, welche befinden sich noch in Entwicklung oder Referenzstatus?
• Mit welchem Verbrauchs- und Kostenmodell müssen Unternehmen für den produktiven Betrieb eigener Agenten nach Auslaufen der kostenlosen Phase Ende 2026 rechnen?

SAP nennt für die produktive Joule Studio Runtime derzeit eine kostenlose Phase bis Ende 2026. Für die Zeit danach beschreibt SAP ein verbrauchsabhängiges Modell. Für Budget- und Rolloutentscheidungen wird deshalb relevant, welche Compute-, Storage-, Transaktions- und AI-Token-Verbräuche im konkreten Agentenszenario entstehen.

Noch keine vollständige Enterprise-Sicherheitsarchitektur

SAP konkretisiert einen bislang eher abstrakten Teil seiner Autonomous-Enterprise-Strategie: Autonomie soll nicht allein über fachliche Governance kontrolliert werden, sondern zusätzlich über eine technische Laufzeitgrenze außerhalb des Agenten selbst. Das ist ein plausibler Schritt, weil Agenten mit wachsender Handlungsmacht auch neue Angriffs- und Fehlerszenarien erzeugen. „Je autonomer KI-Agenten handeln, desto weniger darf ihre Sicherheit nur vom Agenten selbst abhängen. SAP-Anwenderunternehmen sollten deshalb prüfen, ob sich fachliche Berechtigungen, technische Laufzeitgrenzen und unabhängiges Monitoring zu einer tatsächlich durchsetzbaren Kontrollarchitektur verbinden lassen“, kommentiert ITOM-Chefredakteurin Maike Rose.

Noch wird daraus jedoch keine vollständig belegte Enterprise-Sicherheitsarchitektur. OpenShell ist verfügbar, die SAP-Integration und die Verbindung zu Unternehmensberechtigungen werden weiterentwickelt, Sentry ist ein Referenzdesign. Für Anwender zählt deshalb weniger das Sicherheitsversprechen als die Frage, welche Kontrollen heute tatsächlich produktiv und auditierbar durchgesetzt werden können.