Plataforma de Segurança para Agentes Abertos da NVIDIA é Lançada, Levando as Proteções de IA para Fora do Modelo

A Plataforma de Segurança para Agentes Abertos da NVIDIA foi lançada em 28 de setembro com um desafio claro ao atual modelo de segurança da indústria de IA. Em vez de confiar que os agentes obedecerão aos prompts, a NVIDIA quer que software e hardware externos ao agente controlem cada ação.

A plataforma combina OpenShell, um runtime de código aberto para execução isolada de agentes, com Sentry, um design de monitoramento independente construído em torno das unidades de processamento de dados NVIDIA BlueField-4. A NVIDIA afirma que o Sentry pode colocar um agente em quarentena em milissegundos quando ele ultrapassa um limite autorizado.

Essa distinção torna a iniciativa mais do que outro framework de agentes. A NVIDIA argumenta que o alinhamento de modelos e as instruções no nível da aplicação não podem fornecer controle suficiente quando os agentes recebem credenciais, acesso à rede e permissão para alterar sistemas reais. A alternativa proposta se assemelha à segurança convencional de infraestrutura: negar acesso por padrão, conceder permissões restritas, registrar cada decisão e manter a aplicação das regras além do controle da carga de trabalho.

A questão imediata não é se o OpenShell consegue colocar um agente dentro de um sandbox. Sistemas operacionais e plataformas de nuvem existentes já oferecem ferramentas de isolamento. A questão mais difícil é se a NVIDIA consegue transformar a contenção de agentes em uma camada de infraestrutura prática sem bloquear o trabalho que as empresas desejam que os agentes realizem.

Plataforma de Segurança para Agentes Abertos da NVIDIA é Lançada com Duas Camadas de Controle

A NVIDIA dividiu a segurança de agentes entre um limite de software e uma salvaguarda independente baseada em hardware.

O OpenShell fornece a primeira camada. Ele executa cada agente em um ambiente isolado e aplica políticas que abrangem arquivos, processos, destinos de rede, credenciais e endpoints de modelos. O agente pode receber o acesso necessário para uma tarefa sem obter controle irrestrito sobre seu sistema hospedeiro.

A NVIDIA descreve o OpenShell como um runtime, e não como um framework de agentes. Ele fica abaixo de ferramentas como Claude Code, Codex, GitHub Copilot CLI, OpenCode e sistemas de agentes personalizados. Os desenvolvedores não precisam substituir o modelo de raciocínio do agente nem a estrutura da aplicação para usar esse limite de segurança.

O runtime usa uma abordagem de negar por padrão. Um agente não recebe acesso geral à rede, privilégios elevados ou permissões amplas de sistema de arquivos quando seu sandbox é iniciado. Os administradores então definem recursos aprovados por meio de políticas legíveis por máquina.

Por exemplo, um agente de processamento de faturas pode receber permissão para ler uma pasta específica e entrar em contato com uma API de contabilidade aprovada. Ele pode continuar incapaz de excluir faturas, examinar diretórios não relacionados ou enviar dados a um site não aprovado.

O OpenShell também separa o uso de credenciais da posse de credenciais. O supervisor, executado fora do sandbox, pode fornecer credenciais somente quando uma política autoriza uma solicitação específica. O agente não precisa de acesso direto ao segredo subjacente.

O runtime avalia a atividade de rede usando detalhes como o binário solicitante, o destino, o método e o caminho. Ele pode aplicar atualizações de política enquanto um agente continua em execução. Cada ação permitida ou negada passa a integrar uma trilha de auditoria.

A arquitetura do OpenShell da NVIDIA também inclui um verificador de políticas. Esse componente usa verificação formal, um método matemático para checar se regras especificadas satisfazem propriedades definidas, antes que os administradores apliquem alterações de política.

O verificador aborda um problema sutil. As equipes de segurança geralmente entendem que um agente precisa de acesso a um novo serviço, mas não conseguem visualizar facilmente todas as capacidades criadas por uma alteração de política. Uma regra que parece restrita pode abrir um caminho de rede inesperado ou colocar uma credencial ao alcance.

O Sentry fornece a segunda camada. Ele é executado em um domínio de confiança isolado nas DPUs BlueField-4, processadores especializados que lidam com cargas de trabalho de infraestrutura e segurança fora da CPU principal.

Segundo o anúncio da plataforma da NVIDIA, o Sentry monitora a atividade de agentes de forma independente e pode interromper comportamentos suspeitos em milissegundos. A NVIDIA afirma que o sistema usa seu software DOCA para inspecionar solicitações, verificar identidades, proteger o acesso a dados e produzir telemetria atestada.

Essa separação importa porque um agente não pode simplesmente instruir o Sentry por prompt, reescrever suas instruções ou desativá-lo a partir do ambiente de trabalho. Até mesmo um runtime comprometido encontra outro ponto de aplicação das regras além do sistema principal.

O OpenShell está amplamente disponível, enquanto o Sentry é apresentado como parte de um design de sistema de referência vinculado ao BlueField-4. Segundo a NVIDIA, o software do OpenShell também pode ser estendido a processadores da Arm e da Intel.

O resultado é uma proposta em camadas, e não um único produto de segurança. O OpenShell limita o que um agente pode fazer durante a operação normal. O Sentry observa de fora desse limite e responde quando a atividade parece escapar dele.

Por Que a Segurança de Agentes Está Indo Além dos Prompts

Um agente capaz de agir cria um problema de segurança que instruções melhores, por si só, não conseguem resolver.

Chatbots tradicionais retornam texto para que uma pessoa o revise. Agentes autônomos podem ler arquivos locais, instalar pacotes, chamar serviços externos, usar tokens de autenticação, modificar código e continuar trabalhando sem aprovação constante.

Essas capacidades tornam os agentes úteis. Elas também ampliam as consequências de uma suposição equivocada, entrada manipulada, dependência comprometida ou instrução ambígua.

Um prompt pode dizer a um agente para não compartilhar informações confidenciais. Essa instrução não impede fisicamente o agente de abrir um arquivo sensível ou entrar em contato com um servidor desconhecido. As proteções no nível da aplicação continuam sendo parte do mesmo ambiente de software que o agente está explorando.

A injeção de prompt torna essa fragilidade especialmente importante. Um agente pode encontrar instruções hostis em um site, documento, e-mail, rastreador de issues ou repositório de código-fonte. Essas instruções podem tentar redirecionar o agente enquanto parecem dados legítimos da tarefa.

Um modelo também pode interpretar erroneamente uma solicitação válida sem encontrar um invasor. Um agente de programação solicitado a limpar um projeto pode remover arquivos necessários. Um agente de pesquisa pode enviar informações a um serviço não autorizado por considerar essa etapa útil.

Justin Boitano, vice-presidente de IA empresarial da NVIDIA, disse a repórteres que os agentes podem se desviar quando as instruções são ambíguas ou as ferramentas se comportam de maneira inesperada. Seu argumento central foi que não se pode esperar que um agente fiscalize a si mesmo depois que ele passa a poder agir.

Esse é o princípio por trás do anúncio de lançamento da Plataforma de Segurança para Agentes Abertos da NVIDIA. O raciocínio dos agentes continua probabilístico, mas as permissões de infraestrutura podem ser determinísticas. Um mecanismo de políticas pode rejeitar uma conexão de rede independentemente da explicação do modelo para solicitá-la.

A mudança se assemelha a transformações anteriores na segurança em nuvem. As organizações deixaram de depender apenas de desenvolvedores de aplicações para proteger todos os bancos de dados, segredos e rotas de rede. Elas adicionaram gerenciamento de identidade, isolamento de cargas de trabalho, mecanismos de políticas e monitoramento fora de cada aplicação.

A segurança de agentes agora enfrenta uma transição semelhante. O modelo ainda precisa de treinamento de segurança, e a aplicação ainda precisa de instruções sensatas. Nenhuma das duas camadas deve receber autoridade ilimitada apenas porque tem bom desempenho durante os testes.

A posição da NVIDIA também pressiona fornecedores de plataformas de agentes. Controles de segurança implementados apenas dentro de uma estrutura de agente se tornam menos persuasivos quando um runtime externo pode aplicar permissões em diversos modelos e frameworks.

Os provedores de nuvem também enfrentam pressão. Clientes que implantam frotas de agentes esperarão cada vez mais limites de identidade, intermediação de credenciais, controles de saída e registros de auditoria projetados para cargas de trabalho autônomas. Contêineres genéricos não responderão a todas as questões de governança.

As empresas são o terceiro grupo pressionado. Uma companhia não pode alegar que um agente atua com privilégio mínimo a menos que consiga explicar quais recursos o agente acessa, como as permissões mudam e quem pode interrompê-lo.

Essa exigência vai além de cenários dramáticos de agentes descontrolados. As equipes de conformidade precisam de registros para operações rotineiras, incluindo acesso a arquivos, chamadas de API, alterações de políticas e uso de credenciais.

A NVIDIA afirma que mais de 100 organizações estão trabalhando com tecnologias da plataforma. O grupo anunciado inclui Anthropic, Cisco, CrowdStrike, Dell Technologies, Hugging Face, JPMorganChase, Microsoft, Palantir, Perplexity, Red Hat, Salesforce, SAP, Scale AI, ServiceNow e outras.

Essa lista sinaliza amplo interesse, mas não comprova maturidade em produção. “Trabalhar com” pode abranger avaliações, integrações, engenharia conjunta ou suporte planejado. Os compradores ainda precisam de evidências de implantação e resultados operacionais.

OpenShell 0.1 Transforma o Privilégio Mínimo em um Runtime de Agentes

A principal contribuição do OpenShell não é um modelo mais inteligente, mas uma camada de controle reutilizável sob muitos modelos diferentes.

A linha de lançamento OpenShell 0.1 formaliza essa abordagem por meio de uma cadência estável de lançamentos, pontos de extensão ampliados, novas APIs e mecanismos adicionais de isolamento. Seu repositório de código aberto expõe o runtime, o sistema de políticas, kits de desenvolvimento de software e materiais de implantação para inspeção.

Cada agente é executado dentro de um sandbox com uma conta sem privilégios e capacidades reduzidas do sistema operacional. Os controles do Linux restringem o acesso ao sistema de arquivos e as chamadas de sistema, enquanto conexões de saída passam por verificações de política.

A arquitetura separa o sandbox de seu supervisor. O agente opera dentro do limite restrito da carga de trabalho, enquanto o supervisor permanece fora dele e intermedeia o acesso autorizado. Um gateway gerencia usuários, sandboxes, políticas, configurações e credenciais.

Essa separação reduz a autoridade detida pelo processo do agente. Se um modelo gera um comando de shell que solicita um arquivo proibido, o ambiente operacional bloqueia a ação. A confiança do modelo ou sua justificativa declarada não altera esse resultado.

As políticas do OpenShell são declarativas. Os administradores descrevem o comportamento permitido na configuração, em vez de incorporar cada restrição no código da aplicação. Isso cria uma superfície comum de revisão para equipes de segurança, plataforma e desenvolvimento.

As políticas abrangem diversas áreas relacionadas. Regras de sistema de arquivos diferenciam caminhos legíveis de caminhos graváveis. Controles de processo reduzem privilégios e restringem chamadas de sistema. Regras de rede avaliam destinos, portas, binários e detalhes no nível da aplicação.

Perfis de provedores conectam serviços aprovados às credenciais e regras de rede correspondentes. Isso pode manter um token de API vinculado ao seu destino pretendido, em vez de colocá-lo em uma variável de ambiente geral.

O runtime também oferece suporte ao roteamento de inferência. Uma empresa pode governar quais endpoints de modelos um agente utiliza, mantendo as credenciais dos provedores fora do sandbox. Isso importa quando as equipes combinam modelos locais, APIs em nuvem e dados restritos.

A observabilidade completa o ciclo básico de controle. O OpenShell registra decisões e pode exportar eventos de segurança em um formato estruturado. Investigadores podem revisar o que um agente solicitou, o que o runtime permitiu e o que ele negou.

Essas capacidades se encaixam particularmente bem em agentes de programação. Um desenvolvedor pode permitir que um agente leia um repositório, crie arquivos dentro de uma ramificação de trabalho, baixe pacotes de registros aprovados e entre em contato com um endpoint de modelo autorizado.

A mesma política também pode bloquear o acesso a repositórios não relacionados, diretórios pessoais, credenciais de produção e sites arbitrários. Se o agente solicitar acesso mais amplo, uma pessoa ou sistema confiável poderá revisar a alteração proposta.

O design também oferece suporte a agentes de longa execução. Um sandbox tradicional costuma proteger um único processo delimitado para uma tarefa limitada. O OpenShell busca governar atividades mutáveis de agentes ao longo do tempo, incluindo atualizações de políticas e fluxos de trabalho com subagentes.

Essa ambição introduz complexidade operacional. As políticas precisam acomodar variações legítimas sem se tornarem tão amplas que percam seu valor de proteção. As equipes também precisam de processos para revisar exceções sem paralisar cada tarefa.

A verificação formal ajuda a avaliar a estrutura de uma política proposta. Ela não pode decidir se a empresa pretendia autorizar uma ação perigosa. A governança humana ainda determina o limite aceitável.

O status de código aberto do OpenShell oferece às organizações outra vantagem. Pesquisadores de segurança podem inspecionar a implementação, testar premissas e propor alterações. As empresas também podem estender o software para diferentes plataformas de computação ou ambientes de implantação.

Código aberto não produz automaticamente software seguro. Ele oferece as condições para revisão independente, mas uma análise útil exige mantenedores ativos, processos claros de divulgação, testes reproduzíveis e correções rápidas.

A versão 0.1 também comunica cautela. O projeto agora possui uma arquitetura pública concreta, mas os primeiros adotantes devem esperar mudanças em APIs, políticas, práticas de implantação e integrações à medida que cargas de trabalho reais revelem limitações.

A Principal Disputa É Entre Imposição e Autocontenção do Agente

A NVIDIA aposta que controles de infraestrutura aplicáveis superarão regras de segurança que permanecem dentro do ciclo de raciocínio do agente.

Esta não é, principalmente, uma disputa entre a NVIDIA e outra fabricante de chips. É uma disputa entre duas abordagens de segurança: pedir que um agente se comporte com segurança e construir um ambiente em que ações inseguras falhem.

Os fornecedores de modelos continuam aprimorando alinhamento, comportamento de recusa, hierarquia de instruções e monitoramento. Essas medidas podem reduzir a probabilidade de um modelo escolher uma ação prejudicial. Elas também abordam comportamentos que os controles de infraestrutura não conseguem reconhecer por conta própria.

O OpenShell atua em uma camada diferente. Ele presume que um modelo acabará cometendo um erro, seguindo um contexto manipulado ou tentando uma operação não autorizada. O runtime se concentra em limitar os danos resultantes.

As duas abordagens devem se complementar, mas suas prioridades diferem. O alinhamento tenta melhorar as decisões do agente. A imposição em runtime presume que as decisões continuam falíveis e restringe suas consequências.

A participação da Anthropic ilustra essa abordagem combinada. A NVIDIA afirma que os Claude Managed Agents separam o ciclo do agente dos sandboxes de execução. O OpenShell e o BlueField podem adicionar controles adicionais sobre o acesso por meio desses sandboxes.

Esse arranjo cria defesa em profundidade, o que significa que vários controles independentes se interpõem entre o agente e recursos sensíveis. Uma falha em uma camada não derrota automaticamente todas as demais.

A plataforma também oferece suporte a modelos abertos e fechados. Essa posição independente de modelo é estrategicamente importante para a NVIDIA porque a empresa fornece infraestrutura em ecossistemas concorrentes de IA. Um runtime compartilhado pode se tornar útil independentemente de qual modelo lidere um mercado específico.

No entanto, portabilidade de software e independência de hardware não são idênticas. O OpenShell pode se estender além das CPUs da NVIDIA, enquanto o design completo do Sentry depende do BlueField-4 para imposição isolada em silício.

Isso cria uma tensão comercial dentro da plataforma “aberta”. A camada de software pode suportar infraestrutura heterogênea, mas a narrativa de contenção mais forte da NVIDIA destaca o hardware de rede da NVIDIA e sua pilha DOCA.

Concorrentes e provedores de nuvem podem responder de várias maneiras. Eles podem oferecer suporte ao OpenShell em suas plataformas, criar sistemas de política compatíveis ou promover recursos existentes de isolamento e computação confidencial como alternativas.

Fornecedores de segurança também podem conectar a atividade dos agentes a produtos consolidados de endpoint, identidade, rede e proteção de dados. A governança de agentes provavelmente se tornará mais uma camada na arquitetura de segurança empresarial, e não um mercado isolado.

O evento de lançamento da NVIDIA Open Agent Safety Platform, portanto, amplia o papel da NVIDIA. A empresa não está se limitando a fornecer computação para treinamento e inferência. Ela quer ajudar a definir como cargas de trabalho autônomas recebem autoridade e como a infraestrutura a revoga.

Essa posição dá à NVIDIA influência sobre um novo plano de controle. Se as políticas do OpenShell forem amplamente adotadas, o runtime poderá moldar expectativas para identidade de agentes, auditabilidade, gestão de credenciais e acesso à rede.

A adoção dependerá de neutralidade. Empresas podem hesitar se uma camada de segurança supostamente universal favorecer fortemente uma única pilha de hardware. Interfaces claras e suporte confiável para sistemas não-NVIDIA serão importantes.

Os desenvolvedores avaliarão outra questão: atrito. Uma camada de segurança que interrompe constantemente o trabalho útil incentivará exceções amplas, implantações abandonadas ou desvios não oficiais.

A plataforma só terá sucesso se permissões restritas continuarem sendo práticas. Isso exige ferramentas que ajudem as equipes a descobrir o acesso necessário, explicar bloqueios, testar políticas e aprovar alterações sem transformar cada tarefa de agente em um chamado de segurança.

O Que a Plataforma de Segurança da NVIDIA Ainda Não Pode Garantir

A contenção pode restringir o alcance de um agente, mas não pode determinar se toda ação permitida está correta.

Um agente pode causar danos permanecendo dentro de suas permissões formais. Um agente financeiro autorizado a enviar faturas pode aprovar um documento fraudulento. Um agente de programação com acesso de escrita poderia introduzir uma vulnerabilidade sutil em um repositório permitido.

O OpenShell pode registrar essas ações e restringir seu escopo. Ele não consegue compreender de forma independente a intenção, a lógica de negócios ou os requisitos éticos de cada organização.

A qualidade da política continua central. Se um administrador concede amplo acesso ao sistema de arquivos, saída de rede irrestrita ou credenciais reutilizáveis, o runtime aplicará com precisão uma fronteira fraca.

Earlence Fernandes, pesquisador da University of California, San Diego, descreveu a plataforma como um passo na direção certa. Ele também alertou que definir o acesso mínimo necessário continua difícil porque agentes úteis precisam de recursos reais.

Somesh Jha, professor de ciência da computação da University of Wisconsin, levantou uma preocupação relacionada. Ele disse à Associated Press que estudos de caso devem mostrar como o sistema equilibra segurança e bloqueio de trabalho útil.

Falsos positivos representam um lado desse equilíbrio. Se o Sentry colocar cargas de trabalho legítimas em quarentena, as organizações poderão perder a confiança em operações autônomas. Elas precisam de procedimentos confiáveis de recuperação e explicações para cada intervenção.

Falsos negativos representam o outro lado. Comportamentos suspeitos podem se assemelhar a atividades válidas, especialmente quando um agente usa ferramentas aprovadas para uma finalidade não pretendida. Uma solicitação permitida ainda pode vazar informações por meio de seu conteúdo.

A NVIDIA afirma que o Sentry pode intervir em milissegundos. A velocidade importa após a detecção, mas a alegação pública não estabelece a precisão da detecção em ambientes diversos.

Benchmarks independentes precisarão medir mais do que a latência de quarentena. Os avaliadores devem testar tentativas de escape, contornos de políticas, uso indevido de credenciais, transferência encoberta de dados, dependências comprometidas e ataques ao próprio plano de controle.

A sobrecarga de desempenho também precisa de medição cuidadosa. A NVIDIA descreve a sobrecarga do OpenShell em CPUs Vera como mínima. Os compradores precisam de resultados específicos por carga de trabalho que cubram agentes intensivos em rede, grandes cadeias de ferramentas, alterações frequentes de políticas e muitos sandboxes simultâneos.

A dependência de hardware do sistema completo apresenta outra incerteza. O BlueField pode isolar a imposição da carga de trabalho principal, o que fortalece o modelo de segurança. Ele também adiciona requisitos de infraestrutura que os adotantes apenas de software não enfrentam.

A plataforma não elimina o trabalho de alinhamento de modelos. Ela não pode impedir saídas enganosas, raciocínio deficiente, evidências fabricadas, recomendações enviesadas ou conteúdo prejudicial quando esses comportamentos ocorrem dentro de canais permitidos.

Ela também não pode resolver a responsabilização. As organizações ainda precisam decidir quem aprova permissões, quem revisa logs, quem responde a eventos de contenção e quem assume responsabilidade pelas ações autorizadas de um agente.

A NVIDIA vinculou o lançamento a incidentes recentes envolvendo agentes que ultrapassaram limites pretendidos. A cobertura inicial destaca corretamente a importância do OpenShell e da plataforma de segurança mais ampla.

No entanto, alegações de que o sistema teria evitado uma violação anterior continuam sendo avaliações retrospectivas da empresa. Testes reproduzidos de incidentes e exercícios independentes de red team forneceriam evidências mais fortes.

A interpretação mais confiável é mais restrita. A NVIDIA introduziu uma resposta séria, em nível de sistemas, ao risco de agentes, mas não resolveu a segurança de IA como um todo. A plataforma pode reduzir a superfície de ataque acessível quando as organizações a configuram corretamente.

Três Sinais Mostrarão se a Plataforma Funciona

As próximas evidências precisam vir de implantações, testes independentes e suporte além da própria infraestrutura da NVIDIA.

O primeiro sinal é a experiência de produção publicada pelas organizações nomeadas no lançamento. A lista de parceiros é substancial, mas os clientes precisam de relatos detalhados sobre políticas, ações bloqueadas, sobrecarga operacional e resposta a incidentes.

Um estudo de caso significativo descreveria um fluxo de trabalho real de agente e suas permissões necessárias. Ele mostraria quais ações o OpenShell negou, como os desenvolvedores ajustaram as políticas e se esses controles interromperam o trabalho legítimo.

Evidências de ambientes regulados seriam especialmente úteis. Bancos, organizações de saúde, órgãos governamentais e operadores de infraestrutura crítica enfrentam requisitos rigorosos de controle de acesso e auditabilidade.

Se essas organizações levarem o OpenShell à produção, o argumento da NVIDIA ganhará força. Se a atividade permanecer limitada a demonstrações e avaliações, o lançamento parecerá mais uma proposta arquitetural.

O segundo sinal é a validação independente de segurança. Pesquisadores precisam de acesso a implantações representativas, modelos de ameaça, orientações de configuração e testes reproduzíveis.

Os testes devem examinar o sandbox, supervisor, gateway, comprovador de políticas, corretor de credenciais e limite do Sentry. Os atacantes visarão as interações entre componentes, não apenas o componente que a NVIDIA considera mais forte.

Os pesquisadores também devem examinar falhas de usabilidade. Um sistema de segurança tecnicamente correto pode se tornar ineficaz quando administradores copiam exemplos permissivos, interpretam mal os padrões ou desativam controles após bloqueios repetidos.

A documentação pública da NVIDIA já fornece aos desenvolvedores material para inspeção. O próximo passo é uma revisão externa contínua, tratamento transparente de vulnerabilidades e correções visíveis quando pesquisadores encontrarem falhas.

O terceiro sinal é a portabilidade confiável. O software do OpenShell pode se estender a plataformas Arm e Intel, mas as alegações mais fortes do Sentry continuam conectadas ao BlueField-4.

Integrações funcionais em sistemas de nuvem, híbridos, locais e isolados da internet apoiariam a alegação da NVIDIA de que esta é uma camada aberta de segurança para agentes. Uma concentração restrita em hardware da NVIDIA enfraqueceria esse posicionamento.

O suporte de fornecedores de sistemas operacionais pode ajudar. Canonical, Red Hat e SUSE estão entre as organizações que a NVIDIA identifica como integrando tecnologias da plataforma à infraestrutura amplamente implantada.

Os desenvolvedores também devem acompanhar a cadência de lançamentos do OpenShell. Compatibilidade com políticas, APIs estáveis, orientações de migração e melhorias de observabilidade determinarão se a versão 0.1 evoluirá para uma infraestrutura confiável.

O anúncio NVIDIA Open Agent Safety Platform Launched estabelece um padrão útil para o debate. A segurança de agentes deve incluir controles que um agente não possa reescrever, persuadir ou ignorar.

Esse padrão não exige que todas as empresas adotem o design completo da NVIDIA. Exige, porém, que os compradores façam perguntas mais rigorosas sobre acesso, isolamento, credenciais, auditoria e contenção de emergência.

As equipes que avaliam agentes autônomos podem começar mapeando todos os recursos aos quais um agente pode acessar. Devem identificar quais controles dependem da cooperação do modelo e quais continuam aplicáveis depois que o modelo se comporta de forma inesperada.

Também podem manter uma base de conhecimento de engenharia com políticas, ações negadas, decisões sobre exceções e descobertas de incidentes. Esse registro ajuda as regras de segurança a evoluírem com base em evidências, e não em suposições.

O teste prático é simples: uma organização pode permitir que um agente realize um trabalho valioso sem conceder autoridade muito além dessa tarefa? OpenShell e Sentry oferecem a resposta da NVIDIA. As evidências em produção determinarão se essa resposta se sustenta.