Uma experiência publicada no The New Stack revela que conceder a um agente de IA permissões mais amplas do que o necessário pode transformar um simples erro lógico em uma operação financeira repetida que o próprio modelo não interrompe. Em um teste com faturas de clientes, um agente de suporte confirmou que o pagamento havia falhado e que o dinheiro do cliente não havia sido debitado, mas executou um reembolso apesar de os dados não o justificarem e repetiu o erro cinco vezes.
O Claude Sonnet 5 conseguiu detectar os seis casos criados para testar essa falha, enquanto o Claude Haiku 4.5 falhou em todos eles. Além disso, uma única linha nas instruções do sistema, solicitando a verificação do status da transação antes da execução de uma ação financeira, foi suficiente para resolver o problema. Mas o autor considera ambas as soluções frágeis: a organização pode substituir o modelo por uma versão mais barata ou alterar as instruções durante um experimento, fazendo a proteção desaparecer sem um alerta claro.
A permissão negada como barreira de segurança
A proteção que resistiu a essas mudanças foi impedir que o agente tivesse a permissão billing:refund desde o início. Nesse caso, a execução falhou na camada de permissões, independentemente do modelo ou da formulação das instruções. Essa é a essência do princípio do menor privilégio na arquitetura de agentes de IA: o objetivo não é apenas impedir o invasor ou proteger tokens secretos, mas também impedir que um agente bem-intencionado execute instruções erradas com rapidez automatizada e sem supervisão humana.
A natureza do agente é diferente da de uma conta de serviço tradicional que desempenha uma função fixa. Um agente de suporte pode ler um tíquete às 09:00, executar um reembolso às 09:04 e alterar o número de assentos às 09:11. Portanto, o conjunto de permissões necessário para todas as suas possíveis atividades ao longo de uma semana não reflete necessariamente o que ele precisa em uma única tarefa.
O que a experiência mediu?
O autor construiu um ambiente de teste com 30 permissões distribuídas por nove domínios em uma API empresarial fictícia, abrangendo tíquetes, usuários, cobrança, assinaturas, arquivos, mensagens, auditoria, administração e pesquisa. Treze permissões eram capazes de alterar ou extrair o estado. A experiência incluiu 20 tarefas, cada uma com um resultado verificável automaticamente, como fechar um tíquete ou reembolsar o valor de uma fatura.
Quatro modelos de permissões foram comparados nos níveis Claude Haiku 4.5 e Claude Sonnet 5, totalizando 160 execuções:
- Permissão ampla: uma concessão de longo prazo que incluía as 30 permissões.
- Função fixa: uma função de suporte que incluía 17 permissões derivadas de uma descrição de cargo típica.
- Restrição por tarefa: concessão das permissões necessárias para cada execução e sua revogação ao término.
- Ativação sob demanda: início sem permissões e solicitação de cada permissão quando necessário, com a respectiva justificativa.
A restrição por tarefa reduz o alcance dos danos
O modelo de restrição por tarefa concluiu todas as tarefas, utilizando aproximadamente uma em quinze das permissões em comparação com a concessão ampla. Os casos de negação acidental e as tentativas repetidas não provocaram aumento significativo no número de chamadas à API.
Já o modelo de função fixa foi o mais fraco nos dois eixos. Ele concedeu 17 permissões, quatro das quais não foram utilizadas por nenhuma tarefa, enquanto não possuía nove permissões essenciais. Ampliar a função até que todas as tarefas fossem bem-sucedidas exigiria 26 permissões, contra uma mediana de apenas duas permissões por tarefa. Assim, a função fixa se torna ampla demais e insuficiente ao mesmo tempo, pois baseia a decisão no cargo, não no trabalho efetivamente realizado.
O modelo de ativação sob demanda alcançou um nível baixo semelhante de alcance dos danos, mas exigiu cerca de 80% mais chamadas à API. Além disso, a negação de permissões no modelo por tarefa ocorreu geralmente em caminhos exploratórios opcionais, enquanto a negação no modelo de função fixa era definitiva, pois bloqueava uma permissão essencial.
Por que isso importa para as organizações?
Os resultados mostram que as capacidades do modelo e as instruções do sistema são camadas de defesa sujeitas a mudanças, enquanto uma permissão não concedida continua eficaz mesmo quando o modelo é substituído ou o prompt é alterado. Por isso, as equipes devem projetar as permissões do agente em torno da tarefa atual e tornar as permissões sensíveis temporárias e auditáveis, em vez de agrupá-las em uma função permanente e ampla.
A experiência continua limitada por um ambiente sintético, 20 tarefas e dois modelos Claude; portanto, não prova que os resultados serão idênticos em todas as organizações ou com todos os modelos. Ainda assim, oferece um indicador prático claro: testar o agente não é suficiente se a arquitetura permitir que ele execute ações de que não precisa, porque uma mudança no modelo ou nas instruções pode alterar o comportamento, enquanto a capacidade de causar danos permanece.