O OWASP GenAI Security Project divulgou a edição 2026 do seu Top 10 para aplicações com LLM e, junto dela, formalizou o Agent Control Standard (ACS), especificação aberta para controlar o comportamento de agentes de IA durante a execução. Para equipes de segurança que já operam agentes conectados a ferramentas, bases internas e sistemas de produção, a leitura prática é uma só: o risco deixou de morar no modelo e passou a morar no que o agente tem permissão para fazer. A ação prioritária é inventariar cada agente em produção, listar as ferramentas e os dados que ele alcança e decidir quais ações exigem aprovação explícita antes de gerar efeito no mundo real.

O que muda no ranking

A nova lista mantém Prompt Injection na primeira posição e Sensitive Information Disclosure na segunda, mas o movimento que importa para engenharia defensiva está mais abaixo: Excessive Agency assumiu a terceira posição no ranking, a maior subida da edição. Para o projeto da OWASP, o salto reflete convergência entre o voto de especialistas e o registro de incidentes: é nas implantações agênticas que o dano tem se materializado. Traduzido para operação, o problema deixou de ser “o modelo disse algo errado” e virou “o agente executou algo que ninguém autorizou”.

Há outra mudança estrutural: a antiga categoria System Prompt Leakage foi aposentada e substituída por Hidden Context Exposure, quadro mais amplo que trata documentos recuperados por RAG, memória entre sessões, respostas de ferramentas e estado da aplicação como superfície de confidencialidade. Times que construíram defesa apenas em torno do sigilo do prompt de sistema ficam com cobertura incompleta, porque o vazamento pode sair por contexto recuperado, memória persistente ou retorno de tool, e não apenas pelo texto de instrução.

O documento também amplia o mapeamento para NIST, MITRE ATLAS, CWE e para a lista dedicada a aplicações agênticas anunciada no fim de 2025. A fronteira entre as duas listas é explícita: quando o modelo é componente dentro da aplicação, vale o Top 10 de LLM; quando ele passa a agir com ferramentas, memória e consequências próprias, o risco migra para o quadro agêntico. É exatamente esse intervalo que o ACS veio endereçar, e a evidência de que ele não é teórico já existe: ataques com agentes autônomos colhem credenciais em janelas de poucas horas quando recebem permissões largas demais.

Como o ACS funciona na prática

Incorporado ao projeto da OWASP em 1º de setembro de 2026, o ACS parte de um princípio direto: empresas não podem depender de agentes opacos operando entre nuvem, SaaS e ambientes locais. Segundo a página oficial do padrão, agentes devem ser inspecionáveis, rastreáveis e instrumentáveis — com visibilidade sobre o que são, o que acessam, o que fizeram e por quê, e com capacidade de controlar o comportamento em tempo de execução.

Na prática, a especificação define como plataformas de agentes expõem hooks de middleware e como políticas de segurança são aplicadas sobre esses pontos, permitindo controles declarativos portáveis entre frameworks — a mesma política escrita uma vez passa a valer para orquestradores distintos — e aplicados durante a execução, não apenas em revisão de código posterior. O desenho lembra a lógica de Zero Trust aplicada a identidades de serviço: cada ação do agente é avaliada contra política antes de produzir efeito, em vez de confiar no escopo definido no momento da implantação.

Uma política declarativa típica tem três partes: o sujeito (qual agente ou qual papel de agente), a ação (qual ferramenta ou classe de ferramenta) e a condição (horário, volume, sensibilidade do dado, exigência de aprovação humana). Exemplo concreto: agente de atendimento pode ler base de conhecimento pública, mas qualquer chamada que toque o cofre de segredos, inicie exclusão de registros ou envie dado para fora do perímetro vira evento bloqueado até revisão. Nada disso exige IA adicional — exige ponto de decisão no caminho da chamada.

Para o time defensivo, isso cria três alavancas: ponto de decisão (o hook intercepta a chamada antes do efeito), ponto de observação (o evento estruturado alimenta trilha de auditoria e SIEM, na linha do padrão mínimo de visibilidade já discutido aqui) e ponto de inventário (saber quais ferramentas, modelos e fontes de dados cada agente alcança). Nenhuma delas obriga a esperar fornecedor: inventário e trilha já podem ser exigidos em contrato e configurados com o que existe hoje.

Onde o NIST se encaixa

A camada OWASP não vive sozinha. A edição mantém matriz de cobertura que mapeia cada categoria para referências externas, incluindo o perfil de IA generativa do AI RMF publicado pelo NIST — documento que o próprio instituto descreve como recurso para identificar riscos únicos da IA generativa e propor ações de gestão alinhadas aos objetivos e prioridades da organização. Para empresas com programa formal de risco, isso significa que as categorias da lista podem entrar no registro sem tradução improvisada.

O movimento do NIST também não parou: o framework principal está em revisão dentro do plano de ação de IA do governo americano, sinal de que o mapeamento entre lista OWASP e arcabouço governamental vai continuar girando. Quem ancorar controles em nomes estáveis de categoria — e não em número de versão de documento — sofre menos com essa rotação e evita retrabalho de auditoria.

Checklist de adoção do ACS

O ACS em versão inicial deve ser tratado como arquitetura de referência, não como produto pronto para instalar. O caminho pragmático, por prioridade:

Prioridade Ação Critério de pronto
P1 Inventariar agentes em produção e piloto Lista com dono, ferramentas acessíveis e dados tocados
P1 Definir ações que exigem aprovação humana Política escrita cobrindo gravação, exclusão, envio externo e execução de código
P1 Registrar toda chamada de ferramenta em trilha estruturada Evento consultável por agente, sessão e ferramenta
P2 Reduzir escopo de credenciais dos agentes Credencial dedicada por agente, sem permissão administrativa
P2 Mapear hooks do framework usado Relatório do que existe hoje e onde falta ponto de decisão
P2 Tratar conteúdo externo como entrada não confiável Páginas, e-mails e documentos sanitizados antes de chegar ao agente
P2 Montar inventário de componentes do agente Manifesto de ferramentas, modelos e fontes de dados por agente, no estilo SBOM

Sinais a monitorar em execução

Enquanto os controles não existem, a detecção precisa cobrir o que um agente abusivo produz de observável: sequências rápidas de chamadas de ferramenta fora do padrão da sessão, acesso a cofre de segredos sem tarefa correspondente, leitura de volume anormal de documentos em pouco tempo e respostas de saída contendo dados que não aparecem nas entradas autorizadas. Cada um desses sinais só é acionável se existe trilha por agente e por sessão — sem ela, o time enxerga o efeito, nunca a causa.

A decisão de orçamento também muda de forma: gastar em hardening de prompt rende menos do que gastar em redução de escopo e telemetria de ação. A subida de Excessive Agency é a OWASP dizendo, com registro de incidentes, que permissão larga é o controle errado para um ator que falha e pode ser enganado; a chegada do ACS é a indústria reconhecendo que falta infraestrutura para corrigir isso durante a execução. Times que moverem o controle para o caminho da chamada de ferramenta ficam à frente do padrão que tende a virar exigência de compra.

Fontes