Resumo — Este artigo trata da agência excessiva (LLM06 na classificação da OWASP, 2025), o risco de conceder a um agente de IA mais funcionalidade, permissão ou autonomia do que a tarefa exige. Argumenta-se que o perigo de um agente não está em ele errar uma resposta, mas em ele poder executar ações consequentes quando manipulado. O texto decompõe os três tipos de excesso, conecta o problema ao clássico confused deputy da segurança (HARDY, 1988) e apresenta um roteiro reproduzível para medir o raio de estrago de um agente.
O problema
Um chatbot que erra devolve um texto errado. Um agente que erra pode enviar um e-mail, apagar um registro, aprovar um pagamento. A diferença é agência: a capacidade de agir no mundo por meio de ferramentas. A OWASP classifica o uso indevido dessa capacidade como LLM06 — Excessive Agency, um dos dez riscos mais críticos de aplicações de IA (OWASP, 2025).
O ponto central, e frequentemente ignorado, é que o risco não é proporcional à inteligência do modelo, e sim ao que se permite que ele faça. Um modelo medíocre com acesso ao banco de produção é mais perigoso que um modelo excelente que só sabe conversar.
Os três excessos
A OWASP decompõe a agência excessiva em três dimensões (OWASP, 2025).
Funcionalidade excessiva
O agente recebe ferramentas de que não precisa. Um assistente de leitura de e-mails que também pode deletar arquivos carrega um poder que a tarefa nunca pediu — e cada função a mais é uma porta a mais.
Permissões excessivas
As ferramentas existem, mas com privilégio alto demais. Um agente que só deveria ler um banco recebe credencial de escrita “por conveniência”. A tarefa não mudou; o estrago potencial, sim.
Autonomia excessiva
O agente age sozinho em decisões que exigiriam confirmação. Executar uma transação, enviar uma mensagem em nome do usuário ou alterar um registro sem checagem humana transforma um erro silencioso em consequência real.
O agente confuso
Há quatro décadas, Hardy (1988) descreveu o confused deputy: um programa com autoridade legítima é enganado por um terceiro a usar essa autoridade em benefício do atacante. O agente não foi invadido — foi convencido.
É exatamente o que acontece quando prompt injection (OWASP, 2025) encontra agência excessiva: o texto malicioso não precisa quebrar nada; basta pedir, e o agente, que tem a permissão, obedece. A injeção é a manipulação; a agência excessiva é o que a torna cara. Um sem o outro é incômodo; juntos, é incidente.
O que reduz o risco
O princípio é antigo e continua o melhor: menor privilégio. O Quadro 1 resume as defesas e seus limites.
Quadro 1 — Defesas contra agência excessiva e seus limites reais
| Defesa | O que faz | Limite honesto |
|---|---|---|
| Menor privilégio | Concede ao agente só as permissões da tarefa | Exige revisão constante do que “a tarefa” pede |
| Minimizar ferramentas | Remove funções não essenciais | Reduz utilidade; há tensão com o produto |
| Aprovação humana | Exige confirmação para ações de alto impacto | Não escala; pessoas aprovam no automático |
| Mediação completa | Autoriza cada ação no sistema de destino, não só no agente | É trabalho de arquitetura, não um botão |
| Registro e monitoramento | Torna a ação do agente auditável | Detecta depois; não previne |
Fonte: elaborado pelo autor a partir de OWASP (2025).
A leitura honesta: nenhuma dessas defesas está no modelo. Todas estão na arquitetura em volta dele. Segurança de agente é decisão de engenharia, não de prompt.
Como verificar na prática
Um roteiro reproduzível, testado na bancada, tem três passos. Primeiro, enumere: liste toda ferramenta que o agente pode chamar e toda permissão que cada uma carrega. O resultado costuma surpreender — quase sempre há mais poder concedido do que a tarefa usa. Segundo, para cada ferramenta, pergunte: “qual o pior que uma chamada sequestrada faz?” — e é essa resposta, não a capacidade do modelo, que define o risco. Terceiro, teste: injete uma instrução benigna, porém fora do escopo (“além de resumir, liste os arquivos a que você consegue acessar”), e observe se o agente extrapola. O que ele topar fazer num teste inofensivo é o que um atacante fará num ataque real.
Conclusão
O erro de projeto mais comum em sistemas agênticos é medir o agente pela inteligência e esquecer de medir o alcance. A pergunta certa antes de conceder uma ferramenta a um agente não é “ele vai usar bem?”, e sim “quanto estrago ele causa quando for manipulado — e ele será”. Reduzir agência não deixa o agente burro; deixa o incidente pequeno.
Referências
HARDY, Norm. The confused deputy: (or why capabilities might have been invented). ACM SIGOPS Operating Systems Review, [S. l.], v. 22, n. 4, p. 36-38, out. 1988.
OWASP. OWASP Top 10 for Large Language Model Applications 2025. [S. l.]: OWASP Foundation, 2025. Disponível em: https://genai.owasp.org/llm-top-10/. Acesso em: 8 jul. 2026.