Głębokie zanurzenie w architekturę NemoClaw

Głębokie zanurzenie w architekturę NemoClaw

NemoClaw to nie pojedynczy produkt — to warstwowa architektura bezpieczeństwa zaprojektowana, aby uczynić autonomicznych agentów AI bezpiecznymi dla wdrożeń produkcyjnych. Ten wpis przechodzi przez każdą warstwę, wyjaśnia ich wzajemne interakcje i dostarcza kontekst techniczny potrzebny do oceny NemoClaw dla Twojej infrastruktury.

Przegląd architektury

Stos NemoClaw składa się z czterech głównych warstw, z których każda odpowiada za inny wymiar bezpieczeństwa agentów:

┌─────────────────────────────────────────────┐
│              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)             │
└─────────────────────────────────────────────┘

Każda warstwa działa niezależnie i może być wdrożona samodzielnie, ale pełny stos zapewnia obronę warstwową, której żadna pojedyncza warstwa nie jest w stanie osiągnąć.

Warstwa 1: Środowisko bezpieczeństwa OpenShell

OpenShell to fundament modelu bezpieczeństwa NemoClaw. Zapewnia izolację na poziomie jądra dla wykonywania agentów, gwarantując, że nawet skompromitowany agent nie może uciec poza swoje granice bezpieczeństwa.

Jak działa OpenShell

OpenShell wykorzystuje kombinację przestrzeni nazw jądra Linux, filtrów seccomp-BPF oraz niestandardowych programów eBPF od NVIDIA do tworzenia izolowanych środowisk wykonawczych dla każdego zadania agenta:

# 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

Każde wywołanie systemowe wykonane przez agenta jest przechwytywane przez warstwę eBPF OpenShell, klasyfikowane zgodnie z polityką i następnie dopuszczane, odrzucane lub eskalowane do zatwierdzenia przez człowieka. Cały potok decyzyjny działa w przestrzeni jądra, dodając mniej niż 50 mikrosekund opóźnienia na każde wywołanie systemowe.

Procesy zatwierdzania przez operatora

Dla operacji o wysokim ryzyku — usuwanie danych, modyfikacja infrastruktury, wysyłanie komunikacji zewnętrznej — OpenShell może wstrzymać wykonywanie agenta i przekierować akcję do operatora-człowieka w celu zatwierdzenia:

// 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',
};

To zapewnia, że agenci mogą działać autonomicznie przy rutynowych zadaniach, zachowując jednocześnie nadzór ludzki nad istotnymi działaniami.

Warstwa 2: Silnik polityk Nemotron 120B MoE

Model Nemotron 120B Mixture-of-Experts służy jako inteligentny silnik oceny polityk NemoClaw. W przeciwieństwie do tradycyjnych systemów bezpieczeństwa opartych na regułach, Nemotron potrafi zrozumieć intencję stojącą za działaniami agenta i ocenić ją zgodnie z politykami bezpieczeństwa opisanymi w języku naturalnym.

Klasyfikacja intencji

Gdy agent żąda wykonania akcji, Nemotron klasyfikuje intencję w wielu wymiarach:

• •Wrażliwość: Jak wrażliwe są zaangażowane dane? (publiczne, wewnętrzne, poufne, zastrzeżone)
• •Odwracalność: Czy tę akcję można cofnąć? (w pełni odwracalna, częściowo odwracalna, nieodwracalna)
• •Zakres: Ile systemów lub użytkowników jest dotkniętych? (pojedynczy, zespół, organizacja, zewnętrzni)
• •Zgodność: Czy ta akcja podlega jakimkolwiek ramom regulacyjnym? (GDPR, HIPAA, SOC 2, PCI-DSS)

Klasyfikacja wykonuje się w mniej niż 200 ms na pojedynczym GPU A100 i w mniej niż 50 ms na DGX Spark z kwantyzowanym wariantem modelu.

Polityki w języku naturalnym

Zespoły bezpieczeństwa mogą definiować polityki w zwykłym języku angielskim, które Nemotron interpretuje i egzekwuje:

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 konwertuje te polityki w języku naturalnym na wykonywalne reguły bezpieczeństwa, wypełniając lukę między intencjami zespołu bezpieczeństwa a egzekwowaniem technicznym.

Warstwa 3: Privacy Router

Privacy Router to warstwa inteligentnego routingu modeli w NemoClaw. Określa, czy każde zadanie agenta powinno być przetwarzane przez lokalny model (Nemotron działający lokalnie) czy przekierowane do punktu końcowego modelu w chmurze, na podstawie klasyfikacji wrażliwości danych.

Logika routingu

# 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

Privacy Router utrzymuje pamięć podręczną klasyfikacji w czasie rzeczywistym, dzięki czemu powtarzane żądania o podobnym kontekście są routowane bez ponownej oceny. W testach wydajnościowych router dodaje mniej niż 5 ms opóźnienia do potoku żądań.

Zgodność z wymaganiami lokalizacji danych

Dla organizacji działających w warunkach wymagań dotyczących lokalizacji danych (GDPR UE, PIPL Chin itp.), Privacy Router może wymuszać geograficzne ograniczenia routingu:

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

Warstwa 4: Silnik polityk sieciowych

Silnik polityk sieciowych kontroluje, do jakich zewnętrznych zasobów agent może uzyskać dostęp. Działa jako przezroczyste proxy, inspekując i filtrując wszystkie wychodzące żądania sieciowe z sandboxów agentów.

Definicja polityki

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

Silnik polityk sieciowych obsługuje przechwytywanie TLS dla żądań wychodzących (z odpowiednim zarządzaniem certyfikatami), umożliwiając skanowanie treści żądań pod kątem przypadkowych wycieków danych osobowych.

Składając wszystko razem

Gdy agent OpenClaw otrzymuje zadanie, żądanie przepływa przez stos NemoClaw w następujący sposób:

1. 1.OpenClaw otrzymuje zadanie i konstruuje plan wykonania
2. 2.Privacy Router klasyfikuje wrażliwość danych i wybiera odpowiedni punkt końcowy modelu
3. 3.Nemotron ocenia plan wykonania zgodnie z politykami bezpieczeństwa i klasyfikuje intencję
4. 4.OpenShell tworzy izolowany sandbox dla wykonania zadania
5. 5.Silnik polityk sieciowych konfiguruje dostęp sieciowy sandboxa na podstawie roli agenta
6. 6.Agent wykonuje zadanie w sandboxie, przy czym każde działanie jest rejestrowane w audycie
7. 7.Działania o wysokim ryzyku są eskalowane do operatorów-ludzi do zatwierdzenia
8. 8.Wyniki są zwracane przez Privacy Router, z redakcją danych osobowych z logów

Cały ten potok dodaje około 300 ms opóźnienia do pierwszego żądania w sesji i poniżej 100 ms dla kolejnych żądań (dzięki buforowaniu). Dla większości obciążeń korporacyjnych te narzuty są pomijalne w porównaniu z czasem inferencji modelu.

Testy wydajności

Na pojedynczym DGX Spark:

Na klastrze DGX H100 (8 GPU):

Pierwsze kroki

Dokumentacja architektury NemoClaw jest dostępna na GitHub pod adresem nvidia/nemoclaw. Każda warstwa może być wdrożona niezależnie, więc możesz adoptować NemoClaw stopniowo — zaczynając od sandboxingu OpenShell i dodając kolejne warstwy w miarę wzrostu wymagań bezpieczeństwa.

W następnym wpisie przeprowadzimy praktyczny poradnik wdrażania pełnego stosu NemoClaw na DGX Spark.