Agentes de IA sob controle com NVIDIA OpenShell

Como o NVIDIA OpenShell controla o acesso de agentes de IA

O OpenShell é um runtime de código aberto: o ambiente que executa um agente e controla seu acesso. Ele funciona como uma camada abaixo do agente, sem substituir seu raciocínio ou suas ferramentas.

Pense em um prestador de serviços trabalhando dentro de um prédio. Você oferece uma oficina, acesso a determinadas salas e autorização para ligar para certos fornecedores. Não entrega a chave mestra só porque a descrição do trabalho diz “tenha cuidado”. O OpenShell estabelece esses limites para agentes de software.

A visão geral do runtime descreve restrições ao sistema de arquivos, à rede e aos processos, além de proteção das credenciais dos provedores. Landlock é o mecanismo do kernel Linux que limita o acesso a arquivos; seccomp restringe chamadas de sistema, as solicitações de baixo nível que um programa faz ao sistema operacional. A aplicação dessas regras acontece fora do raciocínio do agente.

O gateway gerencia os sandboxes e o acesso. Um supervisor externo ao sandbox verifica as requisições de saída conforme a política e fornece credenciais quando há permissão. O verificador de políticas confere se as permissões modeladas respeitam os limites definidos. Esses controles determinam o que um agente pode fazer; não garantem que o trabalho autorizado esteja correto.

A NVIDIA lista opções para Claude Code, Codex, GitHub Copilot CLI, Hermes, LangChain Deep Agents, OpenClaw e OpenCode, além de agentes e imagens personalizados. “Compatível” não significa que todas as ferramentas venham instaladas: atualmente, a carga de trabalho padrão é uma imagem mínima do Ubuntu sem as CLIs dos agentes, os programas de linha de comando usados para iniciá-los.

Para a operação, a mudança está no reaproveitamento das permissões. Sem um limite reutilizável, cada novo fluxo com agentes pode exigir outra rodada de decisões sobre quais arquivos, segredos e serviços expor. Com esse limite, a equipe pode empacotar essas decisões junto com a carga de trabalho e revisar as mudanças. Meça o efeito em horas de engenharia gastas na configuração de acesso e em interrupções; não existe um número universal verificado de economia de tempo para usar como referência.

Onde o OpenShell roda hoje

Use a matriz de compatibilidade atual para escolher o host. Este guia segue a documentação identificada como v0.1.7, consultada em 8 de novembro de 2026.

O WSL 2 executa um ambiente Linux no Windows. O MXC é uma alternativa separada de isolamento nativo no Windows. Não trate “suporte ao Windows” como se fosse uma única forma de instalação intercambiável.

O anúncio da colaboração para Windows descreve a chegada do OpenShell ao Windows por meio do MXC. Essa direção da plataforma não transforma a opção nativa em um instalador estável convencional hoje. A documentação de instalação atual afirma explicitamente que os canais padrão de distribuição não fornecem binários nativos para Windows.

Para uma primeira avaliação, escolha uma configuração compatível de Linux ou Apple Silicon. A matriz de compatibilidade também especifica os requisitos de kernel e runtime: o Linux 6.2 introduziu a ABI do Landlock exigida, mas a versão do kernel, sozinha, não basta. O runtime precisa passar pelas verificações necessárias. Na opção com Docker Desktop no macOS, esses recursos do Linux rodam dentro da máquina virtual Linux. CPUs NVIDIA Vera não são obrigatórias.

Instale a CLI e execute seu primeiro agente

Comece pelo exemplo com OpenCode documentado pela NVIDIA. Ele deixa claros os três ingredientes: um provedor para acesso ao serviço, uma imagem que contenha o agente e um sandbox para executá-lo. As etapas abaixo se baseiam na documentação; não representam um teste local.

1. Prepare o host e instale o OpenShell. Na opção com Docker, mantenha o Docker Desktop em execução ou use Docker Engine 28.0 ou posterior. No Linux ou macOS compatível, o guia de instalação usa curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh. Revise o instalador antes de executá-lo. Ele instala a CLI, o verificador de políticas e o gateway local. Execute openshell status para confirmar que a CLI consegue se conectar ao gateway.

2. Configure o serviço de modelos. O exemplo usa OpenRouter. Defina OPENROUTER_API_KEY no ambiente do host antes de criar o provedor. Um perfil de provedor descreve os endpoints de serviço e os caminhos de executáveis permitidos; o provedor armazena as credenciais. O perfil de exemplo da NVIDIA permite que /usr/local/bin/opencode acesse openrouter.ai.

3. Importe o perfil, crie o provedor e inicie a imagem. Execute estes comandos no host, nesta ordem:

openshell profile import \
  --url https://raw.githubusercontent.com/NVIDIA/OpenShell/main/providers/openrouter.yaml
openshell provider create \
  --name openrouter --type openrouter --from-existing
openshell sandbox create \
  --name my-agent \
  --from ghcr.io/anomalyco/opencode:latest \
  --provider openrouter \
  -- opencode -m openrouter/nvidia/nemotron-3.5-lightning:free

A imagem fornece o OpenCode; o comando depois de -- o inicia como processo principal. O guia do primeiro agente usa esse modelo gratuito sem exigir créditos no OpenRouter. Essa é a escolha de modelo do exemplo, não uma promessa de que qualquer uso de modelos seja gratuito.

4. Revise as solicitações de acesso pelo host. Quando um agente tenta acessar um destino não aprovado, o OpenShell nega a requisição e prepara uma proposta de regra com escopo restrito. Execute openshell rule get my-agent --status pending. Se a proposta corresponder ao acesso previsto para a tarefa, aprove especificamente essa proposta com openshell rule approve my-agent --chunk-id <chunk-id>, substituindo o marcador pelo ID real. A regra é recarregada e o agente pode tentar novamente.

5. Confira as permissões que você realmente concedeu. Execute openshell policy get my-agent --base e, em seguida, openshell policy get my-agent --full. O primeiro mostra a política base; o segundo inclui as regras acrescentadas pelos provedores. Revise as permissões efetivas antes de adicionar um projeto real ou um serviço sensível.

Ao terminar uma avaliação descartável, exclua o sandbox com openshell sandbox delete my-agent.

Quais políticas podem mudar durante a execução?

O acesso à rede pode mudar durante uma tarefa. Já os limites do sistema de arquivos e dos processos exigem a criação de um novo sandbox.

A mudança durante a execução também tem consequências. Novas regras de rede fecham conexões abertas sob as regras anteriores, então os clientes precisam se reconectar. Registrar um novo serviço externo de middleware exige configurar e reiniciar o gateway. Adicionar um caminho do sistema de arquivos à política salva não libera esse caminho para a carga de trabalho já em execução; remover caminhos ou mudar configurações de inicialização é rejeitado depois que ela começa. O guia de gerenciamento de políticas detalha essas diferenças.

Há outra armadilha: a ausência de um arquivo de política não significa ausência de acesso. Uma política pode vir da imagem, de uma configuração de ambiente ou de uma política global do gateway. Provedores vinculados podem acrescentar regras de rede. As regras de seleção de políticas também deixam claro que uma política global substitui a política do próprio sandbox; ela não é apenas uma camada restritiva adicional.

Uma política clara para agentes de programação

Dê a um agente de correção de bugs um diretório de projeto com permissão de escrita e acesso somente de leitura à API antes de autorizá-lo a publicar mudanças.

Esta política ilustrativa considera uma imagem preparada para programação, com o projeto em /workspace e curl instalado em /usr/bin/curl. Salve-a como policy.yaml e passe --policy ./policy.yaml ao criar um novo sandbox. É um modelo para essa organização da imagem, não uma substituição pronta para qualquer imagem de agente:

version: 1
filesystem_policy:
  include_workdir: false
  read_only: [/usr, /lib, /etc]
  read_write: [/workspace, /tmp]
landlock:
  compatibility: hard_requirement
network_policies:
  github_readonly:
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/curl

O agente pode editar o projeto e os arquivos temporários. A regra de rede permite que o executável indicado faça requisições GET, HEAD e OPTIONS à API do GitHub. Ela não dá acesso à internet para qualquer programa, não autoriza o download de pacotes e não permite Git push. O provedor de modelos é configurado separadamente.

Prepare os diretórios de estado graváveis de que o agente precisa na imagem e adicione-os de forma deliberada. Esses caminhos se referem ao sistema de arquivos do sandbox. Não suponha que um diretório com nome semelhante no host fique automaticamente disponível. Além disso, caminhos básicos do sistema de arquivos são adicionados a cargas de trabalho com acesso à rede; portanto, esse YAML curto não significa que o limite efetivo contenha apenas os caminhos listados nele.

Duas configurações merecem atenção. hard_requirement impede a inicialização se as regras de sistema de arquivos definidas pelo usuário não puderem ser aplicadas, embora caminhos individuais inexistentes ou inacessíveis ainda possam ser ignorados. enforcement: enforce bloqueia requisições inspecionadas que não são permitidas; o modo padrão do esquema, audit, registra as violações e permite essas requisições. Consulte a referência do esquema de políticas antes de adaptar o modelo.

Teste tanto a permissão quanto a recusa. O tutorial de políticas de rede da NVIDIA verifica se curl -s https://api.github.com/zen funciona com a regra de somente leitura e, depois, confirma que um POST é negado. Consulte openshell logs my-agent --since 5m --source sandbox pelo host. No seu projeto, teste também uma escrita de arquivo prevista e um acesso a arquivo fora do escopo. Iniciar o agente com sucesso não é o teste de aceitação de uma política de segurança.

Cinco fluxos de trabalho para experimentar primeiro

Os melhores usos iniciais têm limites claros para a tarefa e uma pessoa capaz de avaliar o resultado. Em ordem de provável valor operacional:

Nenhum desses fluxos garante que o código gerado esteja correto ou que o diagnóstico de um incidente seja confiável. O valor está em limitar o que pode acontecer enquanto o agente trabalha. Para uma seleção mais ampla de ferramentas, consulte Melhores ferramentas de segurança de sandbox para IA em 2026; para escolher plataformas de execução, veja Melhores sandboxes de código para agentes de IA em 2026.

Duas oportunidades de produto em torno do OpenShell

A oportunidade mais forte é um kit de adoção de agentes de programação para equipes. O comprador é um líder de plataforma que quer colocar os desenvolvedores para produzir dentro de um ambiente aprovado. O DataForSEO estima 1,300 buscas mensais por “claude code sandbox” no mercado retornado pela consulta desta execução. Isso indica interesse na configuração, não 1,300 clientes em potencial; além disso, parte das pessoas procura o sandbox do próprio agente, e não o OpenShell.

A menor versão vendável poderia oferecer suporte a um agente e a uma configuração de host aprovada: uma imagem preparada, uma política revisada, um checklist de configuração do provedor e testes repetíveis de permissão e bloqueio. Venda uma implantação funcional para a equipe, com responsabilidades claras pelas atualizações. O desafio é a manutenção: caminhos nas imagens, comportamento dos agentes e interfaces experimentais podem mudar. Converse com líderes de plataforma sobre esse trabalho de manutenção antes de criar um produto hospedado.

Uma bancada de revisão de políticas é a segunda oportunidade. Equipes de segurança poderiam usá-la para visualizar o que uma política efetiva permite, comparar alterações e registrar aprovações. O DataForSEO estima 480 buscas mensais por “ai agent security”, com 70 por “ai agent security tools”. Essas consultas separadas são sinais amplos de demanda; não some seus volumes como se representassem compradores únicos.

Um MVP poderia importar políticas base e efetivas, destacar novos destinos e permissões de requisição e anexar resultados de testes a um registro de revisão. O desafio é se diferenciar: o OpenShell já oferece análise de políticas, propostas e logs. O produto precisa melhorar o processo de revisão da equipe, em vez de apenas colocar os comandos existentes em um painel. Comece pelo kit de adoção, pois é mais fácil definir seu comprador e sua entrega.

O que o OpenShell não resolve

O OpenShell limita o acesso; ele não decide se uma ação permitida é uma boa decisão de negócio. Um agente autorizado a escrever nos arquivos do projeto ainda pode produzir um patch ruim. Um destino externo aprovado ainda pode receber os dados que sua política permite enviar. O acesso a arquivos e a aprovação de endpoints precisam refletir o que você realmente pretende expor.

Ele também não substitui sistemas de identidade, cofres de segredos, monitoramento ou governança. O anúncio de controles de runtime da NVIDIA posiciona a aplicação das regras fora da carga de trabalho do agente. Trate isso como parte do sistema ao redor, não como motivo para descartar o restante.

O projeto agora tem versões estáveis voltadas à produção dentro de sua matriz de compatibilidade; por isso, seria enganoso chamar todo o OpenShell de demonstração experimental. Os limites são mais específicos: interfaces experimentais podem mudar em versões de correção, o Windows nativo continua em desenvolvimento e a NVIDIA afirma que seu perfil atual de qualificação não cobre toda a política de qualificação de versões. Fixe as versões implantadas e valide a combinação exata de carga de trabalho e host.

Ação para segunda-feira: peça ao líder de plataforma que escolha um repositório sem dados sensíveis e um agente. Instale em um host compatível, prepare a imagem, defina o acesso a arquivos e à rede e teste uma operação permitida e outra bloqueada. Registre o tempo de configuração e as horas de engenharia gastas com interrupções ao longo da primeira semana. Só amplie o uso depois que a equipe conseguir explicar cada permissão concedida.

Se você quer incorporar isso ao fluxo da sua equipe, podemos ajudar a implementar os controles de produção.