Mergulho Profundo na Arquitetura do NemoClaw

Mergulho Profundo na Arquitetura do NemoClaw

NemoClaw não é um produto único — é uma arquitetura de segurança em camadas projetada para tornar agentes de IA autônomos seguros para implantação em produção. Este artigo percorre cada camada, explica como elas interagem e fornece o contexto técnico necessário para avaliar o NemoClaw para sua própria infraestrutura.

Visão Geral da Arquitetura

A stack do NemoClaw consiste em quatro camadas principais, cada uma abordando uma dimensão diferente da segurança dos agentes:

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

Cada camada opera de forma independente e pode ser implantada separadamente, mas a stack completa fornece defesa em profundidade que nenhuma camada individual pode alcançar sozinha.

Camada 1: Ambiente de Execução de Segurança OpenShell

OpenShell é a base do modelo de segurança do NemoClaw. Ele fornece sandboxing em nível de kernel para a execução de agentes, garantindo que mesmo um agente comprometido não consiga escapar de seu limite de segurança.

Como o OpenShell Funciona

OpenShell usa uma combinação de namespaces do kernel Linux, filtros seccomp-BPF e programas eBPF personalizados da NVIDIA para criar ambientes de execução isolados para cada tarefa do agente:

# 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

Cada chamada de sistema feita pelo agente é interceptada pela camada eBPF do OpenShell, classificada de acordo com a política e, em seguida, permitida, negada ou escalada para aprovação humana. Todo o pipeline de decisão é executado no espaço do kernel, adicionando menos de 50 microssegundos de latência por chamada de sistema.

Fluxos de Aprovação do Operador

Para operações de alto risco — excluir dados, modificar infraestrutura, enviar comunicações externas — OpenShell pode pausar a execução do agente e direcionar a ação para um operador humano para aprovação:

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

Isso garante que os agentes possam operar de forma autônoma em tarefas rotineiras, mantendo a supervisão humana para ações consequentes.

Camada 2: Motor de Políticas Nemotron 120B MoE

O modelo Nemotron 120B Mixture-of-Experts serve como o motor inteligente de avaliação de políticas do NemoClaw. Diferentemente dos sistemas de segurança tradicionais baseados em regras, Nemotron pode compreender a intenção por trás das ações do agente e avaliá-las de acordo com políticas de segurança em linguagem natural.

Classificação de Intenções

Quando um agente solicita uma ação, Nemotron classifica a intenção em múltiplas dimensões:

• •Sensibilidade: Quão sensíveis são os dados envolvidos? (público, interno, confidencial, restrito)
• •Reversibilidade: Esta ação pode ser desfeita? (totalmente reversível, parcialmente reversível, irreversível)
• •Alcance: Quantos sistemas ou usuários são afetados? (individual, equipe, organização, externo)
• •Conformidade: Esta ação se enquadra em algum framework regulatório? (GDPR, HIPAA, SOC 2, PCI-DSS)

A classificação é executada em menos de 200ms em uma única GPU A100 e em menos de 50ms em um DGX Spark com a variante quantizada do modelo.

Políticas em Linguagem Natural

As equipes de segurança podem definir políticas em linguagem natural, que Nemotron interpreta e aplica:

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 converte essas políticas em linguagem natural em regras de segurança executáveis, fechando a lacuna entre a intenção da equipe de segurança e a aplicação técnica.

Camada 3: Privacy Router

O Privacy Router é a camada inteligente de roteamento de modelos do NemoClaw. Ele determina se cada tarefa do agente deve ser processada por um modelo local (Nemotron rodando localmente) ou direcionada para um endpoint de modelo na nuvem, com base na classificação de sensibilidade dos dados.

Lógica de Roteamento

# 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

O Privacy Router mantém um cache de classificação em tempo real, de modo que solicitações repetidas com contexto semelhante são roteadas sem reavaliação. Nos benchmarks, o roteador adiciona menos de 5ms de latência ao pipeline de solicitações.

Conformidade de Residência de Dados

Para organizações que operam sob requisitos de residência de dados (GDPR da UE, PIPL da China, etc.), o Privacy Router pode aplicar restrições de roteamento geográfico:

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

Camada 4: Motor de Políticas de Rede

O Motor de Políticas de Rede controla quais recursos externos um agente pode acessar. Ele opera como um proxy transparente, inspecionando e filtrando todas as solicitações de rede de saída dos sandboxes dos agentes.

Definição de Políticas

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

O Motor de Políticas de Rede suporta interceptação TLS para solicitações de saída (com gerenciamento adequado de certificados), permitindo escanear os payloads das solicitações em busca de vazamentos acidentais de PII.

Unindo Tudo

Quando um agente OpenClaw recebe uma tarefa, a solicitação flui pela stack do NemoClaw da seguinte forma:

1. 1.OpenClaw recebe a tarefa e constrói um plano de execução
2. 2.Privacy Router classifica a sensibilidade dos dados e seleciona o endpoint de modelo apropriado
3. 3.Nemotron avalia o plano de execução contra as políticas de segurança e classifica a intenção
4. 4.OpenShell cria um sandbox isolado para a execução da tarefa
5. 5.Motor de Políticas de Rede configura o acesso à rede do sandbox com base na função do agente
6. 6.O agente é executado dentro do sandbox, com cada ação auditada
7. 7.Ações de alto risco são escaladas para operadores humanos para aprovação
8. 8.Os resultados são retornados através do Privacy Router, com PII redatado dos registros

Todo esse pipeline adiciona aproximadamente 300ms de latência à primeira solicitação de uma sessão e menos de 100ms para solicitações subsequentes (graças ao cache). Para a maioria das cargas de trabalho empresariais, essa sobrecarga é desprezível comparada ao tempo de inferência do modelo.

Benchmarks de Desempenho

Em um único DGX Spark:

Em um cluster DGX H100 (8 GPUs):

Primeiros Passos

A documentação da arquitetura do NemoClaw está disponível no GitHub em nvidia/nemoclaw. Cada camada pode ser implantada de forma independente, para que você possa adotar o NemoClaw de forma incremental — começando pelo sandboxing do OpenShell e adicionando as outras camadas à medida que seus requisitos de segurança evoluem.

No próximo artigo, vamos percorrer um tutorial prático para implantar a stack completa do NemoClaw em um DGX Spark.