Um container é uma sala — não um sistema de permissões
Agentes de IA apresentam um novo risco substancial: desenvolvedores concedem rotineiramente a ferramentas como o Claude Code ou Codex amplo acesso a repositórios sensíveis, APIs e credenciais, e então os deixam rodar sem supervisão. Essa conveniência muitas vezes custa a segurança, já que a utilidade de um agente está diretamente ligada ao seu acesso a recursos críticos.
Containers comuns, embora eficazes no isolamento do host, não conseguem diferenciar ações sutis. Uma conexão com o GitHub, por exemplo, permite tanto a leitura de dados quanto a realização de alterações destrutivas. O container vê apenas o tráfego para o mesmo endereço, incapaz de discernir se um agente está apenas navegando pelo código ou abrindo problemas ativamente.
O OpenShell da NVIDIA, um novo sandbox de código aberto, aborda essa lacuna. Escrito em Rust e licenciado sob Apache 2.0, o OpenShell controla o que um agente pode fazer com seu acesso, não apenas se ele pode alcançar um recurso. Crucialmente, ele não requer uma GPU NVIDIA, rodando em hardware padrão.
O design focado em políticas do OpenShell impõe controle granular sobre acesso a arquivos, chamadas de sistema e conexões de rede. Ele opera com uma postura de negação por padrão, o que significa que os agentes não podem fazer nada até que sejam explicitamente permitidos. Essa aplicação refinada é um salto significativo além da conteinerização básica.
O segurança verifica todas as saídas
O OpenShell mapeia três componentes principais: o Gateway atua como a interface e plano de controle; o Supervisor impõe a política e intermedeia as credenciais; e o Sandbox fornece o ambiente restrito onde o agente é executado. O único caminho de saída do Sandbox passa pelo Supervisor, garantindo que todas as interações externas sejam mediadas.
O comportamento de negação por padrão é central para o modelo de segurança do OpenShell. Restrições de sistema de arquivos e processos em nível de kernel bloqueiam caminhos não autorizados e a escalada de privilégios desde o início. Qualquer solicitação de rede do agente deve passar pelo Supervisor, que a examina em relação a políticas predefinidas.
Considere uma política que permite que o binário curl faça solicitações somente leitura para a API do GitHub. O Supervisor permite isso. No entanto, se esse mesmo binário curl tentar uma solicitação POST não aprovada para criar um problema, o Supervisor a nega. Essas políticas são atualizadas em tempo real via openshell policy update sem reiniciar o sandbox, e cada negação é registrada, fornecendo uma trilha de auditoria clara.
Criticamente, o agente nunca manipula credenciais diretamente. O Supervisor injeta tokens apenas para solicitações aprovadas, impedindo a exfiltração via injeção de prompt. Até mesmo a resolução de DNS ocorre via Supervisor, limitando a visibilidade e o controle do agente. Esse design garante que, mesmo que um agente seja comprometido, ele não tenha chaves para vazar.
A parte inteligente: seu agente nunca detém a chave
O recurso mais engenhoso do OpenShell é o mascaramento de credenciais: o agente nunca detém diretamente chaves de API ou tokens sensíveis. Em vez disso, o Supervisor retém esses segredos, injetando-os apenas em solicitações de saída aprovadas que estejam alinhadas com a política estabelecida. Esse design reduz significativamente a superfície de ataque para injeção de prompt, já que não há credenciais para o agente vazar.
Antes que quaisquer alterações de política entrem em vigor, o OpenShell emprega um Z3 solver para atuar como um verificador formal. Este motor matemático avalia as modificações de política propostas, calculando o escopo total do acesso recém-concedido. Esta verificação proativa ajuda a expor regras de risco, como wildcards não intencionais ou permissões excessivamente amplas, impedindo que sejam implementadas.
Embora existam alternativas — o Docker oferece isolamento básico, o sandbox runtime da Anthropic oferece uma configuração mais leve e soluções hospedadas como E2B ou Daytona fornecem execução gerenciada — o OpenShell ocupa um nicho próprio. Ele enfatiza o controle de agentes auto-hospedado e orientado por políticas, executado sobre runtimes de contêiner como Docker, Podman ou Kubernetes. Para aqueles interessados na arquitetura subjacente e contribuições de código aberto, o projeto está disponível em NVIDIA/OpenShell no GitHub.
O OpenShell representa uma mudança de simplesmente perguntar "o agente pode alcançar isso?" para "o que o agente tem permissão para fazer com isso?". Os relatórios de telemetria da NVIDIA mostram que, em duas semanas neste verão, o OpenShell criou mais de 550.000 sandboxes e negou 4,2 milhões de ações de agentes, ressaltando seu papel ativo na aplicação de limites aos agentes.
Gostando do artigo? Receba um assim na sua caixa de entrada toda manhã.
um e-mail por dia · cancele em dois cliques · sem rastreadores de terceiros
Diretrizes úteis, não um campo de força de segurança
O OpenShell oferece diretrizes úteis, não um campo de força de segurança. Seu estágio inicial é evidente: apesar do interesse proeminente do ecossistema por parte da Cisco, CrowdStrike, Google Cloud e Microsoft Security, a versão do projeto é apenas 0.1.5, rotulada como uma "early preview". A telemetria é ativada por padrão, contando eventos anonimamente, embora uma variável de ambiente possa desativá-la.
Usuários de Mac devem observar que os sandboxes do OpenShell são baseados em Linux, rodando dentro da máquina virtual do Docker Desktop. Isso requer recursos de kernel como Landlock e rede de host ativados, o que geralmente está desativado por padrão. O próprio comando doctor da NVIDIA pode reportar que está tudo certo, mas recomenda-se realizar testes.
Os relatórios de telemetria interna da NVIDIA mostram uma atividade impressionante: mais de 550.000 criações de sandbox e 4,2 milhões de ações de agentes negadas em um período de duas semanas. Esses números destacam a escala de excessos de agentes que o OpenShell intercepta. No entanto, a NVIDIA também relatou que aproximadamente 12% das criações de sandbox falharam durante o mesmo período; estes são números de telemetria da empresa, não uma auditoria independente.
Para codificação local mais simples com ferramentas como o Claude Code, um contêiner básico ou o Anthropic Sandbox Runtime podem ser suficientes com menos configuração. Mas para agentes que lidam com credenciais reais ou tarefas de longa duração e não supervisionadas, as regras por solicitação e o mascaramento de credenciais do OpenShell são inestimáveis. O design cuidadoso da política continua sendo crítico, pois o sandboxing mitiga riscos, mas não pode eliminar todas as vulnerabilidades potenciais.
Perguntas Frequentes
O que é o NVIDIA OpenShell?
O OpenShell é um runtime de código aberto para restringir o acesso de agentes de IA a arquivos, processos e rede por meio de políticas aplicadas fora do agente.
O OpenShell requer uma GPU NVIDIA?
Não. O vídeo demonstra que ele funciona em um Mac; o OpenShell não depende de hardware de GPU NVIDIA.
Como o OpenShell é diferente do Docker?
O Docker isola um contêiner, enquanto o OpenShell adiciona controles granulares, incluindo regras para quais processos podem acessar endpoints de rede e operações específicas.
O OpenShell evita todos os riscos de segurança de agentes de IA?
Não. Ele limita o que um agente pode acessar, mas não é uma garantia total de segurança; a configuração, os limites de isolamento e a maturidade do software ainda são importantes.