OpenShell: O Ambiente de Execução de Segurança por Trás do NemoClaw

OpenShell: O Ambiente de Execução de Segurança por Trás do NemoClaw

Se o NemoClaw é a stack de segurança, o OpenShell é sua base. Desenvolvido pela equipe de engenharia de segurança da NVIDIA nos últimos 18 meses, o OpenShell fornece sandboxing em nível de kernel para a execução de agentes de IA — garantindo que mesmo um agente completamente comprometido não consiga acessar recursos fora de seu limite de segurança definido.

Este artigo é um mergulho técnico profundo na arquitetura do OpenShell, seus mecanismos de isolamento e como ele aplica políticas de segurança com sobrecarga mínima de desempenho.

Por Que Isolamento em Nível de Kernel?

O sandboxing tradicional de aplicações — containers, VMs, isolamento em nível de processo — foi projetado para software que se comporta de forma previsível. Os agentes de IA são fundamentalmente diferentes. Eles geram seus próprios planos de execução em tempo real, fazem chamadas a ferramentas que interagem com sistemas externos e podem produzir comportamentos inéditos que nenhuma suíte de testes antecipou.

Essa imprevisibilidade exige um modelo de segurança que opere no nível mais baixo possível: o kernel. O OpenShell intercepta cada chamada de sistema que um processo de agente faz, classifica-a de acordo com a política de segurança ativa e toma uma decisão de permitir/negar antes que a chamada chegue ao kernel.

Agent Process
     │
     ▼
OpenShell eBPF Layer  ←── Policy Engine
     │
     ├── ALLOW → System Call → Kernel
     │
     ├── DENY → Error returned to agent
     │
     └── ESCALATE → Human approval queue

eBPF: A Tecnologia por Trás do OpenShell

O OpenShell é construído sobre eBPF (extended Berkeley Packet Filter), uma tecnologia do kernel Linux que permite executar programas personalizados no espaço do kernel sem modificar o próprio kernel. A equipe da NVIDIA escreveu um conjunto de programas eBPF especificamente otimizados para cargas de trabalho de agentes de IA:

Interceptor de Chamadas de Sistema

O interceptor de chamadas de sistema se conecta ao tracepoint sys_enter e avalia cada chamada de sistema contra a política ativa:

// Simplified OpenShell eBPF syscall interceptor
SEC("tracepoint/raw_syscalls/sys_enter")
int openshell_syscall_enter(struct trace_event_raw_sys_enter *ctx) {
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    struct sandbox_policy *policy = bpf_map_lookup_elem(&sandbox_policies, &pid);

    if (!policy)
        return 0;  // Not a sandboxed process

    long syscall_nr = ctx->id;
    int decision = evaluate_policy(policy, syscall_nr, ctx->args);

    if (decision == DENY) {
        // Send event to userspace audit log
        emit_security_event(pid, syscall_nr, DENY);
        // Override return value to -EPERM
        bpf_override_return(ctx, -EPERM);
    } else if (decision == ESCALATE) {
        // Pause the process and notify approval queue
        emit_approval_request(pid, syscall_nr, ctx->args);
        send_signal(pid, SIGSTOP);
    }

    return 0;
}

Guardião do Sistema de Arquivos

O guardião do sistema de arquivos restringe quais arquivos e diretórios um agente pode acessar. Ele opera sobre operações VFS (Virtual Filesystem), interceptando chamadas open, read, write, unlink e rename:

# Filesystem policy for a customer support agent
filesystem:
  # Agent can read its own configuration
  - path: "/etc/nemoclaw/agent.yaml"
    permissions: [read]

  # Agent can read/write to its workspace
  - path: "/var/nemoclaw/workspace/**"
    permissions: [read, write, create]

  # Agent can read shared data
  - path: "/var/nemoclaw/shared/**"
    permissions: [read]

  # Everything else is denied by default
  defaultAction: deny

Sentinela de Rede

O sentinela de rede se conecta às operações de socket para controlar o acesso à rede do agente no nível de conexão:

SEC("cgroup/connect4")
int openshell_connect4(struct bpf_sock_addr *ctx) {
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    struct network_policy *policy = bpf_map_lookup_elem(&net_policies, &pid);

    if (!policy)
        return 1;  // Allow non-sandboxed processes

    __be32 dst_ip = ctx->user_ip4;
    __be16 dst_port = ctx->user_port;

    if (!is_allowed_destination(policy, dst_ip, dst_port)) {
        emit_security_event(pid, NETWORK_BLOCKED, dst_ip, dst_port);
        return 0;  // Block connection
    }

    return 1;  // Allow connection
}

Arquitetura de Aplicação de Políticas

As políticas do OpenShell são compiladas em bytecode eBPF para máxima velocidade de aplicação. O pipeline de compilação funciona da seguinte forma:

1. 1.Os arquivos de política YAML são escritos pelas equipes de segurança em formato legível
2. 2.O compilador de políticas converte o YAML em uma representação intermediária (IR)
3. 3.O validador de políticas Nemotron verifica a IR quanto a consistência lógica e conflitos
4. 4.O compilador eBPF gera bytecode verificado que é carregado no kernel
5. 5.O verificador em tempo de execução garante que os programas eBPF terminam e são seguros em memória

Todo o pipeline de compilação é executado em menos de 2 segundos para conjuntos de políticas típicos, e as políticas podem ser recarregadas a quente sem reiniciar o agente.

# Compile and load a policy
nemoclaw policy compile policies/customer-support.yaml
nemoclaw policy load customer-support

# Hot-reload a modified policy (no agent restart required)
nemoclaw policy reload customer-support

# Verify policy is active
nemoclaw policy status
# Output:
# POLICY              STATUS    LOADED AT            RULES
# customer-support    active    2026-03-19 14:30:01  47
# network-default     active    2026-03-19 14:30:01  12
# filesystem-strict   active    2026-03-19 14:30:01  23

Fluxos de Aprovação do Operador

Uma das características mais distintivas do OpenShell é seu sistema integrado de aprovação do operador. Quando um agente tenta uma ação classificada como de alto risco, o OpenShell pausa a execução do agente e direciona a solicitação de aprovação para um operador humano.

Como a Aprovação Funciona

1. 1.O agente tenta uma chamada de sistema de alto risco (p. ex., escrever em um arquivo protegido, conectar a um endpoint não aprovado)
2. 2.O programa eBPF do OpenShell envia SIGSTOP ao processo do agente
3. 3.Uma solicitação de aprovação é gerada e enviada pelo canal configurado (Slack, Teams, PagerDuty, e-mail)
4. 4.O operador revisa o contexto da solicitação e aprova ou nega
5. 5.Se aprovado, o OpenShell envia SIGCONT para retomar o agente; se negado, retorna EPERM

A solicitação de aprovação inclui o contexto completo:

{
  "request_id": "apr-2026031914-00042",
  "agent": "customer-support-agent-01",
  "action": "email.send",
  "target": "[email protected]",
  "context": {
    "ticket_id": "TKT-12345",
    "customer_name": "[REDACTED]",
    "reason": "Agent wants to send a follow-up email to the customer regarding their refund request",
    "email_preview": "Dear Customer, your refund of $250 has been processed..."
  },
  "risk_level": "medium",
  "policy_rule": "external-communication-requires-approval",
  "timestamp": "2026-03-19T14:30:42Z"
}

Timeout e Ações Padrão de Aprovação

Os operadores podem configurar o que acontece quando uma aprovação expira:

approvalConfig:
  timeout: 15m
  onTimeout: deny          # deny | allow | escalate
  onEscalate:
    target: security-team
    channel: pagerduty
  maxPendingApprovals: 10  # Queue limit per agent
  autoApprove:
    # Automatically approve if the same action was approved
    # 3 times in the past 24 hours for this agent
    repeatThreshold: 3
    repeatWindow: 24h

Características de Desempenho

O OpenShell é projetado para cargas de trabalho em produção onde a latência importa. Estas são as sobrecargas medidas em um DGX Spark:

Para comparação, uma chamada típica de inferência LLM leva de 500ms a 5000ms, então a sobrecarga do OpenShell é desprezível no contexto de cargas de trabalho de agentes.

Comparação com Sandboxing Existente

O diferencial chave do OpenShell é que ele foi projetado desde o início para cargas de trabalho de agentes de IA, com suporte integrado para políticas em linguagem natural, fluxos de aprovação humana e avaliação de políticas acelerada por GPU.

Primeiros Passos com o OpenShell

O OpenShell pode ser usado de forma independente, sem o resto da stack do NemoClaw:

# Install OpenShell standalone
curl -fsSL https://github.com/NVIDIA/OpenShell | bash

# Create a minimal sandbox policy
cat > my-policy.yaml << 'EOF'
apiVersion: openshell.nvidia.com/v1
kind: SandboxPolicy
metadata:
  name: my-first-sandbox
spec:
  isolation:
    network: restricted
    filesystem: workspace-only
    syscalls: minimal
EOF

# Run any process inside the sandbox
openshell run --policy my-policy.yaml -- python my_agent.py

O OpenShell é código aberto sob Apache 2.0 e está disponível em nvidia/openshell no GitHub. No próximo artigo, exploraremos cenários reais de implantação empresarial para a stack completa do NemoClaw.