O erro mais perigoso de um agente de código nem sempre começa com um prompt malicioso. Às vezes ele recebe uma tarefa comum, interpreta um detalhe errado e age rápido demais — porque alguém lhe entregou acesso a coisas que aquela tarefa nunca precisaria tocar.
Essa é a ideia central de um experimento publicado pelo The New Stack: prompt e escolha de modelo ajudam, mas não são a última barreira. A barreira que continua de pé quando o time muda o modelo, enxuga instruções ou testa um fluxo novo é a permissão que simplesmente não existe.
O problema de dar a chaveiro inteiro para uma tarefa pequena
Serviços tradicionais costumam ter um trabalho previsível. Um serviço de pagamentos lida com pagamento; uma integração de e-mail envia e-mail. Um agente é mais instável: numa execução ele lê um ticket, na outra atualiza documentação e, em outra, pode sugerir uma alteração de configuração.
Dar a ele o conjunto de permissões acumulado dessas possibilidades cria um atalho: uma tarefa de revisão passa a carregar capacidade para apagar, publicar ou alterar algo que não tem relação com ela. Se o agente se confundir, o raio de dano já está pronto antes da primeira chamada de ferramenta.
Por que confiar no prompt não basta
No teste relatado pela publicação, uma instrução adicional fez um modelo mais cauteloso evitar reembolsos indevidos. É uma boa melhoria, mas frágil como controle de segurança. Um prompt pode ser reescrito; um modelo pode ser trocado para reduzir custo; uma configuração pode mudar sem que ninguém perceba o impacto naquele guardrail.
Já uma ação bloqueada por falta de permissão não depende de o agente “tomar a decisão certa”. Ela falha no ponto em que deveria falhar: antes de mexer no recurso. Essa diferença importa especialmente quando o agente tem acesso a produção, credenciais, faturamento, deploy ou dados de cliente.
Acesso por tarefa é mais útil do que acesso pelo cargo
O experimento comparou credenciais amplas, um perfil estático, permissões por tarefa e elevação just-in-time. O resultado deve ser lido como evidência de um teste específico — não como regra universal —, mas a direção é prática: o acesso por tarefa reduziu muito o conjunto de privilégios ativos sem impedir a execução das tarefas previstas.
Para um time que usa agentes no dia a dia, a pergunta deixa de ser “o que esse agente talvez faça um dia?” e passa a ser “o que ele precisa fazer nesta execução?”. Essa mudança evita tanto o perfil genérico largo demais quanto o perfil de cargo que bloqueia trabalho legítimo e abre brechas inúteis.
Um desenho mínimo para colocar em prática
- Declare o escopo antes da execução: leitura de repositório, abertura de PR, consulta de logs ou alteração de ambiente são permissões diferentes.
- Faça a credencial expirar junto com a tarefa: uma chave temporária que continua viva depois do job volta a ser uma chave ampla.
- Crie escalada explícita: se a tarefa precisar de algo extra, registre o motivo e aprove ou negue aquele passo.
- Guarde também as tentativas negadas: elas mostram escopo mal definido, tentativa exploratória ou um fluxo que merece revisão.
- Separe leitura de escrita: o agente que investiga um incidente não precisa ganhar, por padrão, poder para corrigir produção.
Não existe permissão mínima perfeita no primeiro dia. O ponto é transformar o ajuste em rotina: observar o que cada execução realmente usou, encurtar o que está sobrando e tornar visível qualquer elevação. Agente útil não é agente solto. É agente capaz de terminar o trabalho certo sem carregar autoridade para criar o problema errado.
