NVIDIA NemoClaw erklärt: Was der Sicherheits-Stack für KI-Agenten kann — und was nicht

Als NVIDIA am 16. März 2026 NemoClaw für die OpenClaw-Community vorstellte, war die Botschaft klar: KI-Agenten brauchen eine Sicherheitsschicht, die nicht vom Modell selbst abhängt. NVIDIA NemoClaw liefert diese Schicht, sechs davon, um genau zu sein. Was dabei fehlt, ist mindestens so aufschlussreich wie das, was funktioniert. Wer glaubt, mit Sandbox-Isolation sei das Agenten-Sicherheitsproblem gelöst, sitzt einem strukturellen Missverständnis auf, das Compliance-Teams und IT-Architekten noch teuer zu stehen kommen wird.

NVIDIA NemoClaw: Sechs Schichten gegen das Agenten-Chaos

NemoClaw ist keine monolithische Security-Suite, sondern eine TypeScript/Python-Referenzschicht über NVIDIA OpenShell. OpenShell stellt Gateway, Sandbox-Container, Credential-Store, Inference-Proxy und Policy-Enforcement bereit; NemoClaw macht diese Bausteine für OpenClaw installierbar und vorkonfiguriert. Das ist eine wichtige Unterscheidung: NemoClaw selbst ist vor allem Orchestrierung und Blueprint, OpenShell setzt die harten Grenzen durch.

Sechs zentrale Schutzmechanismen im Überblick:

Filesystem-Isolation via Landlock LSM: Das Linux Security Module Landlock beschränkt den Agenten auf ein klar definiertes Verzeichnis-Schema. Read-only-Zugriff gilt für /usr, /lib, /proc, /dev/urandom, /app, /etc und /var/log; Schreibzugriff ist auf /sandbox, /tmp und ähnliche Laufzeitpfade begrenzt. Wichtig: Die Dokumentation nennt Landlock ausdrücklich best_effort. Auf Kernels ohne Landlock-Unterstützung greift nur der klassische DAC-Schutz über Datei-Ownership und Permissions. Für Produktion ist eine Landlock-Verifikation daher Pflicht.

Syscall- und Container-Härtung via seccomp: NemoClaw kombiniert Seccomp, reduzierte Linux-Capabilities, no-new-privileges und Prozesslimits. Das verhindert nicht jede Prozesserzeugung, senkt aber die Fläche für Ausbruch, Fork-Bomben und privilegierte Container-Aktionen deutlich.

Netzwerk-Namespaces: Jeder Agent-Prozess erhält einen eigenen Netzwerk-Namespace. Direkter Internetzugriff ist standardmäßig unterbunden; ausgehende Verbindungen laufen durch einen kontrollierten Proxy.

Deny-by-default-Netzwerkpolitik: Die Baseline-Policy erlaubt nur explizit freigegebene Endpunkte. Nicht gelistete Ziele werden durch OpenShell abgefangen und können durch Operatoren genehmigt oder abgelehnt werden. Laufende Policies lassen sich mit openshell policy set aktualisieren; für statische Änderungen verweist NVIDIA auf die Blueprint-Policy openclaw-sandbox.yaml.

Layer-7-Proxy am Gateway: Der OpenShell-L7-Proxy sitzt an der Egress-Grenze, terminiert kontrollierte Routen und injiziert echte Credentials erst außerhalb der Sandbox. Das bedeutet: Der Agent sieht Platzhalter, nicht die API-Schlüssel selbst.

Inference-Routing über die lokale Gateway-Route: API-Schlüssel und Provider-Credentials verbleiben im OpenShell-Gateway-Store. Der Sandbox-Kontext erhält keine direkten Credentials, der Agent sendet Inference-Anfragen an eine lokale Route, die ihrerseits gegen NVIDIA Endpoints, OpenAI, Anthropic, Ollama oder andere Provider vermittelt.

Was die Deployment-Frage betrifft: Die NVIDIA-Dokumentation nennt keine GPU als Mindestanforderung. Getestet sind Linux mit Docker als primärer Pfad, macOS Apple Silicon mit Colima oder Docker Desktop, DGX Spark sowie Windows WSL2 mit Docker Desktop. Die Einrichtung erfolgt über nemoclaw onboard, der Installer startet einen geführten Wizard für Sandbox, Inference-Provider und Netzwerk-Policy.

Der Haken: NemoClaw befindet sich im Alpha-Status. APIs können sich ändern, der Produktionseinsatz wird von NVIDIA selbst nicht empfohlen.

Die vergessene Lücke: Was Sandboxing nicht abdeckt

Hier beginnt das eigentlich kritische Gespräch. Die verbreitete Annahme lautet: Wenn ein Agent in einer Sandbox läuft, sind seine Aktionen kontrolliert und begrenzt. NemoClaw adressiert diese Annahme nur zur Hälfte.

Forscher der Ben-Gurion University identifizierten in ihrer April-2026-Studie zu Aethelgard ein Problem, das sie «Capability Overprovisioning» nennen: OpenClaw exponiert standardmäßig 15 oder mehr Tools pro Session, unabhängig davon, ob der Agent diese Tools für die aktuelle Aufgabe benötigt. Die Skill Economy Ratio (SER) für eine einfache Zusammenfassungsaufgabe liegt bei 0,067: Eines von 15 verfügbaren Tools wird genutzt. Die anderen 14 sind geladene Waffen, die auf dem Tisch liegen.

NemoClaw adressiert diese Überbestückung nicht. Es isoliert den Kontext, in dem ein Agent ausgeführt wird, aber nicht, welche Fähigkeiten er innerhalb dieses Kontexts besitzt.

Dazu kommt eine strukturelle Lücke, die im Forschungsumfeld als Text-Output-Problem bekannt ist: NemoClaw scannt keine Textausgaben des Agenten. Ein Agent kann gefährliche Anweisungen, Daten oder Exfiltrationspfade als Fließtext beschreiben, ohne einen Tool-Call auszuführen, der durch Sandbox-Kontrollen abgefangen werden könnte. Diese Lücke ist kein Implementierungsfehler, sondern ein Architekturproblem: Sandbox-Isolation setzt auf Aktionskontrolle, nicht auf Output-Semantik.

Ein weiterer blinder Fleck: NemoClaw fragt nicht, was ein Agent tun darf, bevor er handelt. Die Plattform adressiert die Frage «Kann der Agent die Außenwelt erreichen?» durch Netzwerk-Kontrolle, aber eine Pre-Action-Authorization, die prüft «Ist diese spezifische Aktion im vorliegenden Kontext erlaubt?», fehlt. Studien zum Open Agent Passport-Framework zeigen eine Social-Engineering-Erfolgsrate von 74,6 Prozent, wenn das Sprachmodell selbst die primäre Verteidigung darstellt. Unter restriktiver OAP-Policy sinkt diese Rate auf null, bei 879 getesteten Versuchen.

Für Sicherheitsverantwortliche, die sich mit LLM-Guardrails und deren Grenzen gegenüber Prompt-Fuzzing-Angriffen beschäftigen, ist das keine Überraschung: Modell-seitige Abwehrmechanismen brechen unter adversarialem Druck zusammen. NemoClaw verlagert die Kontrolle in die Infrastruktur, löst aber nicht das Problem der semantischen Intention.

Drei Frameworks im Vergleich: NemoClaw, Aethelgard und DefenseClaw

Die Agenten-Sicherheitslandschaft hat sich 2026 pluralisiert. Drei Ansätze sind derzeit maßgeblich, und sie adressieren jeweils unterschiedliche Angriffsflächen.

NemoClaw (NVIDIA), Containment-orientiert. Stärken: Kernel-Level-Isolation, Credential-Trennung, Policy-as-Code via OPA, keine GPU-Abhängigkeit. Schwächen: Kein Capability-Management, keine Output-Semantik-Kontrolle, keine Pre-Action-Authorization. Alpha-Status.

Aethelgard (Ben-Gurion University), Least-Privilege-orientiert. Das vierschichtige Framework legt sich über NemoClaw und ergänzt einen Capability Governor, eine RL-Policy (Proximal Policy Optimization), einen Safety Router (MITM-Proxy mit LLM-Classifier) und einen Inference Layer. Die Studie berichtet 73 Prozent Tool-Reduktion und die Entfernung gefährlicher Tools wie exec und sessions_spawn aus adversarialen Testkonfigurationen. Das PPO-Training läuft laut Paper in unter fünf Minuten auf einer RTX 3090 mit 50.000 Schritten.

Der Preis: Wenn der LLM-basierte Teil des Safety Routers greift, addiert er laut Paper rund 800 Millisekunden Latenz; einzelne Benchmark-Pfade lagen höher. Bei interaktiven Agenten ist das ein merklicher Overhead. Aethelgard ist ein Forschungsprototyp, kein Produktionssystem.

Cisco DefenseClaw, Reaktiv und detektionsorientiert. DefenseClaw scannt Skills, MCP-Server, Plugins, Tool-Aufrufe und LLM-I/O, führt Policy-Checks über Rego/OPA aus und schreibt Audit-Daten in lokale oder Enterprise-Senken. Es ergänzt damit das operative Management: Wer kümmert sich um Block-Listen? Wer reagiert auf Alerts um 2 Uhr morgens? Diese Fragen beantwortet NemoClaw nicht. DefenseClaw adressiert sie auf Betriebsebene.

Die Kombination, die sich aus dem Forschungsstand ableiten lässt: NemoClaw als Isolation-Foundation, Aethelgard-Prinzipien (oder vergleichbare Capability-Governance) für Least-Privilege, DefenseClaw für reaktive Detektion und Betrieb. Kein einzelnes Framework löst das Problem allein.

Ähnliche Architekturüberlegungen gelten auch für Code-Execution-Umgebungen, wie LangSmith Sandboxes zeigen: Isolation und semantische Kontrolle sind orthogonale Probleme, die orthogonale Lösungen erfordern.

DACH-Compliance: EU AI Act, DSG und die Frage nach dem Nachweisbarkeitsrahmen

Ab dem 2. August 2026 greifen wesentliche Pflichten für Hochrisiko-Systeme nach dem EU AI Act. Autonome Agenten sind nicht automatisch Hochrisiko-Systeme. Relevant wird NemoClaw dort, wo Agenten in regulierten Kontexten handeln: kritische Infrastruktur, Finanzprozesse, öffentliche Leistungen oder sicherheitsrelevante Workflows.

Zwei Artikel sind für den NemoClaw-Kontext unmittelbar relevant:

Art. 9 (Risikomanagementsystem) verlangt einen kontinuierlichen Identifikations- und Bewertungsprozess für Risiken während des gesamten Lebenszyklus eines Hochrisiko-KI-Systems. NemoClaw liefert technische Kontrollen, aber kein dokumentiertes Risikomanagement-Framework. Die OPA-Policies sind maschinenlesbar, aber nicht automatisch audit-tauglich im Sinne des EU AI Acts.

Art. 13 (Transparenz und Bereitstellung von Informationen) fordert, dass Betreiber die Funktionsweise des Systems nachvollziehen können. Hier entsteht ein strukturelles Problem: Wenn Aethelgard-ähnliche RL-basierte Governance über NemoClaw gelegt wird, lernt das Policy-Modell Fähigkeitsbeschränkungen, aber wer prüft das gelernte Modell? Wer dokumentiert, welche Capability-Reduktionen aus dem Training resultieren und welche aus expliziter Konfiguration? Die Antwort lautet heute: niemand, weil die Tooling-Infrastruktur dafür fehlt.

In der Schweiz gelten die Anforderungen des revidierten Datenschutzgesetzes (DSG) parallel. Das DSG verlangt Datensicherheitsmaßnahmen, die dem Stand der Technik entsprechen. Der Credential-Proxy-Ansatz von NemoClaw, Provider-Schlüssel im OpenShell-Gateway-Store, nur Platzhalter im Sandbox-Kontext, ist eine valide Maßnahme. Aber ein Gateway als Credentials-Verwalter bleibt ein Konzentrationspunkt: SSRF-Schwachstellen in vergleichbaren MCP- und Agenten-Proxy-Komponenten zeigen, dass Credential-Broker selbst hart abgesichert werden müssen. NemoClaw reduziert Credential-Leakage im Agenten-Kontext; es ersetzt keine klassische Proxy-Härtung.

Second-Order Effects: Was Enterprise-Adoption wirklich bedeutet

Zwei Konsequenzen einer breiten NemoClaw-Adoption bleiben in der öffentlichen Diskussion unterbelichtet.

Vendor-Lock-in auf NVIDIA-Infrastruktur: NemoClaw ist Open Source, aber die dokumentierten Inference-Pfade priorisieren NVIDIA-Dienste. Organisationen, die NemoClaw als Compliance-Baseline einführen, bauen Abhängigkeiten auf, die beim Wechsel zu alternativer Inference-Infrastruktur Aufwand erzeugen. Das ist keine Verschwörungstheorie, sondern die strukturelle Logik jedes Platform-Plays: Die Sicherheitsschicht und die empfohlene Compute-Schicht stammen vom gleichen Hersteller.

RL-basierte Governance erzeugt neue Compliance-Blindstellen: Aethelgard trainiert seine Policy via PPO, in unter fünf Minuten, auf einem Consumer-GPU. Das klingt effizient. Es bedeutet aber auch, dass das gelernte Modell Fähigkeitsbeschränkungen kodiert, die sich nicht direkt aus menschlich verständlichen Regeln ableiten lassen. Wenn ein Compliance-Audit fragt «Warum kann dieser Agent dieses Tool nicht aufrufen?», lautet die korrekte Antwort: «Weil das RL-Modell das so gelernt hat.» Ob das unter Art. 9 EU AI Act als dokumentierter Risikominderungsmaßnahme gilt, ist eine offene Rechtsfrage.

Das Supply-Chain-Risiko verschärft die Situation: Cisco beschreibt mit ClawHavoc eine koordinierte Attacke, bei der über 800 bösartige Skills in ClawHub auftauchten, grob ein Fünftel des damaligen Registry-Bestands. NemoClaw isoliert die Ausführung in einer Sandbox; es validiert nicht die Herkunft und Integrität der Skills vor dem Laden.

Fazit: Notwendig, aber nicht hinreichend

NemoClaw adressiert ein reales Problem: KI-Agenten brauchen Infrastruktur-seitige Sicherheitsgarantien, die nicht vom Modellverhalten abhängen. Die sechs Schutzschichten, Filesystem-Isolation, Syscall-Filterung, Netzwerk-Namespaces, Policy-Proxy, TLS-Inspektion, Credential-Trennung, sind technisch solide konzipiert.

Aber Sandboxing löst das Agenten-Sicherheitsproblem nicht. Es begrenzt den Schaden eines kompromittierten Agenten, der bereits handelt. Es verhindert nicht, dass ein Agent mit überbestückten Capabilities gefährlich handelt. Es scannt keine semantischen Outputs. Es implementiert keine Pre-Action-Authorization.

Wer NemoClaw als Compliance-Antwort auf den EU AI Act behandelt, wird spätestens beim Audit merken, dass ein Alpha-Framework ohne dokumentierten Lebenszyklus kein Risikomanagementsystem im Sinne von Art. 9 ist.

Die Antwort auf das Agenten-Sicherheitsproblem ist kein einzelnes Framework. Sie ist eine Architekturentscheidung: Containment (NemoClaw) plus Least-Privilege-Governance (Aethelgard-Prinzipien) plus reaktive Detektion (DefenseClaw) plus Pre-Action-Authorization (OAP). Alles andere ist Stückwerk, und Angreifer, die LLMs für Cyberangriffe einsetzen, wissen das bereits.