A NVIDIA publicou em 21 de setembro de 2026, em seu blog, uma análise em que defende que a segurança de inteligência artificial deve ser encarada como um problema de engenharia. Na prática, isso significa requisitos de segurança definidos, controles aplicáveis, responsáveis nomeados e evidências de que as proteções funcionam.
Segundo a empresa, conforme a IA se torna mais capaz, a indústria precisa acelerar a engenharia de segurança, ampliar o acesso a ferramentas defensivas e compartilhar mais rápido o que dá certo.
Fundamentos que sobrevivem à mudança
A internet e a computação em nuvem mudaram a forma como o software opera. As responsabilidades centrais de segurança permaneceram as mesmas: estabelecer identidade, controlar acesso, limitar exposição e verificar se as proteções funcionam.
Agentes de IA acrescentam capacidades novas. Eles raciocinam, usam ferramentas e adaptam ações conforme os dados que encontram.
Isso exige aplicar esses princípios a condições operacionais inéditas.
O texto reconhece a pressão desse ritmo. As organizações querem os ganhos de produtividade da IA, mas as práticas para governar e proteger esses sistemas ainda estão em formação.
A segurança depende de todo o stack do agente
Aplicações dependem de código, dados, identidades, serviços e infraestrutura. A segurança depende de como esses componentes funcionam em conjunto.
Nos agentes, os modelos fornecem capacidades. Os harnesses organizam contexto, ferramentas e fluxos de trabalho.
Os ambientes de execução oferecem a infraestrutura onde as ações acontecem, como detalha a NVIDIA em material complementar sobre onde a segurança se encaixa no stack de um agente de IA.
Cada camada carrega responsabilidades próprias. Dados, instruções e ações circulam pelo sistema inteiro.
Um exemplo do texto mostra por que isso importa. Suponha um agente que atualiza o cadastro de um cliente e encontra instruções maliciosas em um documento anexado.
Ele passa a tentar exportar dados do cliente para um destino não autorizado.
Uma política de rede deveria bloquear a transferência. Logs protegidos deveriam registrar a tentativa de chamada de ferramenta, a decisão de autorização e o resultado.
Assim a equipe de segurança identifica a ferramenta usada e o destino pretendido.
A permissão para atualizar um cadastro não deveria se estender automaticamente à exportação desses dados. O agente pode pedir acesso adicional, mas não pode autorizar esse acesso por conta própria.
Barreiras que não dependem do raciocínio do agente
Uma fronteira de segurança precisa se manter mesmo quando o agente decide errado. O ambiente onde ele roda determina o que é permitido fazer.
Por isso, deve impor limites a arquivos, destinos de rede e processos independentemente do raciocínio do modelo.
Instruções e salvaguardas ajudam a orientar o comportamento. Segurança também exige limites aplicáveis.
Cada agente precisa de identidade rastreável e credenciais restritas à tarefa designada. As organizações precisam de políticas claras sobre quais informações os agentes podem acessar, quais sistemas podem alterar e quais ações exigem aprovação.
Ações consequentes e mudanças de permissão continuam dependendo de aval humano.
Também é necessário verificar a origem e a integridade das ferramentas, habilidades e dependências usadas pelos agentes. Quando algo dá errado, registros protegidos de chamadas de ferramentas, decisões de autorização e resultados ajudam a reconstruir o ocorrido.
Procedimentos claros de revogação de acesso e contenção de incidentes tornam essa evidência acionável.
OpenShell, aliança e parceiros
Para colocar essas ideias em prática, a NVIDIA aponta o OpenShell, runtime seguro de código aberto que aplica políticas fora do alcance do agente e oferece execução em sandbox, governando o acesso a dados, rede e recursos do sistema.
Parceiros da Open Secure AI Alliance estão construindo sobre ele. O DefenseClaw, da Cisco, adiciona uma camada de governança.
A JFrog integra-se ao OpenShell para escanear e verificar habilidades de agentes e aplicar políticas sobre quais habilidades eles podem acessar.
Evidências antes de ir para produção
Antes da implantação, equipes precisam de evidências de que os controles bloqueiam tentativas de obter credenciais além do escopo do agente ou de enviar dados sensíveis a destinos não autorizados.
Os testes devem cobrir também tentativas de mudar permissões ou interferir no monitoramento. E ser repetidos após mudanças relevantes em modelos, ferramentas ou fluxos de trabalho.
Um responsável nomeado deve usar esses resultados para decidir se o sistema está pronto e garantir que falhas levem a ações corretivas. Cada achado pode virar um teste repetível, capaz de checar se a correção continua valendo em versões futuras.
A NVIDIA cita o SafeMind, da CrowdStrike, para testar e fortalecer defesas com simulações repetidas de ataque. Cita também o Prisma AIRS, da Palo Alto Networks, para red teaming contínuo conforme modelos e aplicações mudam.
Modelos abertos e fechados na defesa
Investigar falhas exige ferramentas adequadas à tarefa, aos dados e ao ambiente. Modelos abertos e fechados atendem necessidades complementares.
Modelos fechados oferecem capacidades e serviços gerenciados. Modelos abertos dão aos defensores opções para inspecionar componentes relevantes, adaptar estratégias e trabalhar em infraestrutura sob seu controle.
Durante um incidente, esse controle ajuda a reproduzir a falha e testar uma correção nos próprios sistemas, mantendo evidências sensíveis dentro do ambiente. A IA capaz pode apoiar esse trabalho ao ajudar a encontrar vulnerabilidades, validar correções e investigar ataques.
Por que isso importa
O recado é que a segurança não pode esperar a maturidade das práticas. Ela precisa ser tratada como disciplina de engenharia, com requisitos, donos nomeados e provas.
À medida que a IA se torna mais capaz, a indústria deve acelerar a engenharia de segurança, ampliar o acesso a ferramentas de defesa e compartilhar mais rapidamente o que funciona.
