Se você precisa decidir o que sua empresa deixa um agente de IA fazer sozinho, a nova lista de riscos da OWASP tem uma mensagem direta: a autonomia excessiva de agentes de IA deixou de ser um item de rodapé. Na edição 2026 do Top 10 para aplicações de LLM, divulgada em agosto, o risco chamado Excessive Agency passou do 6º para o 3º lugar, segundo a análise da Aembit. Neste texto eu explico o que mudou, o que os números de mercado dizem e o que um líder de TI deveria revisar já na próxima semana.
O que mudou no OWASP Top 10 para LLMs em 2026
A lista de 2026 mantém Prompt Injection em primeiro e Sensitive Information Disclosure em segundo. Excessive Agency entra em terceiro, à frente de Supply Chain e Data and Model Poisoning. Na edição de 2025 ele era o LLM06; agora é o LLM03, conforme o ranking publicado pela Imperva.
Um detalhe de método ajuda a entender o peso dessa subida. Pela primeira vez, a OWASP combinou o voto de profissionais, com peso de 75%, e dados de incidentes reais, com 25%. A equipe reuniu 7.714 incidentes de bases públicas de vulnerabilidades e de uma base de danos de IA, e 6.639 tinham detalhe suficiente para classificar, de acordo com a ReversingLabs. Ou seja, não é só opinião de especialista: há incidente catalogado por trás.
Cuidado com a leitura apressada de que esse é “o risco que mais cresce”. Unbounded Consumption, por exemplo, andou quatro posições, do 10º para o 6º. O que torna a subida de Excessive Agency especial é o ponto de chegada: ele vai parar no pódio da lista por causa dos agentes, e isso muda a conversa de segurança.
O que a OWASP chama de autonomia excessiva
A definição é simples. O risco aparece quando uma saída errada ou manipulada do modelo consegue disparar uma ação danosa. A OWASP aponta três causas: funcionalidade excessiva, permissões amplas demais e autonomia demais, como resume a Aembit.
A Imperva descreve de um jeito que eu acho mais útil para quem gerencia times: o risco diz respeito ao que a aplicação pode fazer quando um modelo está no comando. Quais ferramentas ele chama, quais sistemas alcança e até onde uma decisão viaja antes de um humano ver.
Jeremy London, da Keeper Security, disse à ReversingLabs que o modelo “não está só devolvendo uma resposta, está agindo”, o que cria uma superfície de ataque de natureza diferente. Eilon Cohen, da Pillar Security, completa: um único pedido do usuário pode virar dezenas ou centenas de operações por trás. Uma alucinação em um chatbot gera um texto ruim. A mesma alucinação em um agente com acesso a produção gera um registro apagado.
Os números mostram um descompasso entre confiança e controle
Aqui os dados são desconfortáveis. Uma pesquisa da Cequence com a EMA, divulgada em 31 de agosto de 2026 com 202 líderes de TI e segurança de empresas com mais de mil funcionários, encontrou um contraste claro. Segundo o comunicado da pesquisa, 94% confiam que seus agentes não têm acesso além do necessário, mas só 33% aplicam menor privilégio de fato.
- 65% já viram um agente agir fora do escopo, e 29% tiveram impacto mensurável no negócio.
- Só 32% conseguem detectar e conter uma ação fora do escopo em minutos.
- Apenas 34% avaliam a autorização no momento em que o agente age.
- 31% abandonaram pilotos deixando credenciais ativas, e 14% permitem conexões irrestritas a ferramentas externas via MCP.
Outro levantamento, da Cloud Security Alliance encomendado pela Zenity, ouviu 445 profissionais e foi publicado em abril de 2026. Nele, 53% das organizações já tiveram agentes excedendo as permissões previstas, e só 8% disseram que isso nunca acontece. Também apareceram agentes não autorizados: 54% identificaram entre 1 e 100 deles.
Vale lembrar que as duas pesquisas foram encomendadas por fornecedores e têm amostras pequenas. Não as trate como retrato do mercado inteiro. Mesmo assim, a direção é a mesma, e ela bate com o que se vê no Brasil: segundo a Netskope, citada pelo TI Inside, 88% das organizações brasileiras usam plataformas de IA e 79% usam agentes de desenvolvimento de código. Globalmente, as violações em que um serviço de IA devolve dado a quem não deveria acessá-lo passaram de 12 para 31 por organização por semana em um ano. Nas 10 semanas analisadas, as transações com servidores MCP cresceram 375%.
Da lista de LLMs à lista de agentes: o princípio de least agency
Em dezembro de 2025 a OWASP já tinha publicado uma lista própria para agentes, o Top 10 for Agentic Applications, revisado por mais de 100 especialistas. Dois dos seus riscos tocam direto no tema: ASI02, uso indevido de ferramentas, e ASI03, abuso de identidade e privilégio.
O resumo da Teleport dá exemplos concretos. No ASI02, o agente encadeia uma ferramenta inofensiva com uma API sensível, ou repassa uma saída não validada para um comando poderoso. No ASI03, ele reaproveita credenciais em cache ou herda autoridade por uma cadeia de delegação que ninguém desenhou de propósito.
A resposta que aparece nos dois documentos é o least agency, uma extensão do menor privilégio. O agente recebe só o mínimo de autonomia necessário para a tarefa, e não apenas o mínimo de acesso.
O que líderes de TI precisam revisar agora
A nota de pesquisa da CSA sobre a lista 2026 sugere começar refazendo o registro de riscos com Excessive Agency em posição de destaque. A partir dela, eu montaria esta revisão:
- Inventário de agentes. Liste cada agente em uso, inclusive os que times de produto instalaram por conta própria, com as ferramentas, as fontes de dados e os sistemas downstream que cada um alcança.
- Escopo por invocação. Confira se o limite de permissão é imposto no momento da chamada, e não apenas na configuração inicial. Só 34% das empresas da pesquisa da Cequence fazem isso.
- Autorização fora do modelo. A decisão de permitir uma ação não pode depender do julgamento do próprio modelo, como a OWASP recomenda. Coloque a regra em código e em política, em um ponto que o modelo não consiga reescrever.
- Humano no circuito para ações irreversíveis. Atualizar registros, enviar mensagens, publicar conteúdo e disparar fluxos em nuvem pedem confirmação explícita. O modelo pode propor; quem executa é uma pessoa.
- Identidades curtas e com escopo. Prefira credenciais de vida curta por agente, em vez de uma chave de serviço compartilhada. Revogue as credenciais de pilotos encerrados.
- Limites e monitoramento. Defina orçamentos e rate limit por usuário e por sessão, e registre cada chamada de ferramenta, no estilo de observabilidade que times de SRE já usam.
- Conexões MCP. Mantenha uma lista de servidores permitidos. Conexão irrestrita a ferramentas externas é exatamente o que 14% das empresas pesquisadas admitem ter.
Autonomia é decisão de projeto, não padrão de fábrica
Eu não acho que a resposta seja frear os agentes. O ganho de produtividade é real, e a pressão por adoção não vai diminuir. O que muda é a pergunta de projeto: em vez de “o que o agente consegue fazer?”, passe a perguntar “o que ele precisa fazer, e quem vê antes de acontecer?”. A subida para o terceiro lugar no OWASP é um sinal de que o mercado já começou a responder a segunda pergunta.
Se a sua equipe está desenhando agentes para produção e quer revisar escopo, identidades e pontos de aprovação antes do próximo release, fale com o time da Luby. Comece pelo inventário: é o item mais barato da lista e o que mais costuma surpreender.