A NVIDIA está usando uma nova publicação de seu AI Red Team para fazer um ponto mais amplo sobre a implantação de IA corporativa: se as empresas quiserem colocar agentes de IA na frente de ferramentas reais, bases de código e dados internos, elas precisam de controles de infraestrutura fora do próprio modelo.

Em uma orientação publicada no NVIDIA Developer Blog, a equipe diz que encontrou repetidamente os mesmos padrões exploráveis ao avaliar agentes corporativos ao longo dos últimos seis meses. Segundo a NVIDIA, os problemas recorrentes foram controle de acesso fraco, execução insegura de comandos, ausência de restrições de saída de rede e segredos em texto simples dentro dos ambientes dos agentes. A importância disso não é que se trate de conceitos de segurança totalmente novos, mas que a NVIDIA argumenta que as atuais pilhas de agentes ainda falham nisso com frequência suficiente para que proteções baseadas em prompts e modelos revisores não devam ser tratadas como a principal linha de defesa.

O alerta da NVIDIA é sobre arquitetura de agentes, não sobre ajuste de prompts

A publicação, intitulada “Four Ways to Deploy More Secure AI Agents”, vem do NVIDIA AI Red Team e foca no que acontece quando um modelo de linguagem grande é conectado a sistemas ao vivo por meio de um harness de agente. A NVIDIA enquadra o problema em termos práticos para empresas: um colega digital que pode revisar um relatório de bug, fazer uma correção, executar testes e enviar um patch pode impulsionar a produtividade, mas a mesma configuração também pode criar software privilegiado com uma superfície de ataque ampla e pouco compreendida.

Esse enquadramento importa porque o conselho se destina menos a pesquisadores de modelos e mais a equipes que constroem sistemas de produção em torno de agentes de IA. A NVIDIA diz que os modos de falha observados apareceram em vários tipos de agentes, de assistentes interativos de programação a assistentes autônomos sempre ativos, e não se limitaram a um único framework.

O principal argumento da empresa é que as defesas dentro do plano de controle do modelo não são confiáveis o suficiente sob pressão adversarial. Segundo a publicação, proteções baseadas em prompts e padrões de “LLM-as-a-judge” foram consistentemente vulneráveis a engenharia social, manipulação gradual no estilo “frog-boiling” e ataques ocultos em fluxos de trabalho aparentemente legítimos. A posição da NVIDIA é que controles determinísticos aplicados fora do modelo são necessários.

Os quatro controles que a NVIDIA diz que as empresas devem priorizar

Primeiro, a NVIDIA diz que controles de acesso devem ser tratados como a primeira camada de defesa. Em suas avaliações, a equipe encontrou agentes que usavam credenciais de usuários individuais, mas podiam ser acessados por qualquer usuário autorizado em uma rede interna. Segundo a NVIDIA, isso não só permitia o uso indevido dos privilégios legítimos do agente, como em alguns casos também criava caminhos para coletar credenciais e usá-las fora do contexto pretendido do agente. A recomendação prática é direta: restringir cada agente a usuários explicitamente aprovados e alinhar as permissões do agente ao usuário que o invoca sob regras de menor privilégio.

Segundo, a NVIDIA alerta que a execução de comandos continua sendo o risco de maior impacto em agentes acessíveis. Muitos frameworks de agentes expõem um shell porque ele é flexível e reduz a necessidade de ferramentas especializadas. Mas, se a saída do modelo puder acionar execução de comandos, então prompt injection ou entrada maliciosa do usuário podem transformar comandos normais de desenvolvedor em um caminho para execução arbitrária de código. A NVIDIA observa que comandos comuns em fluxos de trabalho de software, incluindo instalação de pacotes e execução de testes, podem parecer benignos o suficiente para passar por um modelo revisor e ainda assim permitir comprometimento.

A empresa recomenda ambientes de execução em sandbox, como Docker ou NVIDIA OpenShell, restrições em nível de sistema operacional que impeçam gravações fora de espaços de trabalho não executáveis e listas de अनुमति muito estreitas para comandos executáveis quando o acesso à linha de comando for inevitável. Ela também destaca um risco mais sutil: mesmo sem shell, ferramentas de leitura e gravação de arquivos podem permitir escalada de privilégios se um agente puder modificar arquivos de inicialização, arquivos de configuração ou outros locais que depois sejam executados por outro processo.

Terceiro, a NVIDIA diz que a conectividade de saída deve ser bloqueada com políticas de egress de rede de negação por padrão. Segundo o Red Team, conexões de saída irrestritas simplificam a exfiltração de dados e permitem reverse shells ou outro acesso direto do operador ao runtime do agente. A NVIDIA relata que, quando os controles de egress foram corretamente aplicados, os ataques ficaram mais lentos, menos confiáveis e mais difíceis de manter, porque as interações precisavam continuar passando pelo agente em vez de por um canal externo direto. Para os construtores, isso se traduz em uma regra concreta de implantação: permitir apenas os endpoints externos mínimos necessários para a tarefa do agente.

Quarto, a publicação diz que segredos persistentes devem ser mantidos fora dos ambientes dos agentes sempre que possível. As evidências extraídas na publicação da NVIDIA apontam a exposição de segredos em texto simples como um modo de falha recorrente. Sua recomendação mais ampla é gerenciamento rigoroso de segredos, validação cuidadosa de fontes de pacotes e controle rígido das permissões das ferramentas. O fio condutor é reduzir o que um invasor pode roubar ou reutilizar se um agente for manipulado.

Por que isso importa agora para ferramentas de programação e IA corporativa

As recomendações da NVIDIA chegam enquanto mais empresas passam de pilotos de chatbot para agentes que usam ferramentas dentro de fluxos de trabalho de engenharia, TI, suporte e back office. A diferença entre um assistente de chat e um agente operacional é grande: assim que o sistema pode executar scripts, instalar dependências, abrir tickets, consultar sistemas internos ou tocar repositórios, o perfil de risco começa a se parecer tanto com segurança tradicional de software e hardening de endpoints quanto com segurança de modelo.

Isso torna a orientação especialmente relevante para equipes que implantam um assistente de programação ou outras ferramentas autônomas de fluxo de trabalho. Um agente focado em código geralmente precisa executar testes, inspecionar arquivos, instalar pacotes e se conectar a sistemas de controle de versão. Essas são exatamente as capacidades que a NVIDIA diz que podem se tornar inseguras se os controles de segurança dependerem principalmente do julgamento do modelo. A menção a arquivos como configuração do git e configuração do model context protocol também aponta para o ecossistema emergente de ferramentas de agentes, no qual integrações flexíveis podem criar silenciosamente novos caminhos de persistência.

Para compradores de IA corporativa, a conclusão prática é que demonstrações de fornecedores mostrando alta taxa de conclusão de tarefas não bastam. Os compradores precisam perguntar onde a execução acontece, se o runtime é isolado, quais destinos de rede são permitidos, como a identidade do usuário é propagada e se credenciais de longa duração chegam a ficar dentro do ambiente do agente. Essas questões afetam confiabilidade e governança tanto quanto segurança pura.

Evidências, alegações e o que permanece não verificado

Esta história se baseia quase inteiramente na própria reportagem da NVIDIA via NVIDIA Developer Blog, com uma segunda fonte simplesmente refletindo o mesmo item em um feed do Google News. Isso significa que as descobertas centrais devem ser lidas como observações de red team reportadas pelo fornecedor, e não como medições independentes do setor.

Ainda assim, a NVIDIA fornece especificidade útil. Ela diz que seu AI Red Team avaliou vários agentes nos últimos seis meses e encontrou padrões exploráveis recorrentes entre frameworks e harnesses. Também dá exemplos concretos de comportamentos de risco, incluindo usar um shell para executar instalações de pacotes ou scripts, escrever em arquivos de inicialização do shell e aproveitar tráfego de saída irrestrito para exfiltração ou acesso remoto.

Mesmo assim, a publicação não quantifica quantos agentes foram testados, quais fornecedores ou pilhas de código aberto estavam envolvidos, com que frequência cada modo de falha apareceu ou quantos incidentes ocorreram em produção. Também não apresenta dados comparativos de benchmark mostrando a eficácia de um conjunto de controles em relação a outro. Como resultado, a orientação é melhor entendida como conselho arquitetônico prático de um Red Team com experiência direta em testes, e não como uma pesquisa abrangente de mercado.

A crítica à filtragem de prompts e às configurações de LLM-as-a-judge também é a avaliação da NVIDIA. Muitas equipes de segurança provavelmente concordarão com a direção geral, mas o artigo não inclui resultados de testes validados externamente nas evidências fornecidas. Isso não torna o alerta menos relevante; significa que os leitores devem separar a lição geral de qualquer suposição de que todos os produtos de agentes falham da mesma forma.

Implicações para construtores e equipes de plataforma

Para os construtores, a mudança mais clara é da segurança em nível de aplicação para a segurança em nível de sistema. Se um agente de IA puder tocar recursos próximos da produção, então o design de implantação passa a importar mais do que prompts inteligentes. Limites de sandbox, propagação de identidade, listas de permissões de endpoints e isolamento de segredos tornam-se decisões centrais de produto.

Isso traz implicações de custo e fluxo de trabalho. O sandboxing pode desacelerar a execução ou complicar ambientes de desenvolvimento. Políticas de egress com negação por padrão exigem que as equipes mapeiem dependências em detalhe. A correspondência de permissões por usuário pode forçar integração mais profunda com sistemas corporativos de identidade. Mas essas restrições podem ser necessárias se as empresas quiserem passar agentes de IA de experimentos para fluxos de trabalho corporativos aprovados.

A orientação também sugere uma definição mais madura de automação do ambiente de trabalho. Em vez de perguntar se um agente pode completar um fluxo de trabalho de ponta a ponta, as equipes talvez precisem perguntar se ele pode fazê-lo dentro de um raio de impacto rigidamente limitado. Isso influenciará escolhas de arquitetura em plataformas de IA corporativa, inclusive quais ferramentas são expostas, onde elas rodam e quanta autonomia é aceitável.

O que observar a seguir

Um sinal útil será ver se os principais frameworks de agentes e plataformas corporativas começam a entregar esses controles por padrão, e não apenas como etapas opcionais de hardening. Em particular, construtores devem observar integrações mais fortes de sandboxing, modelos de identidade e autorização mais granulares, políticas de egress de rede mais fáceis de administrar e designs de segredos que evitem credenciais persistentes.

Um segundo sinal é se mais fornecedores publicarem dados de testes adversariais em vez de alegações gerais de segurança. A publicação da NVIDIA levanta preocupações credíveis, mas o mercado ainda carece de evidências consistentes de terceiros sobre o quão comuns são esses modos de falha dos agentes entre produtos.

Por fim, vale acompanhar se os padrões secure-by-default se tornam parte da aquisição de agentes de IA, especialmente em setores regulados. Se os compradores começarem a exigir prova de isolamento e aplicação de menor privilégio, a arquitetura de segurança pode se tornar um diferencial competitivo em vez de uma lista de verificação de back office.

Perspectiva da Creati.ai

A mensagem da NVIDIA é menos sobre um novo exploit e mais sobre uma correção de mercado. A primeira onda de agentes de IA muitas vezes foi julgada por autonomia e conveniência. Esta orientação argumenta que as empresas deveriam julgá-los como operadores de software privilegiados. Essa é uma mudança saudável para a categoria.

Para fundadores e equipes de produto, a lição estratégica é simples: os agentes de IA vencedores na IA corporativa não serão apenas os que concluem tarefas, mas os que podem provar onde rodam, ao que conseguem chegar e o que não podem vazar. A qualidade do modelo ainda importa, mas a arquitetura de implantação está rapidamente se tornando a verdadeira camada de confiança para agentes de IA, automação do ambiente de trabalho e qualquer assistente de programação sério.