A Arquitetura de Referência NVIDIA OpenShell Leva a Aplicação de Regras para a Infraestrutura

A NVIDIA lançou sua NVIDIA OpenShell Reference Architecture em 21 de outubro, levando as permissões de agentes além do controle do software que executa o trabalho. Anunciado na GTC Berlin, o projeto conecta computação de modelos, execução de agentes e aplicação independente de segurança. Sua proposta central é prática: um agente deve continuar trabalhando de forma autônoma sem ganhar autoridade para reescrever suas próprias restrições.

Isso cria uma decisão de compra diferente da escolha de um modelo mais capaz. As empresas precisam decidir onde as permissões residem, qual infraestrutura as aplica e quem pode interromper um agente depois que algo dá errado. A tensão está entre uma autonomia útil e restrições precisas o suficiente para impedir ações não autorizadas sem bloquear trabalho legítimo.

O Claude Code, da Anthropic, oferece uma comparação útil porque também restringe agentes por meio de seu ambiente operacional. A NVIDIA estende essa discussão à infraestrutura empresarial e à aplicação opcional por hardware. Desenvolvedores, equipes de segurança e fornecedores de software empresarial agora enfrentam uma questão comum: como uma organização transforma suas regras de negócio em limites que continuam eficazes durante a execução?

A Arquitetura de Referência NVIDIA OpenShell Conecta Execução e Aplicação de Regras

O anúncio apresenta a contenção de agentes como uma responsabilidade da infraestrutura, com componentes separados para executar o trabalho e governá-lo.

Uma arquitetura de referência é um projeto documentado de sistema que organizações e parceiros podem usar ao criar implantações. Isso não significa que cada integração mencionada seja disponibilizada como um produto finalizado com capacidades idênticas. Essa distinção importa ao avaliar um anúncio que abrange processadores, sistemas operacionais, fornecedores de segurança e aplicações empresariais.

Segundo a arquitetura de referência OpenShell da NVIDIA, a infraestrutura Vera Rubin executa modelos, enquanto as CPUs Vera operam os agent harnesses, o software que coordena chamadas de modelos e ferramentas. As unidades de processamento de dados BlueField-4, processadores especializados de infraestrutura, executam o software de segurança Sentry para monitoramento e aplicação independentes.

A divisão reflete problemas operacionais distintos. Gerar um plano exige capacidade computacional. Executá-lo exige acesso a arquivos, serviços e ferramentas. Autorizar essas ações exige regras que o agente executor não possa alterar simplesmente porque uma restrição interfere em sua tarefa.

O anúncio também estende o projeto a implantações locais e de borda, ou seja, sistemas que operam mais próximos dos usuários ou dos equipamentos. A NVIDIA cita RTX Spark, DGX Spark e DGX Station. Os compradores devem avaliar esses ambientes individualmente, em vez de presumir que uma estação de trabalho local oferece todas as proteções descritas para uma implantação de infraestrutura maior.

A mudança importante está na relação proposta entre essas partes. Em vez de tratar a segurança como um recurso da aplicação adicionado após o desenvolvimento, a arquitetura posiciona a aplicação de regras abaixo da aplicação. A solicitação de um agente passa a ser algo avaliado pela infraestrutura, em vez de algo aceito porque o agente gerou uma explicação plausível.

Considere uma tarefa ilustrativa de engenharia: um agente investiga um serviço com falha e propõe um reparo. Ler arquivos de diagnóstico, instalar uma dependência, alterar uma configuração e implantar a correção representam permissões diferentes. Uma única instrução para reparar o serviço não estabelece que todas as etapas possíveis estejam autorizadas.

Esse exemplo explica por que a arquitetura é relevante além dos especialistas em segurança. Equipes de produto que prometem execução autônoma também precisam explicar os limites dessa execução. Caso contrário, os clientes recebem uma descrição de capacidade sem uma explicação correspondente sobre controle.

A disponibilidade também exige interpretação cuidadosa. A NVIDIA diz que a arquitetura de referência está disponível, mas isso não estabelece prontidão para produção em todas as combinações de parceiros. Um projeto documentado, uma implantação compatível e uma instalação validada em cliente respondem a perguntas diferentes.

Portanto, para os leitores que avaliam o lançamento, a primeira pergunta é específica: quais partes da cadeia proposta de execução e aplicação de regras existem na configuração oferecida? A resposta determina se um comprador está avaliando controles de software, proteção adicional por hardware ou um roteiro que combine ambos.

Equipes Empresariais Herdam o Problema das Permissões

Levar a aplicação de regras para a infraestrutura dá às empresas mais controle, ao mesmo tempo que torna mais difícil deixar implícitas suas decisões de política.

A pressão imediata recai sobre as equipes responsáveis por traduzir autoridade de negócio em permissões técnicas. As equipes de segurança podem definir recursos restritos, mas os responsáveis pelo negócio precisam explicar quais ações pertencem a uma tarefa. As equipes de infraestrutura devem então tornar essas decisões aplicáveis em todos os sistemas que um agente acessa.

Uma instrução como “prepare a renovação do cliente” contém considerável ambiguidade. Ela pode justificar a leitura do histórico da conta e a elaboração de uma proposta. Não justifica automaticamente alterar termos contratuais, exportar registros de clientes ou enviar a proposta sem revisão.

Essas são distinções ilustrativas, não resultados relatados de implantações do OpenShell. Elas mostram por que a segurança de agentes exige mais do que identificar o modelo ou verificar se um funcionário iniciou a solicitação. A autoridade depende da ação, de seu alvo e das circunstâncias.

Os controles de execução de agentes da NVIDIA dividem a responsabilidade entre um gateway, supervisor, sandbox e policy prover. O gateway gerencia políticas e ciclos de vida de sandbox. O supervisor verifica solicitações e intermedeia credenciais fora do sandbox, um ambiente isolado de execução. O policy prover verifica permissões em relação a um limite definido pela organização.

Essa separação fornece locais para aplicação de regras, mas as organizações ainda precisam decidir o que esses locais devem permitir. Um limite formalmente verificado pode confirmar uma relação entre políticas. Ele não pode decidir de forma independente se um departamento de negócios concedeu acesso excessivo desde o início.

Isso muda a discussão entre desenvolvedores de aplicações e revisores de segurança. Em vez de perguntar se um agente é confiável de forma geral, os revisores podem examinar o que ele pode ler, modificar, invocar ou transmitir. Essas perguntas produzem respostas mais acionáveis, embora também exijam preparação mais detalhada.

Os desenvolvedores enfrentam uma restrição de projeto relacionada. Um fluxo de trabalho que só funciona quando recebe permissões amplas é mais difícil de aprovar do que outro com requisitos explícitos e limitados. Interfaces de ferramentas e descrições de tarefas passam a fazer parte do projeto de segurança porque determinam quão precisamente a autoridade pode ser expressa.

Para trabalhadores do conhecimento, a distinção começa pelo acesso à informação. Uma base de conhecimento pesquisável ajuda a estabelecer onde está o material útil. Um agente que realiza ações introduz outra decisão: encontrar informações também concede permissão para compartilhá-las ou alterar o sistema que as contém?

O ônus organizacional é contínuo. Funcionários mudam de função, projetos terminam, credenciais expiram e aplicações adquirem novas funções. A autoridade de um agente precisa refletir essas mudanças, em vez de preservar qualquer acesso que tornou sua primeira demonstração bem-sucedida.

É por isso que a governança não pode terminar com um documento de aprovação. As empresas precisam de uma conexão entre a pessoa que autoriza o trabalho, a política que representa essa autoridade e a infraestrutura que a aplica. Sem essa conexão, regras aplicadas de forma independente ainda podem preservar uma decisão desatualizada ou excessivamente ampla.

O lançamento, portanto, pressiona tanto os fornecedores de software quanto os compradores de infraestrutura. Os fornecedores precisam expor detalhes suficientes sobre as ações dos agentes para que os clientes possam governá-las. Um sistema que apresenta todas as operações como uma solicitação indistinguível deixa os clientes diante de uma escolha rudimentar entre acesso amplo e interrupção.

O Isolamento por Hardware Muda Onde o Limite se Sustenta

A proposta de hardware da NVIDIA adiciona um local independente para aplicação de regras; seu valor depende de as ações relevantes realmente passarem por esse local.

Uma restrição de software tem um escopo definido. Sua proteção depende dos componentes que a aplicam e das premissas adotadas por esses componentes. Adicionar uma camada de segurança por hardware separada altera algumas dessas premissas ao posicionar controles fora do ambiente de execução do agente.

A NVIDIA descreve o Sentry como uma proteção adicional opcional ao lado dos limites de software do OpenShell. Essa distinção evita um equívoco comum: usar o OpenShell não significa automaticamente que uma implantação inclui aplicação de regras pelo BlueField-4. Os compradores precisam identificar a configuração real antes de comparar alegações de segurança.

No projeto de segurança de execução Sentry da NVIDIA, o BlueField-4 ocupa o caminho de comunicação do nó com modelos e sistemas externos. O Sentry combina inspeção de tráfego com análise selecionada da memória do host. A NVIDIA afirma que ele pode colocar agentes em quarentena em milissegundos sem exigir cooperação do agente ou do software host.

A lógica arquitetural é direta. Um controle é mais útil contra uma carga de trabalho comprometida quando essa carga não consegue desativá-lo. Mas a independência, por si só, não estabelece cobertura completa. O ponto de aplicação também precisa enxergar a ação avaliada e manter autoridade para bloqueá-la.

Isso cria perguntas concretas para revisões de implantação. A configuração encaminha todas as conexões externas relevantes pelo caminho controlado? Quais ações locais recebem restrições separadas? O que acontece quando uma ferramenta realiza trabalho em outro serviço após receber uma solicitação autorizada?

Essas perguntas decorrem do projeto, e não documentam falhas descobertas. Elas importam porque o fluxo de trabalho de um agente pode atravessar diversos limites administrativos. Bloquear sua próxima conexão não pode necessariamente reverter uma ação já aceita por outra aplicação.

O tráfego criptografado introduz outra decisão de configuração. A NVIDIA descreve a inspeção de conexões configuradas para serem descriptografadas e examinadas. Portanto, as empresas precisam entender onde a inspeção se aplica, quais informações se tornam visíveis e como essa visibilidade se encaixa em seus requisitos de confidencialidade.

A comparação com a Anthropic ajuda a esclarecer a escolha de projeto. O sandboxing do Claude Code usa mecanismos do sistema operacional para restringir o acesso ao sistema de arquivos e à rede. Sua abordagem declarada dá aos agentes liberdade dentro de limites predefinidos, enquanto controla o acesso além deles.

Ambas as abordagens colocam restrições fora das instruções geradas pelo modelo. A diferença não é uma simples disputa entre software irrestrito e hardware seguro. Os compradores estão comparando arranjos de aplicação, requisitos de implantação e pressupostos de falha.

O exemplo da Anthropic aborda um ambiente de execução para desenvolvedores. O anúncio da NVIDIA conecta a execução de agentes a um design de infraestrutura mais amplo, com uma camada opcional de hardware independente. Nenhuma das descrições, isoladamente, estabelece qual arranjo é mais adequado para uma carga de trabalho empresarial específica.

Para uma organização que executa tarefas de desenvolvimento com escopo restrito, os controles de ambiente existentes merecem avaliação por seus próprios méritos. Para implantações sensíveis que exigem independência adicional em relação ao software hospedeiro, a abordagem de hardware da NVIDIA apresenta uma opção diferente. A decisão deve seguir a ameaça que está sendo tratada.

A principal troca envolve separação mais forte em contraposição a maior complexidade de implantação. Uma camada adicional de aplicação cria mais um ponto para interromper atividades inseguras. Ela também cria mais um componente cujas políticas, visibilidade, atualizações e responsabilidade operacional devem permanecer consistentes com o restante do sistema.

Anúncios de Parceiros Revelam Diferentes Estágios de Prontidão

Os detalhes mais úteis dos parceiros distinguem recursos disponíveis agora de integrações que ainda permanecem planejadas.

A ServiceNow fornece um exemplo concreto da arquitetura entrando na conversa sobre produtos empresariais. Seu anúncio de governança de agentes empresariais informa que Arc, um agente pessoal projetado para trabalho de longa duração, está amplamente disponível. A ServiceNow descreve a aplicação do OpenShell como parte da execução governada do Arc.

O mesmo anúncio coloca a integração do AI Passport com a aplicação do OpenShell e do BlueField em uma versão futura. AI Passport é um registro de autoridade destinado a comunicar as permissões de um agente. Seu status planejado importa porque o lançamento atual de uma aplicação não estabelece a disponibilidade de toda a cadeia de governança proposta.

Essa distinção oferece aos compradores uma maneira útil de ler outros materiais de lançamento. A disponibilidade no presente deve ser avaliada separadamente da integração pretendida, da colaboração com parceiros e de capacidades futuras. Combiná-las em uma única impressão de prontidão obscurece o trabalho ainda necessário.

O exemplo da ServiceNow também torna tangível o problema de negócios. Um agente persistente no ambiente de trabalho precisa operar entre atribuições e permissões em mudança. A governança deve permanecer relevante após a solicitação inicial, especialmente quando uma tarefa continua além da atenção imediata do usuário.

Um caso ilustrativo é o de um funcionário que atribui a um agente a coordenação da transição de um projeto. Ler documentos do projeto, identificar trabalho inacabado, redigir mensagens e alterar direitos de acesso exigem autoridades diferentes. Um sistema útil precisa preservar essa distinção à medida que a tarefa se desenvolve.

Parceiros de segurança introduzem outra camada de diferenciação. A F5 descreve a inspeção de tráfego de IA que complementa as permissões de execução com o exame de prompts, respostas e chamadas de ferramentas compatíveis. Seu anúncio também distingue uma topologia de implantação proposta, sujeita à validação do produto.

Essa é uma qualificação importante, não uma nota de rodapé menor. Um parceiro pode apoiar a direção da arquitetura enquanto uma configuração específica ainda exige validação. Os clientes devem perguntar qual implantação foi testada, com quais funções de inspeção ativadas e em relação a qual carga de trabalho.

O relato da F5 também separa autorização de avaliação de conteúdo. Uma solicitação pode visar um serviço aprovado enquanto transporta informações sensíveis ou instruções maliciosas. A permissão para se conectar e o julgamento sobre o conteúdo transmitido abordam riscos diferentes.

Isso ajuda a explicar por que o lançamento inclui parceiros de segurança, em vez de apresentar a aplicação na infraestrutura como substituta para todas as defesas existentes. O limite proposto precisa de informações sobre identidade, autorização e atividade suspeita. Ele também precisa de uma resposta operacional após algo ser bloqueado.

A questão comercial é se essas camadas se tornam mais fáceis de operar em conjunto. Os compradores devem procurar políticas consistentes e registros de incidentes compreensíveis. Adicionar consoles separados sem uma relação clara entre as decisões deixaria os investigadores reconstruindo o que ocorreu entre sistemas desconectados.

A amplitude dos parceiros sinaliza interesse, mas os detalhes de implantação têm mais peso. Um cliente pode avaliar uma configuração compatível, uma limitação documentada ou uma integração entregue. O nome de uma empresa em uma lista de lançamento fornece menos evidências sobre o que esse cliente pode operar com segurança hoje.

Limites Seguros Ainda Dependem de Regras Corretas

A Arquitetura de Referência NVIDIA OpenShell não elimina a distinção entre uma ação autorizada e uma boa decisão.

Um agente pode permanecer dentro de suas permissões e ainda assim produzir um resultado incorreto. Ele pode interpretar mal um documento, escolher o registro errado ou fazer uma recomendação inadequada. A contenção na infraestrutura aborda o escopo da ação; ela não estabelece a veracidade de cada conclusão.

Essa distinção deve moldar a forma como as organizações interpretam a palavra “seguro”. Segurança é um resultado amplo, enquanto a aplicação em tempo de execução fornece controles específicos. Uma avaliação significativa identifica a falha que está sendo evitada e as premissas sob as quais essa prevenção se sustenta.

Imagine um agente autorizado a atualizar um sistema de agendamento. Uma restrição pode impedir com sucesso seu acesso a dados de folha de pagamento. O mesmo agente ainda poderia agendar o compromisso errado dentro da aplicação permitida. Ambos os resultados importam, mas exigem salvaguardas diferentes.

Permissões excessivamente amplas criam outra limitação. Uma regra perfeitamente aplicada que permite a um agente exportar um conjunto de dados inteiro não protege esse conjunto contra uma exportação autorizada. A qualidade da decisão de negócios permanece central mesmo quando a aplicação funciona exatamente como projetada.

Permissões excessivamente restritas criam o problema oposto. Se o trabalho rotineiro é interrompido repetidamente, os usuários têm um incentivo para solicitar acesso mais amplo. As equipes de segurança então precisam de evidências sobre quais bloqueios evitam danos e quais refletem políticas mal ajustadas a tarefas legítimas.

Esta é uma preocupação analítica, não uma constatação de que o OpenShell cause interrupções desnecessárias. Ela identifica a medição necessária para avaliar a troca entre autonomia e controle. A contenção bem-sucedida deve ser considerada juntamente com a conclusão útil de tarefas, a frequência de intervenções e as consequências de operações negadas.

O momento da detecção também precisa de contexto. Uma alegação de quarentena rápida descreve a resposta após uma condição relevante ser detectada. Os compradores ainda precisam entender quais eventos acionam a detecção e se um sistema externo já agiu antes do início da contenção.

As descrições disponíveis dos fornecedores não estabelecem uma garantia universal verificada de forma independente em fluxos de trabalho empresariais. Elas explicam mecanismos e pontos de integração pretendidos. Conclusões sobre segurança em produção exigem evidências vinculadas à configuração implantada, incluindo suas permissões e proteções ativadas.

Há também uma dimensão de privacidade na observabilidade ampliada. Examinar comunicações e contexto de execução pode melhorar as investigações, ao mesmo tempo que expõe material sensível a componentes adicionais de segurança. As organizações precisam de decisões claras sobre escopo de inspeção, acesso a registros e retenção.

A responsabilidade operacional merece igual atenção. Alguém precisa manter políticas, investigar negações, aprovar exceções e restaurar um agente após a contenção. Se essas responsabilidades permanecerem pouco claras, um limite tecnicamente eficaz ainda pode produzir uma interrupção prolongada ou uma solução alternativa insegura.

A abordagem da NVIDIA torna essas questões mais concretas porque identifica pontos em que regras podem ser aplicadas de forma independente. Isso representa um progresso útil no design de sistemas. Não elimina a necessidade de avaliar as próprias regras ou o fluxo de trabalho em torno de uma decisão de segurança.

Portanto, o padrão apropriado é uma afirmação delimitada: controles específicos impedem ações não autorizadas específicas sob condições determinadas. Os compradores devem resistir a transformar essa afirmação em uma promessa geral de que um agente não pode causar danos.

Acompanhe Integrações Entregues, Evidências de Segurança e Adequação Operacional

Os próximos sinais relevantes são capacidades entregues, validação reproduzível e evidências de que as organizações conseguem manter os controles resultantes.

Nos próximos meses, o primeiro sinal é a entrega das integrações descritas como trabalho futuro. A aplicação planejada do AI Passport pela ServiceNow fornece um exemplo específico. Uma versão com suporte e limitações documentados tornaria mais fácil avaliar a conexão proposta entre autoridade de negócios e aplicação na infraestrutura.

Isso fortaleceria o argumento de que as empresas podem transportar uma decisão de governança entre camadas de execução. A continuidade de linguagem de roteiro deixaria essa parte da proposta menos estabelecida. Os compradores devem distinguir a disponibilidade de produtos de demonstrações ou anúncios de colaboração.

O segundo sinal é a validação de segurança vinculada a uma implantação completa. Evidências úteis descreveriam a carga de trabalho, a configuração de políticas, a inspeção ativada, a ação não autorizada tentada e o resultado observado. Elas também deveriam explicar qual trabalho legítimo permaneceu possível.

Uma demonstração que mostra um agente sendo interrompido estabelece menos do que um relato reproduzível de por que ele foi interrompido. Este último ajuda os clientes a determinar se o mesmo controle se aplica às suas aplicações. Ele também expõe premissas que uma apresentação pode deixar implícitas.

A validação deve incluir fluxos de trabalho permitidos, bem como ataques. Um limite que bloqueia atividades não autorizadas enquanto permite o trabalho esperado sustenta a principal troca da arquitetura. A dependência repetida de exceções amplas enfraqueceria a alegação de que as empresas podem combinar autonomia com controle preciso.

O terceiro sinal é a adequação operacional em ambientes empresariais reais. As organizações precisam saber se as políticas permanecem consistentes à medida que aplicações, identidades e ferramentas mudam. Elas também precisam de registros de incidentes que expliquem a relação entre a ação solicitada e a decisão de aplicação.

Evidências de atualizações de políticas administráveis e investigações compreensíveis fortaleceriam o argumento para a implantação. Evidências de regras inconsistentes ou responsabilidade pouco clara identificariam um gargalo diferente. Nessa situação, capacidade adicional de aplicação não resolveria, por si só, o problema de governança.

Implantações locais e de borda merecem atenção especial nessa avaliação operacional. Os leitores devem procurar capacidades documentadas do sistema específico que está sendo implantado. Uma família de produtos ou um rótulo de arquitetura compartilhado não responde a todas as perguntas sobre cobertura de aplicação.

Para desenvolvedores, a consequência prática é uma demanda por requisitos de permissão mais claros. Para compradores empresariais, é uma demanda por evidências específicas da configuração. Para trabalhadores do conhecimento, é a distinção entre conceder a um agente acesso a informações e delegar autoridade para agir.

Antes de aprovar uma implantação, identifique o fluxo de trabalho exato que você deseja que um agente conclua e as ações que devem permanecer fora de sua autoridade. Peça ao fornecedor que mostre ambos os resultados na configuração proposta: o trabalho legítimo continuando e uma ação não autorizada sendo interrompida. Em seguida, examine quem mantém a política, como as mudanças de acesso entram em vigor e o que os investigadores conseguem reconstruir posteriormente. Mantenha as capacidades atuais separadas das integrações prometidas, especialmente quando lançamentos de software e hardware seguem cronogramas diferentes. A Arquitetura de Referência NVIDIA OpenShell oferece um projeto concreto de infraestrutura para essa avaliação. Use-a para exigir uma resposta precisa a uma pergunta prática: quais decisões permanecem sob o controle da sua organização enquanto o agente trabalha de forma independente?