These: Ohne Execution-Boundary kein Enterprise-Agent – SAP bettet NVIDIA OpenShell ein

Agenten scheitern nicht am Prompt. Sie scheitern am fehlenden Execution-Boundary. Das ist die These dieses Textes, und sie erklärt, warum SAP am 28. September 2026 eine Ankündigung veröffentlicht hat, die auf den ersten Blick nach reiner Infrastruktur-Pflege aussieht, aber bei genauem Lesen etwas anderes ist: ein Eingeständnis, dass Autorisierung allein nicht reicht, um Agenten in produktiven Enterprise-Systemen laufen zu lassen.

SAP bettet NVIDIA OpenShell in die SAP Business AI Platform ein. Klingt nach einer weiteren Partnermeldung. Ist es aber nicht, wenn man sich ansieht, was da eigentlich zusammengeführt wird: Joule Studio als AI-first Development Environment mit Execution- und Governance-Stack auf der einen Seite, OpenShell als Open-Source Secure Runtime auf der anderen. Zwei Systeme, die bislang getrennt liefen, weil sie unterschiedliche Fragen beantworten. Die eine Frage: Darf dieser Agent das? Die andere Frage: Was passiert konkret, wenn er es tut?

Das Problem mit AuthZ ohne Sandbox

Seien wir ehrlich: Die meisten Enterprise-Agent-Projekte, die aktuell durch Konzerne rollen, haben ein Autorisierungsmodell. Sie haben Rollen, sie haben Rechte, sie haben irgendeine Form von Identity- und Access-Management, das entscheidet, ob ein Nutzender oder ein Agent im Namen eines Nutzenden eine Aktion anstoßen darf. Das ist die AuthZ-Seite. Sie beantwortet das Ob.

Was in den meisten Aufbauten fehlt, ist die zweite Hälfte: die Kontrolle darüber, wie eine Ausführung konkret abläuft, sobald die Berechtigung erteilt ist. Welche Dateisysteme sieht der Agent? Welche Prozesse darf er starten? Wohin geht die Inferenz-Anfrage, wenn das Modell im Hintergrund eine externe Ressource anspricht? Das ist die Containment-Seite. Sie beantwortet das Wie und das Wohin.

Genau. Diese Trennung ist kein akademisches Detail, sondern der Kern des Problems, das aktuell fast jede Enterprise-Agent-Initiative bremst oder in Audit-Schwierigkeiten bringt. Ein Rollenmodell sagt nichts darüber aus, was ein Agent tut, sobald er innerhalb seiner Berechtigung agiert. Ein Agent mit legitimer Berechtigung, auf ein ERP-System zuzugreifen, kann innerhalb dieser Berechtigung trotzdem Dinge tun, die niemand vorhergesehen hat: ungewollte Netzwerkverbindungen, Zugriffe auf Datenbereiche, die zwar formal erlaubt, aber fachlich nie gemeint waren, oder schlicht ein Verhalten, das sich der Beobachtung entzieht, weil es keine strukturierte Protokollierung auf Ausführungsebene gibt.

Falsch verstanden wird das oft als reines Sicherheitsproblem. Ist es nicht nur. Es ist ein Kontrollproblem. Wer Agenten skaliert, ohne die Ausführungsebene zu kontrollieren, produziert nicht Autonomie. Er produziert Sprawl mit Audit-Lücke – viele Agenten, viele Berechtigungen, aber keine belastbare Antwort auf die Frage, was im Ernstfall tatsächlich passiert ist.

Was SAP und NVIDIA konkret zusammenführen

Laut Ankündigung von Andre Lamego, SVP und Chief Product Officer für die SAP Business AI Platform Fabric, geht es SAP genau um diese Lücke. Die Integration von OpenShell in Joule Studio soll die Ausführungsisolation von OpenShell mit der Business-Governance von Joule Studio verbinden – also AuthZ, Identity- und Access-Management sowie Audit-Funktionen mit einer Runtime, die auf Prozess- und Netzwerkebene tatsächlich durchsetzt, was passieren darf.

Bemerkenswert ist dabei nicht nur die Integration selbst, sondern die Art der Zusammenarbeit. SAP-Engineers committen laut Unternehmensangaben direkt in die OpenShell-Codebase. Das ist kein reines Zukauf-und-Einbau-Modell, sondern Co-Development in einem Open-Source-Projekt. Wenn ein Unternehmen wie SAP eigene Entwicklungsressourcen in den Quellcode einer fremden Sicherheits-Runtime steckt, ist das ein anderes Commitment als ein API-Wrapper um ein Partnerprodukt. Es bedeutet: SAP verlässt sich nicht darauf, dass NVIDIA die Härtung für regulierte Branchen allein liefert, sondern bringt eigene Anforderungen aus jahrzehntelanger Enterprise-Erfahrung direkt in die Architektur ein.

Zu den SAP-Beiträgen zählen laut der Ankündigung unter anderem die Zerlegung von Supervisor- und Agent-Execution-Komponenten, Kubernetes-native Betriebsmodelle, eine Verkleinerung des Gateway-Image-Footprints sowie Supervisor-Health-Monitoring mit strukturierten Logs. Das sind keine Marketing-Schlagworte, sondern Betriebsanforderungen, die jedes Team kennt, das produktive Kubernetes-Cluster in regulierten Umgebungen betreibt. Ein kleineres Image bedeutet weniger Angriffsfläche und schnellere Deployment-Zyklen. Strukturierte Logs bedeuten, dass ein Audit-Team tatsächlich nachvollziehen kann, was ein Supervisor-Prozess wann entschieden hat – statt sich durch unstrukturierte Textausgaben zu wühlen.

Wer tiefer in die technischen Details einsteigen will, findet die vollständige Ankündigung direkt bei SAP News Center. Die Gegenseite der Geschichte, geschrieben von Alex Watson und Ali Golshan, liefert der NVIDIA Developer Blog.

Der Joule-Split: Business-Autorisierung trifft Runtime-Containment

Der eigentliche Kern der Ankündigung ist eine architektonische Trennung, die SAP als Split bezeichnet – und die man verstehen muss, um die These dieses Textes einzuordnen. Joule Studio Runtime entscheidet, ob eine Aktion überhaupt ausgeführt werden darf. Das passiert auf Basis von Business-Autorisierung, RBAC-Regeln und Prozesskontext, bevor die Anfrage die eigentliche Ausführungs-Runtime erreicht. Es ist die klassische Governance-Schicht, angesiedelt auf Ebene des Geschäftsprozesses: Darf diese Rolle in diesem Kontext diese Aktion anstoßen?

OpenShell übernimmt danach die zweite Hälfte. Es steuert, wie der Agent ausführt, was er sehen und tun darf, und wohin Inferenz-Anfragen tatsächlich gehen. Das ist Containment auf technischer Ebene, unabhängig davon, ob die Business-Autorisierung schon vorher „Ja“ gesagt hat. Genau diese Zweiteilung ist der Punkt, an dem die meisten aktuellen Agent-Architekturen brechen. Viele Systeme behandeln Autorisierung und Ausführung als eine Einheit – wer einmal die Berechtigung hat, bekommt implizit auch die volle technische Handlungsfreiheit innerhalb dieser Berechtigung. SAP und NVIDIA trennen das bewusst.

Warum ist das wichtig? Weil eine Berechtigung auf Prozessebene nie granular genug sein kann, um jede mögliche technische Ausführung vorherzusehen. Ein Agent, der berechtigt ist, Bestelldaten zu lesen und Freigaben vorzuschlagen, kann technisch trotzdem Dutzende Wege finden, diese Berechtigung zu nutzen – manche davon gewollt, manche nicht. Die Business-Ebene kann das Ob regeln. Sie kann nicht in Echtzeit das Wie regeln, ohne dass die Ausführungsebene selbst über eine eigene Kontrollinstanz verfügt.

Diese Denkweise deckt sich mit dem, was wir bei digital-magazin.de in der Debatte um EU-Regulierung und Enforcement schon länger beobachten: Regeln auf dem Papier – oder auf Prozessebene – lösen kein Kontrollproblem, wenn die Durchsetzung auf technischer Ebene fehlt. Wer sich mit der Frage beschäftigt, wie Aufsichtsstrukturen tatsächlich greifen sollen, findet dazu einen passenden Hintergrund in unserem Beitrag zu Enforcement-Kompetenz bei KI-Aufsichtsgremien. Das Muster ist dasselbe: Governance-Vorgaben ohne technische Durchsetzungsschicht bleiben Absichtserklärungen.

OpenShell im Detail: Gateway, Supervisor, Sandbox

Um zu verstehen, was OpenShell technisch tatsächlich leistet, lohnt sich ein Blick auf die drei Kernkomponenten, die NVIDIA im eigenen Developer-Blog beschreibt. OpenShell 0.1.0 ist als Open-Source-Runtime konzipiert, die drei Aufgaben übernimmt: sandboxed Execution, kontrollierten Service-Zugriff und Credential-Management mit dem Anspruch formaler Policy-Analyse.

Das Gateway übernimmt Lifecycle-Management und Policy-Durchsetzung auf oberster Ebene. Es entscheidet, welche Policies für welche Agenten-Session gelten, und verwaltet den gesamten Lebenszyklus einer Ausführungsumgebung – vom Start bis zum kontrollierten Beenden. Der Supervisor läuft außerhalb der eigentlichen Agent-Workload und prüft jede ausgehende Anfrage gegen die geltende Policy. Das ist ein entscheidendes Architekturdetail: Die Kontrollinstanz sitzt nicht innerhalb des Agent-Prozesses, sondern daneben. Ein Agent, der versucht, seine eigene Kontrolle zu manipulieren, kommt gar nicht an den Supervisor heran, weil dieser als separater Prozess läuft.

Die Sandbox selbst setzt auf Kernel-Ebene an. Datei- und Prozesskontrollen laufen auf dieser Schicht, Netzwerkzugriffe sind ausschließlich über den Supervisor möglich. Ein Agent kann also nicht einfach eine eigene Netzwerkverbindung öffnen und an der Kontrollschicht vorbei kommunizieren. Jeder Ausgang muss durch die Instanz, die die Policy kennt und durchsetzt.

Ergänzt wird das durch Credential Binding: Die tatsächlichen Zugangsdaten liegen außerhalb der Agent-Workload und werden nur bei autorisierten Requests eingesetzt. Der Agent selbst sieht die echten Credentials nie. Das reduziert das Risiko, dass ein kompromittierter oder fehlgeleiteter Agent Zugangsdaten abgreifen und außerhalb des vorgesehenen Kontexts nutzen kann.

Zusätzlich behauptet NVIDIA eine Policy-Prover-Funktion mit formaler Verifikation – also die Möglichkeit, Policies nicht nur zur Laufzeit zu prüfen, sondern vorab formal zu verifizieren, dass sie das tun, was sie sollen. Ergänzt wird das durch einen OCSF-basierten Audit-Trail (Open Cybersecurity Schema Framework) sowie Inspektionsmöglichkeiten für MCP-, HTTP- und GraphQL-Verkehr. OpenShell ist damit laut NVIDIA Teil der breiter angelegten NVIDIA Open Agent Safety Platform.

Wichtig an dieser Stelle: Diese Funktionen sind Herstellerangaben. Formale Verifikation, FedRAMP- und FIPS-Roadmaps oder die Behauptung, Permissions würden vollständig außerhalb der Workload durchgesetzt, sind Aussagen der beteiligten Unternehmen, keine unabhängig geprüften Zertifizierungen. Wer produktiv damit arbeitet, sollte diese Behauptungen im eigenen Audit-Prozess verifizieren, nicht als gegeben hinnehmen. Genau hier schließt sich der Kreis zu einem Thema, das wir bereits ausführlich behandelt haben: Wie Drittanbieter-Bewertungen bei KI-Systemen funktionieren sollten, beschreiben wir in unserem Beitrag zu unabhängigen Third-Party-Assessments.

Warum Co-Development kein reiner Marketing-Move ist

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptDesk with authz vs sandbox sticky notes soft light photorealistic no logos no readable text 16:9

Man könnte einwenden: Jede Partnerschaft zwischen zwei großen Techkonzernen wird als strategisch verkauft. Das stimmt. Aber der Unterschied zwischen einer reinen Vermarktungspartnerschaft und echtem Co-Development zeigt sich nicht in der Pressemitteilung, sondern im Code-Repository. Dass SAP-Engineers direkt in die OpenShell-Codebase committen, ist überprüfbar, weil OpenShell Open Source ist. Wer skeptisch ist – und das sollte man bei jeder Vendor-Ankündigung sein – kann sich das Repository selbst ansehen und nachvollziehen, welche Commits von welchem Unternehmen stammen.

Das ist ein struktureller Unterschied zu vielen anderen KI-Partnerschaften, bei denen ein Unternehmen ein fremdes Produkt lediglich per API einbindet und dann von „tiefer Integration“ spricht. Hier entstehen laut Ankündigung tatsächlich gemeinsame Architekturentscheidungen: die Trennung von Supervisor- und Agent-Execution, die Optimierung des Gateway-Footprints, das Monitoring-Konzept. Das sind Entscheidungen, die man nicht trifft, wenn man nur ein fertiges Produkt integriert. Man trifft sie, wenn man gemeinsam an der Architektur arbeitet.

Die Gründung der Open Secure AI Alliance mit NVIDIA als Gründungsmitglied unterstreicht diese Richtung zusätzlich. Ob daraus ein tragfähiges Industriegremium mit echtem Einfluss auf Standards wird oder eine weitere Initiative, die nach zwei Jahren in der Bedeutungslosigkeit verschwindet, lässt sich heute nicht seriös vorhersagen. Was sich aber sagen lässt: Die Richtung – offene, auditierbare Ausführungsschichten für Agenten als Branchenstandard statt proprietäre Insellösungen – trifft einen Nerv, den viele Enterprise-Kunden aktuell spüren, wenn sie versuchen, Agenten über verschiedene Systeme und Compliance-Anforderungen hinweg zu betreiben.

Was das für Enterprise-Teams praktisch bedeutet

Für IT-Verantwortliche und Architekturteams, die aktuell Agentenprojekte planen oder bereits im Rollout haben, ergeben sich aus dieser Ankündigung konkrete Fragen, die man sich stellen sollte – unabhängig davon, ob man SAP-Kunde ist oder nicht.

Erste Frage: Wo in der eigenen Architektur liegt aktuell die Trennlinie zwischen Autorisierungsentscheidung und Ausführungskontrolle? Wenn die Antwort lautet „Es gibt keine echte Trennung, die Berechtigung und die Ausführung laufen im selben Vertrauenskontext“, dann steckt genau das Problem im eigenen System, das SAP und NVIDIA mit dem Joule-Split adressieren wollen.

Zweite Frage: Wie sieht der Audit-Trail für Agentenausführungen tatsächlich aus? Reicht ein Log-Eintrag „Aktion X wurde ausgeführt“, oder gibt es eine strukturierte, maschinenlesbare Nachvollziehbarkeit auf Prozess- und Netzwerkebene, die im Ernstfall vor einer Aufsichtsbehörde oder einem internen Compliance-Team Bestand hat? Ein OCSF-Format ist dabei kein Selbstzweck, sondern eine praktische Antwort auf die Frage, ob unterschiedliche Sicherheitswerkzeuge im Unternehmen dieselbe Sprache sprechen.

Dritte Frage: Wer im Unternehmen versteht den Unterschied zwischen „der Agent darf das“ und „der Agent kann das kontrolliert tun“ überhaupt? Das ist keine rein technische Frage, sondern eine Frage der organisatorischen Reife. Teams, die Agenten evaluieren und einbetten, brauchen ein Verständnis dafür, dass Autonomie ohne Containment kein Feature, sondern ein Risiko ist. Wie man Evaluationsprozesse für eingebettete KI-Agenten systematisch aufbaut, zeigt unser Beitrag zur eingebetteten Evaluation im Kontext von Anthropic und Accenture – ein Muster, das sich unabhängig vom konkreten Anbieter wiederholt: Bewertung und Kontrolle müssen strukturell in den Betrieb eingebaut sein, nicht nachträglich draufgesetzt.

Ein praktischer Punkt am Rand: Joule Studio Runtime ist laut SAP für Kunden und Partner kostenlos verfügbar – befristet bis Oktober 2026. Wer also aktuell evaluiert, hat ein enges Zeitfenster, um sich die Integration ohne zusätzliche Lizenzkosten anzusehen. Das ist kein Grund für überstürzte Entscheidungen, aber ein Grund, die Evaluation nicht auf die lange Bank zu schieben, wenn man ohnehin plant, in diese Richtung zu gehen.

Die Kosten der Autonomie ohne Boundary

Zurück zur Kernthese. Das Problem, das SAP und NVIDIA hier zu lösen versuchen, ist nicht neu erfunden – es ist ein altes Sicherheitsprinzip, übertragen auf eine neue Klasse von Software. Principle of Least Privilege, Defense in Depth, Trennung von Kontroll- und Ausführungsebene: Das sind Konzepte, die in klassischer IT-Sicherheit seit Jahrzehnten Standard sind. Neu ist nur, dass Agenten eine Geschwindigkeit und eine Entscheidungsautonomie mitbringen, die diese alten Prinzipien plötzlich wieder dringend relevant machen.

Ein menschlicher Mitarbeitender, der eine Berechtigung missbraucht, tut das in menschlichem Tempo, meist erkennbar, oft mit Zwischenschritten, die ein aufmerksames Team bemerkt. Ein Agent, der innerhalb seiner Berechtigung eine unerwartete oder fehlerhafte Aktion ausführt, tut das in Millisekunden, potenziell tausendfach parallelisiert, ohne dass ein Mensch dazwischen sitzt. Das ist der Punkt, an dem Sprawl entsteht: viele Agenten, viele Berechtigungen, viele parallele Ausführungen – und wenn die Containment-Schicht fehlt, eine Audit-Lücke, die im Ernstfall niemand mehr schließen kann, weil die Datenbasis für eine nachträgliche Analyse schlicht nicht existiert.

Das Problem mit vielen aktuellen Agent-Rollouts ist nicht der Agent selbst. Es ist die Annahme, dass ein gutes Rollenmodell reicht, um Kontrolle herzustellen. Funktioniert nicht. Ein Rollenmodell beantwortet Fragen auf Geschäftsprozessebene. Es beantwortet keine Fragen auf Ausführungsebene. Genau diese Lücke ist der Grund, warum Enterprise-Anbieter wie SAP anfangen, technische Ausführungskontrolle als eigenständige Architekturschicht zu behandeln, statt sie implizit dem Autorisierungssystem zu überlassen.

Kritisch anzumerken bleibt: Auch der Joule-Split löst nicht automatisch jedes Problem. Eine gut konzipierte Trennung zwischen Business-Autorisierung und Runtime-Containment ist eine notwendige Bedingung für kontrollierte Agenten-Autonomie – keine hinreichende. Policies müssen richtig konfiguriert sein. Formale Verifikation ist nur so gut wie die Modelle, gegen die verifiziert wird. Und ein Audit-Trail nützt nichts, wenn niemand im Unternehmen ihn regelmäßig auswertet. Die Architektur schafft die Möglichkeit zur Kontrolle. Sie erzwingt nicht, dass diese Kontrolle auch tatsächlich gelebt wird.

Der Blick über SAP hinaus

Wer glaubt, dieses Thema betreffe nur SAP-Kunden, unterschätzt die Reichweite der Diskussion. OpenShell ist Open Source. Die Architekturprinzipien – Trennung von Business-Autorisierung und technischem Containment, Ausführung von Kontrollinstanzen außerhalb der eigentlichen Workload, strukturierte Audit-Formate – lassen sich auf jede Agenten-Architektur übertragen, unabhängig vom eingesetzten Enterprise-System. Wer aktuell eigene Agenten-Infrastruktur mit Kontext aus Graphdatenbanken oder anderen strukturierten Wissensquellen aufbaut, findet in unserem Beitrag zum Thema Context Engineering mit Graphdatenbanken ergänzende Perspektiven dazu, wie Kontext und Kontrolle zusammenspielen müssen, damit ein Agent nicht nur schnell, sondern auch nachvollziehbar handelt.

Wir bei digital-magazin.de beobachten seit Monaten, dass sich der Diskurs um Enterprise-Agenten verschiebt: weg von der Frage „Was kann der Agent?“ hin zur Frage „Was darf der Agent, und wie stellen wir sicher, dass er nicht mehr tut?“ Diese Verschiebung ist gesund. Sie zeigt, dass Unternehmen aus den ersten Pilotprojekten gelernt haben, dass Fähigkeit ohne Kontrolle kein Fortschritt ist, sondern ein aufgeschobenes Risiko.

Interessant wird sein, wie sich die Open Secure AI Alliance in den kommenden Monaten entwickelt und ob weitere große Anbieter dem Beispiel folgen, Ausführungsisolation als offenen Standard statt als proprietäres Feature zu behandeln. Die FedRAMP- und FIPS-Roadmap-Ansprüche von SAP und NVIDIA sind bislang Ankündigungen, keine abgeschlossenen Zertifizierungen. Wer in regulierten Branchen arbeitet, sollte diese Roadmap im Blick behalten, aber nicht als bereits erfüllte Anforderung in eigene Compliance-Dokumente übernehmen.

Was bleibt?

Was bleibt, ist eine relativ einfache Erkenntnis mit großer praktischer Wirkung: Ein Agent, der weiß, dass er darf, aber niemand kontrolliert, wie er es tut, ist kein autonomes System. Er ist ein unkontrolliertes System mit Berechtigung. Der Unterschied zwischen beiden ist der Execution-Boundary – die technische Schicht, die entscheidet, was ein Agent innerhalb seiner Berechtigung tatsächlich anrichten kann, und die diese Entscheidungen so protokolliert, dass sie im Nachhinein überprüfbar sind.

SAP und NVIDIA haben mit der Einbettung von OpenShell in Joule Studio einen konkreten architektonischen Vorschlag dafür vorgelegt, wie diese Trennung technisch aussehen kann. Ob die Umsetzung in der Praxis hält, was die Ankündigung verspricht, muss sich in produktiven Deployments zeigen – nicht in der Pressemitteilung. Aber die Richtung der Architektur ist richtig: AuthZ und Sandbox gehören zusammen, aber sie sind zwei getrennte Kontrollinstanzen mit unterschiedlichen Aufgaben. Wer das ignoriert und Agenten allein über Rollenmodelle skaliert, baut keine Autonomie auf. Er baut Sprawl mit einer Audit-Lücke, die irgendwann teuer wird – spätestens dann, wenn eine Aufsichtsbehörde oder ein interner Prüfbericht nach der Nachvollziehbarkeit einer Agentenaktion fragt und niemand eine belastbare Antwort liefern kann.

Der Punkt ist: Execution-Boundary ist kein Nice-to-have für die nächste Ausbaustufe. Er ist die Voraussetzung dafür, dass ein Enterprise-Agent überhaupt als kontrolliertes System gelten darf. Alles andere ist ein Versprechen ohne Absicherung.