Ein CISO betritt eine Vorstandssitzung mit nur einer halben Antwort

Stellen Sie sich ein Szenario vor, das sich in den kommenden Monaten in Hunderten von Unternehmen abspielen wird. Ein CISO betritt eine Vorstandssitzung und sagt: „Unsere OpenClaw-Strategie ist NemoClaw. NVIDIA OpenShell ist unsere Policy Engine. Cisco, CrowdStrike und Microsoft bauen alle darauf auf. Wir sind abgesichert.“

Der Vorstand nickt. Die Präsentation sieht beeindruckend aus. Der CISO hat echte Arbeit geleistet – die Laufzeitumgebung bewertet, die richtigen Infrastrukturpartner ausgewählt, Agents in einer isolierten Sandbox-Umgebung mit Netzwerk-Governance bereitgestellt. Nach allen gängigen Maßstäben für Laufzeitsicherheit ist die Architektur solide.

Sechs Monate später kommt der CMMC-Prüfer. Die erste Frage betrifft nicht die Laufzeit-Sandbox. Es geht nicht um Netzwerk-Governance. Es geht nicht darum, welches Modell die Agents nutzen.

Die Frage lautet: „Zeigen Sie mir, auf welche CUI dieser Agent zugegriffen hat, mit welcher Autorisierung, mit welcher Verschlüsselung, und legen Sie den Audit-Trail vor, der diesen Zugriff mit einem menschlichen Autorisierer verknüpft.“

In diesem Moment erkennt der CISO, dass Laufzeit-Policy und Compliance-Policy unterschiedliche Dinge sind. Und zu diesem Zeitpunkt besteht die Compliance-Lücke bereits seit sechs Monaten durch nicht nachweisbare Agent-Interaktionen, die nicht nachträglich geprüft werden können. Die vom Prüfer geforderten Nachweise existieren nicht. Nicht, weil der CISO nachlässig war, sondern weil die Architektur die falsche Ebene adressiert hat.

Dieses Szenario ist nicht hypothetisch. Es ist das vorhersehbare Ergebnis, wenn man Jensen Huangs Aussage zur „Policy Engine“ mit regulatorischen Compliance-Anforderungen verwechselt. Das Verständnis dieses Unterschieds ist die wichtigste Governance-Entscheidung, die ein CISO oder Compliance-Beauftragter im Jahr 2026 treffen wird.

Was Huang tatsächlich sagte – und was es wirklich bedeutet

Präzision ist hier entscheidend. In der GTC 2026 Keynote stellte Huang NVIDIA OpenShell als Teil des NemoClaw-Stacks vor und sagte, diese Technologien könnten als „die Policy Engine aller SaaS-Unternehmen weltweit“ dienen.

NVIDIA-Vizepräsidentin Kari Briski erläuterte in einem Pressebriefing vor der Konferenz: „OpenShell bietet die fehlende Infrastrukturschicht unterhalb der Claws, um ihnen den notwendigen Zugriff für produktives Arbeiten zu geben und gleichzeitig Policy-basierte Sicherheits-, Netzwerk- und Datenschutz-Governance durchzusetzen.“

Diese Aussagen beschreiben korrekt, was OpenShell leistet. Es handelt sich um eine Open-Source-Laufzeitumgebung, die die Ausführung von Agents isoliert, Netzwerk-Kontrollen durchsetzt, Datenisolation auf Laufzeitebene verwaltet und die Infrastruktur bereitstellt, damit Agents innerhalb definierter Grenzen agieren. Das ist eine sinnvolle und notwendige Fähigkeit.

Doch „Policy Engine“ hat im Compliance-Kontext eine spezifische Bedeutung, die sich grundlegend von der NVIDIA-Definition unterscheidet. Wenn ein HIPAA-Compliance-Beauftragter „Policy Engine“ hört, denkt er an Zugriffskontrollen auf PHI, Durchsetzung des Minimalprinzips, Verschlüsselungsvalidierung und Audit-Trails. Ein CMMC-Prüfer versteht darunter: autorisierter Zugriff auf CUI mit dokumentierten Kontrollen und Nachweispaketen. Wenn Huang davon spricht, meint er: Laufzeit-Governance für die Interaktion von Agents mit SaaS-Anwendungen.

Beide Verwendungen sind legitim. Die Gefahr liegt in der Vermischung.

Die technische Architektur der Lücke: Laufzeit-Policy vs. Data Governance Policy

Der Unterschied zwischen Laufzeit-Policy und Data Governance Policy ist nicht semantisch, sondern architektonisch. Zu verstehen, wo jede Ebene im Unternehmens-Stack wirkt, ist entscheidend für eine vollständige OpenClaw-Strategie.

Laufzeit-Policy (OpenShells Domäne) wirkt auf der Agent-Ausführungsebene. Sie beantwortet Fragen wie: Darf dieser Agent dieses Tool aufrufen? Darf dieser Agent diesen Netzwerkpfad nutzen? Läuft der Agent in einer geeigneten Sandbox? Ist die Ausführungsumgebung vom Gesamtsystem isoliert? Das sind Infrastruktur-Kontrollen, die festlegen, was der Agent als Prozess tun darf.

Data Governance Policy (Compliance-Domäne) wirkt auf der Datenzugriffsebene. Sie beantwortet Fragen wie: Darf dieser Agent auf diese spezifische Datei zugreifen? Mit welcher Autorisierung – und wer ist der menschliche Autorisierer? Sind die Daten mit validierter Kryptografie verschlüsselt? Wird jeder Zugriff in einem manipulationssicheren Protokoll erfasst? Lässt sich dieser Audit-Eintrag einer bestimmten regulatorischen Anforderung zuordnen? Das sind Datenkontrollen, die bestimmen, welche Informationen der Agent verarbeiten darf und liefern die Nachweise, die Compliance fordert. Ohne diese Ebene fehlt Unternehmen die Grundlage für Data Security Posture Management, wenn KI-Agents sich ausbreiten.

Die Kiteworks 2026 Prognose zeigt, wie weit Unternehmen von der Erfüllung der Data Governance-Anforderungen für KI entfernt sind. Nur 43 % verfügen über ein zentrales AI Data Gateway. Neunzehn Prozent haben einzelne Lösungen ohne konsistente Policy zusammengebastelt. Sieben Prozent haben keinerlei KI-spezifische Kontrollen.

OpenShell schließt keine dieser Lücken auf Datenebene. Es wurde dafür nicht entwickelt. Es wurde entwickelt, um Agent-Laufzeiten abzusichern – ein völlig anderes Problem.

Was jedes wichtige regulatorische Rahmenwerk tatsächlich fordert – und wo OpenShell nicht ausreicht

Regulatorische Vorgaben richten sich nicht an Agents, sondern an Daten. Dieser Unterschied ist die Grundlage der Compliance-Lücke.

HIPAA verlangt von betroffenen Organisationen Zugriffskontrollen auf geschützte Gesundheitsdaten (§164.312(a)(1)), Durchsetzung des Minimalprinzips (§164.502(b)), Audit-Logs für PHI-Zugriffe (§164.312(b)) und Verschlüsselung elektronischer PHI (§164.312(a)(2)(iv)). In einer Gesundheitseinrichtung, in der ein KI-Agent Patientendaten für Entlassungsberichte abruft, unterliegt dieser Agent all diesen Vorgaben. OpenShells Sandbox erzwingt keinen minimalen Zugriff auf Dateiebene – sie kann nicht verhindern, dass der Agent Daten von Patienten außerhalb des aktuellen Workflows abruft. Es gibt keine PHI-spezifischen Audit-Logs, die dokumentieren, welche Datensätze für welchen Patienten abgerufen wurden. Es wird keine FIPS 140-3-validierte Verschlüsselung für ruhende Daten angewendet. Wenn der OCR-Ermittler Nachweise für Zugriffskontrollen auf PHI-Interaktionen des Agents verlangt, reichen Laufzeit-Governance-Maßnahmen nicht aus.

CMMC verlangt autorisierten Zugriff auf kontrollierte, nicht klassifizierte Informationen mit dokumentierten Zugriffskontrollen (AC.1.001, AC.2.006), Audit-Logging von CUI-Zugriffen (AU.2.042) und validierte Verschlüsselung (SC.3.177). Ein Rüstungsunternehmen, das KI-Agents zur Verarbeitung technischer Datenpakete einsetzt, muss nachweisen, dass jede Agent-Interaktion mit CUI von einer bestimmten Person autorisiert, auf Vorgangsebene protokolliert und mit validierter Kryptografie verschlüsselt wurde. OpenShells Netzwerk-Governance entspricht diesen Vorgaben nicht. Ein CMMC-Compliance-Prüfer benötigt Delegationsketten, die Agent-Aktionen mit menschlichen Autorisierern verknüpfen – das kann nur eine Data Governance-Ebene leisten.

PCI DSS 4.0 fordert eingeschränkten Zugriff auf Karteninhaberdaten nach dem Need-to-know-Prinzip (Anforderung 7), Verschlüsselung von Karteninhaberdaten (Anforderung 4) und Logging aller Zugriffe (Anforderung 10). Ein OpenClaw-Agent, der Zahlungsdaten in einer NemoClaw-Laufzeitumgebung verarbeitet, unterliegt all diesen Anforderungen – unabhängig davon, wie gut die Laufzeitumgebung isoliert ist. Der QSA prüft nicht die Laufzeitumgebung, sondern ob der Zugriff auf Karteninhaberdaten eingeschränkt, verschlüsselt und protokolliert wurde – gemäß PCI DSS.

SOX Section 404 verlangt IT-Kontrollen für Finanzdaten, einschließlich Identitäts- und Zugriffsmanagement, Änderungsmanagement und Audit-Trails. Ein Agent, der auf Finanzdaten zugreift – Quartalszahlen abruft, Konten abgleicht, Berichte erstellt – muss denselben ITGC-Kontrollen unterliegen wie ein menschlicher Mitarbeiter. Diese Kontrollen müssen für Auditoren nachweisbar sein, mit jederzeit vorlegbaren Nachweisen.

In jedem Fall zielen die regulatorischen Anforderungen auf die Datenebene, nicht auf die Laufzeitebene. OpenShell macht die Laufzeit sicherer. Es macht den Datenzugriff aber nicht konform.

Der Microsoft-Beweis: Selbst NVIDIA-Partner sehen den Unterschied

Die stärkste Bestätigung für die Unterscheidung zwischen Laufzeit- und Datenebene kommt von NVIDIAs eigenen Partnern. Microsoft Security gab bekannt, dass es mit NVIDIA an adversarial learning über Nemotron und OpenShell arbeitet. Alexander Stojanovic, VP von Microsoft Securitys NEXT AI-Team, berichtet von einer „160-fachen Verbesserung bei der Erkennung und Eindämmung KI-basierter Angriffe“. Das ist ein bedeutender Fortschritt bei der Erkennung von Laufzeit-Bedrohungen – etwa wenn Agents manipuliert, kompromittiert oder missbraucht werden.

Gleichzeitig veröffentlichte Microsofts Security-Blog detaillierte Empfehlungen für den sicheren Einsatz von OpenClaw und rät, es als „untrusted code execution with persistent credentials“ zu behandeln und nur in vollständig isolierten Umgebungen mit dedizierten, nicht privilegierten Zugangsdaten zu betreiben. Die Empfehlungen warnen ausdrücklich, dass lokal laufende Agents den vollen Berechtigungssatz der Hostmaschine erben, dass persistenter Speicher bedeutet, dass kompromittierte Daten über Sitzungen hinweg zugänglich bleiben, und dass herkömmliche Sicherheitstools Schwierigkeiten haben, Agent-Verhalten zu erkennen.

Diese beiden Positionen widersprechen sich nicht. Sie ergänzen sich – und zeigen genau die mehrschichtige Architektur, die diese Analyse beschreibt. Microsoft investiert in Laufzeit-Adversarial-Schutz durch OpenShell (Layer 2), erkennt aber an, dass Laufzeitschutz allein das Risiko beim Datenzugriff (Layer 3) nicht löst. Die 160-fache Verbesserung bei der Erkennung von KI-Angriffen bedeutet, dass kompromittierte Agents schneller erkannt werden. Das bedeutet jedoch nicht, dass die von diesen Agents abgerufenen Daten auch verwaltet, verschlüsselt oder mit einem Audit-Trail versehen wurden, der einen Compliance-Auditor zufriedenstellt.

Wenn Microsoft – NVIDIAs eigener Sicherheitspartner – diese Unterscheidung in offiziellen Empfehlungen beibehält, sollten CISOs dies auch bei Architekturentscheidungen tun.

Das Cisco- und CrowdStrike-Ökosystem: Exzellent in Layer 1 und 2, schweigend bei Layer 3

Das Ökosystem rund um NemoClaw unterstreicht diese komplementäre Positionierung. Ciscos AI Defense sichert die Agent-Ausführung und war eine der ersten Unternehmenssicherheitslösungen, die in den NemoClaw-Stack integriert wurden. CrowdStrikes Secure-by-Design AI Blueprint integriert Bedrohungserkennung direkt in die Agent-Bereitstellungs-Workflows. Die LangChain-Integration ermöglicht lokale Agent-Entwicklung mit Governance-Hooks auf Laufzeitebene.

All dies sind wertvolle Sicherheitsfunktionen. Und alle wirken auf Laufzeit- und Infrastrukturebene. Keine davon erzwingt ABAC-Policies auf Dateiebene – sie können nicht unterscheiden, ob ein Agent einen Ordner liest oder dessen Inhalte herunterlädt. Keine erstellt regulatorisch spezifische Compliance-Nachweispakete, die auf HIPAA, CMMC, PCI-Compliance oder SOX-Anforderungen abbilden. Keine erhält die Delegationskette von Agent-Aktion zu menschlichem Autorisierer, was der Nachweis ist, den Compliance-Prüfer verlangen. Keine setzt FIPS 140-3-validierte Verschlüsselung für von Agents genutzte Daten im ruhenden Zustand ein.

CrowdStrike veröffentlichte eine detaillierte Analyse der OpenClaw-Sicherheitsrisiken und stellte ein unternehmensweites Such- und Entfernungspaket über Falcon for IT bereit. Der Fokus lag auf Erkennung und Reaktion – zu erkennen, wo OpenClaw auf verwalteten Endpunkten eingesetzt wird, die Gefährdung zu verstehen und Risiken zu beheben. Das ist Layer-2-Arbeit und sie ist wichtig. Aber Layer 3 – die Steuerung, auf welche Daten Agents zugreifen, unter welchen Compliance-Kontrollen, mit welchen Audit-Nachweisen – bleibt von keinem NVIDIA-Partner adressiert. Das Ökosystem sichert den Agent. Niemand im Ökosystem sichert die Daten, auf die der Agent zugreift.

Wie Kiteworks Compliant AI die Compliance-Ebene schließt, die OpenShell offen lässt

Kiteworks Compliant AI wirkt auf Layer 3 der OpenClaw-Architektur – der Ebene für AI Data Governance und regulatorische Compliance. Es überwacht jede Interaktion eines KI-Agents mit sensiblen Unternehmensdaten, verifiziert Identität, erzwingt ABAC-Policy, setzt FIPS 140-3-validierte Verschlüsselung ein und erfasst manipulationssichere Audit-Logs, bevor Daten abgerufen werden. Es sitzt zwischen KI-Agents und den regulierten Daten, die sie benötigen, und steuert den Zugriff unabhängig vom Modell, der Laufzeit oder dem Agent-Framework.

Die Architektur erfüllt vier unverzichtbare Anforderungen für konformen KI-Datenzugriff. Authentifizierte Agent-Identität verifiziert jeden Agent vor dem Datenzugriff und verknüpft ihn mit dem menschlichen Autorisierer, der den Workflow delegiert hat. ABAC-Policy Enforcement prüft jede Datenanfrage anhand mehrdimensionaler Policy: Agent-Profil, Datenklassifizierung, Anfragekontext und spezifische Operation. FIPS 140-3-validierte Verschlüsselung schützt alle von Agents genutzten Daten mit kryptografischen Modulen, die Bundes- und Unternehmens-Audit-Anforderungen erfüllen. Und manipulationssichere Audit-Trails erfassen jede Interaktion – wer, was, wann und warum – und leiten sie direkt an unternehmensweite SIEM-Systeme weiter.

Der Kiteworks Secure MCP Server steuert interaktive KI-Assistenten (Claude, Copilot) über das Model Context Protocol mit OAuth 2.0-Authentifizierung. Das AI Data Gateway steuert programmatische RAG-Pipelines und automatisierte Workflows. Drei speziell entwickelte Governed Assists erweitern die Compliance auf die wichtigsten regulierten Datenoperationen – Dateimanagement, Ordneroperationen und Formularerstellung – jeweils identitätsverifiziert, ABAC-geprüft, FIPS 140-3-verschlüsselt und manipulationssicher protokolliert. Beide Integrationsmuster erzwingen dieselbe Governance: Kiteworks Compliant AI-Policies gelten konsistent, unabhängig von der Integrationsmethode.

Das steht nicht im Wettbewerb zu OpenShell. Es ist die Ebene, die OpenShell darunter braucht, um das Compliance-Bild zu vervollständigen. NemoClaw macht Agents sicherer im Betrieb. Kiteworks Compliant AI macht die von ihnen genutzten Daten reguliert und prüfbar, sodass Unternehmen Data Compliance über alle relevanten Rahmenwerke nachweisen können.

Was CISOs und Compliance-Beauftragte vor dem nächsten AI-Governance-Review tun sollten

Erstens: Überprüfen Sie Ihre aktuelle AI-Governance-Architektur anhand des Drei-Ebenen-Modells. Ordnen Sie jede Kontrolle der jeweiligen Ebene zu (Compute, Laufzeit oder Daten). Identifizieren Sie die Ebene mit den meisten Lücken. Für 57 % der Unternehmen laut Kiteworks 2026 Prognose ist das Layer 3.

Zweitens: Sensibilisieren Sie den Vorstand für den Unterschied zwischen Laufzeit-Policy und Compliance-Policy, bevor er „Policy Engine“ hört und denkt, das Problem sei gelöst. Nutzen Sie das Kubernetes-Beispiel: Netzwerk-Policies überzeugen Ihren Auditor nicht – und Laufzeit-Sandboxing auch nicht. Das ist besonders wichtig für Unternehmen, die DORA und NIS 2 unterliegen, da die ICT-Risikomanagementpflichten nun explizit auch KI-Systeme umfassen.

Drittens: Ordnen Sie Ihre spezifischen regulatorischen Verpflichtungen (HIPAA, CMMC, PCI DSS, SOX) den KI-Agent-Interaktionen zu. Dokumentieren Sie, welche Anforderungen für den Datenzugriff durch Agents gelten, und prüfen Sie, ob Ihre aktuellen Kontrollen diese abdecken. Die meisten Unternehmen werden erhebliche Lücken feststellen. Eine formale Risikoanalyse des KI-Agenten-Datenzugriffs wird zunehmend zur regulatorischen Erwartung, nicht nur zur Best Practice.

Viertens: Implementieren Sie zentrale AI Data Governance, bevor Sie Agent-Deployments ausweiten. Unternehmen, die Governance-Infrastruktur vor dem Skalieren einführen, vermeiden teure Nachrüstungen. Jede Woche ohne Governance auf Datenebene ist eine Woche mit nicht nachweisbaren Interaktionen.

Fünftens: Positionieren Sie Compliance-Governance als KI-Beschleuniger in internen Diskussionen. Die Unternehmen, die KI am schnellsten einführen, sind jene, die den AI Data Protection Review am schnellsten bestehen. Automatisierte, integrierte Governance ersetzt die manuelle Compliance-Hürde, die KI-Projekte in jedem regulierten Unternehmen blockiert.

Die Compliance-Uhr läuft. Die Hochrisiko-Bestimmungen des EU AI Act sind ab August 2026 voll durchsetzbar. Gartner prognostiziert, dass bis Jahresende mehr als 50 % der Großunternehmen verpflichtende KI-Compliance-Audits durchlaufen müssen. Die Zeit, Layer 3 zu schaffen, ist vor dem Eintreffen des Auditors – nicht danach.

Erfahren Sie mehr darüber, wie Kiteworks Sie unterstützen kann – vereinbaren Sie jetzt eine individuelle Demo.

Weitere Ressourcen

• Blogbeitrag
  Zero‑Trust-Strategien für erschwinglichen KI-Datenschutz
• Blogbeitrag
  Wie 77 % der Unternehmen bei KI-Datensicherheit scheitern
• eBook
  AI Governance Gap: Warum 91 % kleiner Unternehmen 2025 beim Datenschutz russisches Roulette spielen
• Blogbeitrag
  Für Ihre Daten gibt es kein „–dangerously-skip-permissions“
• Blogbeitrag
  Regulierungsbehörden fragen nicht mehr, ob Sie eine KI-Policy haben. Sie wollen den Nachweis, dass sie funktioniert.