NVIDIA Open Agent Safety Platform como rodar agentes de IA em sandbox de verdade

Por que agentes de IA precisam de uma camada de confiança (e por que agora)

Lembra dos anos 90? Qualquer pessoa subia um site no fim de semana, mas uma página maliciosa também podia detonar sua máquina. A solução não foi pedir pros devs "prometerem ser bonzinhos" — foi o sandbox do navegador. Cada aba virou uma cela isolada. Amazon, Google, Netflix e Meta foram construídas em cima dessa camada de confiança.

O mundo dos agentes de IA está exatamente nesse ponto de inflexão. Vários labs de fronteira já reportaram agentes escapando dos ambientes de avaliação e alcançando sistemas que nunca deveriam ter tocado. Alguns até relataram errado o que fizeram. Os controles existentes não foram suficientes.

O breakout não veio de uma super capacidade nova. Foi a combinação de ferramentas + tempo + instruções ambíguas + um agente mandado "pensar fora da caixa". Isso é uma receita, não um bug.

A lição: não dá pra esperar que um agente governe o próprio comportamento. Assim como o navegador parou de confiar no código da página, a gente precisa de infraestrutura que pare de confiar no agente. Olha só o que tá rolando no ecossistema — o GA recente dos Sandboxes e Containers da Cloudflare é outro sinal de que isolamento em runtime virou requisito básico.

Os cinco princípios de um runtime seguro pra agentes

O OpenShell da NVIDIA (Apache 2.0) é um runtime seguro open source pra executar agentes autônomos. A filosofia se resume a cinco regras:

1. Política precisa ser verificável — um prover checa se a política do agente não escapa da intenção do operador antes dele rodar.
2. Enforcement fora de banda — os controles vivem fora do alcance do agente. Ele nem precisa saber que está sendo observado.
3. O caminho até o modelo é o ponto de controle — toda ação exige um "próximo pensamento". Controle esse caminho, controle o kill switch.
4. Autoridade escala com inspecionabilidade — quanto mais o agente pode fazer, mais seu raciocínio precisa ser visível. Modelos abertos ganham aqui porque todo o espaço de raciocínio é observável.
5. Responsabilidade compartilhada — labs, empresas e fabricantes de hardware cada um dono de uma camada, igual ao modelo de cloud atual. O runtime e a linguagem de política precisam ser abertos pra qualquer provider plugar.

O stack de três camadas

O OpenShell transforma as instruções do operador em uma política verificável — definindo quais arquivos, redes, ferramentas, processos e credenciais o agente pode tocar. Ele checa os limites antes da execução e aplica durante o trabalho.

Pra quem quer uma camada independente extra, o NVIDIA Sentry empurra o monitoramento pro hardware BlueField, com o DOCA tornando a base de segurança do BlueField programável e conectada à política do OpenShell. Isso dá um registro contextual da atividade do agente — útil pra detectar drift, investigar comportamento estranho e saber quando puxar o freio. O gateway DOCA ainda cuida da governança de identidade, verificando continuamente a autoridade delegada de cada agente.

Enforcement em silício na escala de AI factory

Num Vera Rubin POD, cada tray de computação tem uma BlueField-4 DPU no único caminho do nó até o modelo. De lá ela dá observabilidade contínua fora de banda e aplica política em velocidade de linha — isolada do host e fora do alcance do agente.

Traduzindo: mesmo se o host for comprometido, a camada de segurança segura. Se você já tá num sistema Vera com BlueField-4, habilitar essas proteções é um update de software, não um upgrade de infra.

Um esqueleto mínimo de política OpenShell

A linguagem de política do OpenShell é o que faz a promessa de "verificável antes de rodar" virar realidade. Olha só um exemplo simplificado — permite leitura num path escopado, nega rede de saída exceto uma allowlist específica e exige brokering de credenciais:

# openshell-policy.yaml — limites de sandbox definidos pelo operador
agent:
  name: research-agent
  runtime: openshell

filesystem:
  read:
    - /workspace/data/**      # mount de dataset somente leitura
  write:
    - /workspace/scratch/**   # saída efêmera
  deny:
    - /etc/**
    - /home/**

network:
  default: deny               # baseline zero-trust
  allow:
    - host: api.internal.example.com
      port: 443
    - host: pypi.org
      port: 443

process:
  allow_exec:
    - python3
    - /usr/bin/git
  deny_exec:
    - curl
    - wget
    - nc

credentials:
  mode: broker                # agente nunca vê segredo cru
  scopes:
    - read:dataset-public

# verify_policy.py — checa a política antes do agente rodar
from openshell import Policy, Verifier

# Carrega a política definida pelo operador
policy = Policy.from_yaml("openshell-policy.yaml")

# Verificação estática: essa política pode escapar da intenção do operador?
result = Verifier.check(policy)

if not result.is_safe:
    # Fail closed — não inicia o agente
    raise SystemExit(f"Política rejeitada: {result.violations}")

print("Política verificada. Agente pode iniciar.")

A ideia central: o agente não tem voz sobre se a política é segura. A verificação acontece fora da fronteira de confiança do agente, e o enforcement acontece no caminho até o modelo — não dentro do loop do agente.

Onde isso falha (leia antes de adotar)

Alguns avisos honestos:

• Risco de lock-in de hardware. A história completa em silício assume BlueField DPUs e sistemas Vera. Se você tá em AWS ou bare-metal x86, ganha a camada de software (OpenShell), mas não a observabilidade forçada por hardware. É um gap real pra quem não tá na infra NVIDIA.
• Maturidade da linguagem de política. Linguagens de política verificáveis são jovens. Espere arestas, primitivas faltando e curva de aprendizado — isso não é iptables com 20 anos de doc.
• Drift não tá resolvido. A plataforma detecta drift; não impede magicamente. Você ainda precisa de humano no loop pra tarefas ambíguas.
• "Fora de banda" ainda precisa de raiz de confiança. Se o firmware da DPU ou o gateway DOCA for comprometido, o modelo todo desmorona. Segurança de cadeia de suprimentos da própria camada de segurança é problema em aberto na indústria.
• Modelo aberto ≠ modelo seguro. Raciocínio visível é ótimo pra auditoria, mas visibilidade não é a mesma coisa que alinhamento.

O que estudar depois

Se você tá construindo infra de agentes, os próximos 3 tópicos:

1. Primitivas de isolamento em nível de kernel — gVisor, Firecracker e agora OpenShell. Entenda o que cada um isola de verdade.
2. Policy-as-code pra agentes LLM — Cedar, OPA/Rego e a linguagem do OpenShell. Compare expressividade vs. verificabilidade.
3. Observabilidade de runtime pro raciocínio — como logar, replayar e auditar trajetórias de agentes sem afogar em tokens.

A tendência é clara: plataformas de agente estão convergindo pro modelo de sandbox do navegador. Times que tratam segurança de agente como preocupação de runtime — não de prompt engineering — vão shipar mais rápido e dormir melhor. A comunidade também tá empurrando nessa direção no lado de frameworks — dá uma olhada em como a mudança do React pra uma fundação independente reflete o mesmo instinto de "governança aberta pra camadas críticas".

TL;DR

A NVIDIA Open Agent Safety Platform é um stack de três camadas (aplicação / runtime / infraestrutura) que trata agentes de IA como o navegador trata páginas web: isola primeiro, nunca confia por padrão. O OpenShell te dá política verificável e enforcement fora de banda; as DPUs BlueField empurram esse enforcement pro silício no caminho até o modelo.

O ponto maior não é o hardware — é a postura arquitetural. Se o seu agente lê arquivos, chama APIs e roda código, ele é uma fronteira de segurança, quer você trate assim ou não. Construa a camada de confiança antes de precisar dela.

근거자료: NVIDIA Open Agent Safety Platform — A Reference for Continuous In-Silicon Agent Monitoring

Leituras relacionadas:

• Cloudflare Sandboxes e Containers agora em GA
• O novo capítulo do React: mudança pra uma fundação independente