NemoClaw Architektur im Detail

NemoClaw Architektur im Detail

NemoClaw ist kein einzelnes Produkt — es ist eine geschichtete Sicherheitsarchitektur, die darauf ausgelegt ist, autonome KI-Agenten für den Produktionseinsatz sicher zu machen. Dieser Beitrag führt durch jede Schicht, erklärt deren Zusammenspiel und liefert den technischen Kontext, den Sie benötigen, um NemoClaw für Ihre eigene Infrastruktur zu bewerten.

Architekturübersicht

Der NemoClaw-Stack besteht aus vier primären Schichten, von denen jede eine andere Dimension der Agentensicherheit adressiert:

┌─────────────────────────────────────────────┐
│              Agent Application               │
│         (OpenClaw Agent Framework)           │
├─────────────────────────────────────────────┤
│             Privacy Router                    │
│    (Local vs. Cloud Model Routing)           │
├─────────────────────────────────────────────┤
│           Nemotron Policy Engine              │
│    (120B MoE Intent Classification)          │
├─────────────────────────────────────────────┤
│             OpenShell Runtime                 │
│    (Kernel-Level Sandbox + Isolation)        │
├─────────────────────────────────────────────┤
│          Host OS / Hardware (DGX)             │
└─────────────────────────────────────────────┘

Jede Schicht arbeitet unabhängig und kann eigenständig bereitgestellt werden, aber der vollständige Stack bietet eine Defense-in-Depth-Sicherheit, die keine einzelne Schicht allein erreichen kann.

Schicht 1: OpenShell-Sicherheitslaufzeitumgebung

OpenShell ist das Fundament des NemoClaw-Sicherheitsmodells. Es bietet Kernel-Level-Sandboxing für die Agentenausführung und stellt sicher, dass selbst ein kompromittierter Agent seine Sicherheitsgrenze nicht überschreiten kann.

Wie OpenShell funktioniert

OpenShell verwendet eine Kombination aus Linux-Kernel-Namespaces, seccomp-BPF-Filtern und NVIDIAs benutzerdefinierten eBPF-Programmen, um isolierte Ausführungsumgebungen für jede Agentenaufgabe zu erstellen:

# openshell-policy.yaml
apiVersion: openshell.nvidia.com/v1
kind: SandboxPolicy
metadata:
  name: customer-support-agent
spec:
  isolation:
    network: restricted
    filesystem: read-only
    syscalls: minimal
  resources:
    maxMemory: 4Gi
    maxCPU: 2
    gpuAccess: inference-only
  permissions:
    allowedAPIs:
      - crm.read
      - crm.update
      - ticket.create
      - ticket.resolve
    deniedAPIs:
      - admin.*
      - billing.*
      - user.delete
  auditLog:
    enabled: true
    destination: siem://security-events

Jeder Systemaufruf des Agenten wird von OpenShells eBPF-Schicht abgefangen, anhand der Richtlinie klassifiziert und entweder erlaubt, abgelehnt oder zur menschlichen Genehmigung eskaliert. Die gesamte Entscheidungspipeline läuft im Kernel-Bereich und fügt weniger als 50 Mikrosekunden Latenz pro Systemaufruf hinzu.

Operator-Genehmigungsworkflows

Für Hochrisiko-Operationen — Datenlöschung, Infrastrukturänderungen, externe Kommunikation — kann OpenShell die Agentenausführung pausieren und die Aktion zur Genehmigung an einen menschlichen Operator weiterleiten:

// Approval workflow configuration
const approvalPolicy = {
  triggers: [
    { action: 'data.delete', threshold: 'always' },
    { action: 'infra.modify', threshold: 'always' },
    { action: 'email.send', threshold: 'external-only' },
    { action: 'payment.process', threshold: 'above-100-usd' },
  ],
  channels: ['slack', 'teams', 'pagerduty'],
  timeout: '15m',
  defaultAction: 'deny',
};

Dies stellt sicher, dass Agenten für Routineaufgaben autonom arbeiten können, während bei folgenreichen Aktionen die menschliche Aufsicht gewahrt bleibt.

Schicht 2: Nemotron 120B MoE Richtlinien-Engine

Das Nemotron 120B Mixture-of-Experts-Modell dient als NemoClaws intelligente Richtlinienbewertungs-Engine. Anders als traditionelle regelbasierte Sicherheitssysteme kann Nemotron die Absicht hinter Agentenaktionen verstehen und sie anhand natürlichsprachlicher Sicherheitsrichtlinien bewerten.

Absichtsklassifikation

Wenn ein Agent eine Aktion anfordert, klassifiziert Nemotron die Absicht über mehrere Dimensionen:

• •Sensitivität: Wie sensibel sind die beteiligten Daten? (öffentlich, intern, vertraulich, eingeschränkt)
• •Reversibilität: Kann diese Aktion rückgängig gemacht werden? (vollständig reversibel, teilweise reversibel, irreversibel)
• •Umfang: Wie viele Systeme oder Benutzer sind betroffen? (einzeln, Team, Organisation, extern)
• •Compliance: Fällt diese Aktion unter regulatorische Rahmenwerke? (DSGVO, HIPAA, SOC 2, PCI-DSS)

Die Klassifikation läuft in unter 200 ms auf einer einzelnen A100-GPU und in unter 50 ms auf einem DGX Spark mit der quantisierten Modellvariante.

Natürlichsprachliche Richtlinien

Sicherheitsteams können Richtlinien in einfachem Englisch definieren, die Nemotron interpretiert und durchsetzt:

Policy: "Customer support agents may access customer records for active tickets only.
         They may not access financial data, modify account settings, or communicate
         with customers outside of the ticketing system. All PII must be redacted
         from internal logs."

Nemotron wandelt diese natürlichsprachlichen Richtlinien in ausführbare Sicherheitsregeln um und überbrückt so die Kluft zwischen der Absicht des Sicherheitsteams und der technischen Durchsetzung.

Schicht 3: Privacy Router

Der Privacy Router ist NemoClaws intelligente Modell-Routing-Schicht. Er bestimmt, ob jede Agentenaufgabe von einem lokalen Modell (Nemotron vor Ort) verarbeitet oder an einen Cloud-Modell-Endpunkt weitergeleitet werden soll, basierend auf der Datensensitivitätsklassifikation.

Routing-Logik

# Simplified Privacy Router logic
def route_request(request: AgentRequest) -> ModelEndpoint:
    sensitivity = classify_sensitivity(request.context)

    if sensitivity in ['restricted', 'confidential']:
        # Highly sensitive data stays local
        return local_nemotron_endpoint

    if sensitivity == 'internal':
        # Internal data can use cloud with encryption
        return cloud_endpoint_with_e2e_encryption

    if sensitivity == 'public':
        # Public data can use any endpoint for best performance
        return optimal_cloud_endpoint

    # Default: local processing
    return local_nemotron_endpoint

Der Privacy Router pflegt einen Echtzeit-Klassifikations-Cache, sodass wiederholte Anfragen mit ähnlichem Kontext ohne erneute Bewertung weitergeleitet werden. In Benchmarks fügt der Router weniger als 5 ms Latenz zur Anfragepipeline hinzu.

Datenresidenz-Compliance

Für Organisationen, die Datenresidenz-Anforderungen unterliegen (EU-DSGVO, Chinas PIPL usw.), kann der Privacy Router geografische Routing-Einschränkungen durchsetzen:

privacyRouter:
  residencyRules:
    - region: EU
      dataTypes: [personalData, financialData]
      allowedEndpoints: [eu-west-1-local, eu-central-1-local]
    - region: CN
      dataTypes: [all]
      allowedEndpoints: [cn-north-1-local]
  fallback: local-only

Schicht 4: Netzwerkrichtlinien-Engine

Die Netzwerkrichtlinien-Engine kontrolliert, auf welche externen Ressourcen ein Agent zugreifen kann. Sie arbeitet als transparenter Proxy, der alle ausgehenden Netzwerkanfragen aus Agent-Sandboxes inspiziert und filtert.

Richtliniendefinition

networkPolicy:
  name: sales-ops-agent
  egress:
    allow:
      - domain: "*.salesforce.com"
        methods: [GET, POST, PATCH]
      - domain: "api.hubspot.com"
        methods: [GET]
      - domain: "smtp.company.com"
        ports: [587]
    deny:
      - domain: "*"  # deny all other outbound traffic
  ingress:
    allow:
      - source: "webhook.salesforce.com"
        path: "/api/v1/events"
  inspection:
    tlsDecrypt: true
    logPayloads: false
    scanForPII: true

Die Netzwerkrichtlinien-Engine unterstützt TLS-Interception für ausgehende Anfragen (mit ordnungsgemäßer Zertifikatsverwaltung) und ermöglicht so das Scannen von Anfragenutzlasten auf versehentliche PII-Lecks.

Alles zusammengefügt

Wenn ein OpenClaw-Agent eine Aufgabe erhält, durchläuft die Anfrage den NemoClaw-Stack wie folgt:

1. 1.OpenClaw empfängt die Aufgabe und erstellt einen Ausführungsplan
2. 2.Privacy Router klassifiziert die Datensensitivität und wählt den geeigneten Modell-Endpunkt
3. 3.Nemotron bewertet den Ausführungsplan anhand von Sicherheitsrichtlinien und klassifiziert die Absicht
4. 4.OpenShell erstellt eine isolierte Sandbox für die Aufgabenausführung
5. 5.Netzwerkrichtlinien-Engine konfiguriert den Netzwerkzugang der Sandbox basierend auf der Rolle des Agenten
6. 6.Der Agent wird innerhalb der Sandbox ausgeführt, wobei jede Aktion auditiert wird
7. 7.Hochrisiko-Aktionen werden zur Genehmigung an menschliche Operatoren eskaliert
8. 8.Ergebnisse werden über den Privacy Router zurückgegeben, wobei PII aus den Logs geschwärzt wird

Diese gesamte Pipeline fügt ungefähr 300 ms Latenz zur ersten Anfrage in einer Sitzung hinzu und unter 100 ms für nachfolgende Anfragen (dank Caching). Für die meisten Unternehmens-Workloads ist dieser Overhead im Vergleich zur Modell-Inferenzzeit vernachlässigbar.

Leistungsbenchmarks

Auf einem einzelnen DGX Spark:

Auf einem DGX H100-Cluster (8 GPUs):

Erste Schritte

Die NemoClaw-Architekturdokumentation ist auf GitHub unter nvidia/nemoclaw verfügbar. Jede Schicht kann unabhängig bereitgestellt werden, sodass Sie NemoClaw schrittweise einführen können — beginnend mit OpenShell-Sandboxing und Hinzufügen der anderen Schichten, wenn Ihre Sicherheitsanforderungen wachsen.

Im nächsten Beitrag führen wir Sie durch ein praktisches Tutorial zur Bereitstellung des vollständigen NemoClaw-Stacks auf einem DGX Spark.