Aprovar sugestão de agente não é controle de segurança

Imagine uma issue de bug num produto pequeno.

O agente lê a descrição, sugere a label bug, escolhe um componente, ajusta o campo de prioridade e explica o motivo. Na tela aparece uma coisa bem confortável: rationale, confidence e um botão para aceitar.

Isso é ótimo. De verdade. A interface tira fricção de uma tarefa chata e deixa a revisão mais rápida.

O problema começa quando o time olha para esse botão como se ele fosse uma barreira de segurança.

Approval melhora o fluxo de trabalho. Ele não decide sozinho o que o agente pode fazer. Se o agente já tem permissão para aplicar uma mudança diretamente, o botão de aprovação virou conveniência, não fronteira. A fronteira real está no escopo da permissão, no threshold de confiança, nos artefatos que ficam para auditoria e no que acontece quando ninguém está olhando.

Revisão humana é interface. Permissão é política.

Essa separação parece detalhe semântico, mas muda bastante a forma de operar agentes.

Uma revisão humana responde: "esta sugestão específica faz sentido?"

Uma política de permissão responde outra pergunta: "este agente pode executar esta classe de ação neste contexto?"

As duas coisas podem trabalhar juntas. Na prática, deveriam. Mas uma não substitui a outra.

Se o agente pode fechar issues, reatribuir responsáveis e mexer em campos sensíveis sem pedir confirmação, a presença de uma tela de approval em outros casos não protege o sistema inteiro. Ela só protege o caminho em que a ação foi configurada para esperar alguém.

É aqui que muita automação começa bonitinha e envelhece mal. Primeiro o time libera labels automáticas. Depois prioridade. Depois assign. Depois close. Cada passo parece pequeno. Meses depois, ninguém sabe exatamente quais ações passam direto, quais viram sugestão e quais dependem do usuário que acionou o agente.

Não precisa demonizar automação. Só precisa desenhar o contrato antes de chamar o botão de controle.

Quatro camadas que não deveriam se misturar

Gosto de separar esse tipo de fluxo em quatro camadas: permissão, sugestão, confiança e rationale.

Permissão

Permissão é a parte menos charmosa e mais importante. Ela define quais ações o agente consegue aplicar de verdade.

Um agente pode ter autorização para adicionar labels, mas não para fechar uma issue. Pode editar campos de triagem, mas não trocar o responsável. Pode abrir um draft pull request, mas não fazer merge. Pode comentar numa tarefa, mas não alterar o status final.

Esse limite precisa existir fora do texto do prompt. Prompt ajuda a orientar comportamento, mas não é controle de acesso. Se a ferramenta aceita a chamada, o modelo eventualmente vai encontrar um caminho para chamá-la, seja por erro, ambiguidade ou instrução ruim.

Sugestão

Sugestão é o que fica aguardando revisão. É uma boa camada para ações reversíveis, ações com impacto moderado ou casos em que o agente tem informação suficiente para propor, mas não para decidir sozinho.

Uma label simples pode passar direto quando a confiança é alta. Fechar uma issue talvez nunca devesse passar direto num repositório pequeno, porque o custo de esconder um bug real costuma ser maior do que o tempo economizado.

O importante é não tratar "ficou como sugestão" como propriedade natural do agente. Isso é configuração de produto. Alguém decidiu que aquela ação, naquele nível de confiança, naquele workspace, deve parar antes de ser aplicada.

Confiança

Confidence ajuda a roteirizar atenção. Ela pode dizer: "isso parece óbvio, talvez possa aplicar" ou "isso está duvidoso, melhor mostrar para alguém".

Mas confidence não mede impacto de produto.

Uma sugestão de label com baixa confiança pode ser irrelevante. Uma sugestão com alta confiança pode ser perigosa se a ação for sensível. O modelo pode estar muito confiante de que a issue é duplicada e ainda assim fechar o relato que continha o único detalhe útil para reproduzir o bug.

Use confidence para decidir o caminho de revisão. Não use como selo de verdade.

Rationale

Rationale é a justificativa. Quando funciona bem, reduz aquela sensação de "por que isso mudou?" no histórico da tarefa.

Só que rationale precisa ficar preso à ação certa. Se o agente aplica três mudanças e deixa uma explicação genérica, a auditoria continua fraca. O ideal é conseguir ler o histórico e entender: esta label entrou por este motivo, este campo mudou por este sinal, esta ação foi aceita por esta pessoa.

Sem isso, o time ganha uma automação que parece transparente no dia da demo e opaca na semana seguinte.

Um fluxo pequeno, mas operável

Vamos pegar uma issue realista:

Título: Checkout trava quando o cupom expira
Descrição: cliente aplica cupom, espera alguns minutos e tenta pagar.
Resultado: botão de pagamento continua habilitado, mas a API retorna erro.

Um fluxo saudável poderia ser assim:

o agente sugere bug, checkout e uma prioridade inicial;
label simples com alta confiança pode ser aplicada direto;
prioridade média fica como sugestão;
assign e close sempre exigem revisão;
toda mudança carrega uma justificativa curta no histórico;
se o agente abrir PR, o controle volta para review de código, teste e branch.

Repare que o approval não é a primeira barreira. Antes dele já existe uma decisão sobre o que o agente pode tentar fazer.

Também existe uma diferença entre triagem e resolução. Automatizar label é uma coisa. Fechar a issue porque o agente "achou" que o bug foi resolvido é outra. Abrir um draft PR a partir dela é outra ainda.

Cada degrau merece uma política diferente.

O controle começa antes da execução

Quando um agente trabalha a partir de uma tarefa externa, como uma issue do Linear atribuída ao Copilot cloud agent, o botão final de review é só uma parte do desenho.

O controle começa bem antes:

qual modelo vai executar a tarefa;
qual agente ou workflow customizado será usado;
qual branch base ele deve considerar;
qual branch de trabalho ele pode criar;
quais instruções por comentário entram na sessão;
em qual ambiente efêmero ele vai rodar;
onde o progresso fica visível;
quem revisa o pull request no fim.

Esse conjunto importa porque reduz o espaço em que uma instrução vaga vira mudança real.

Comentário para orientar sessão é prático. Também é perigoso se virar um canal informal de requisito. Se alguém escreve "aproveita e ajusta o fluxo de cupom também" num comentário solto, isso precisa aparecer no rastro da tarefa. Caso contrário, o PR chega com mudança legítima, mas sem contexto suficiente para revisão.

Ambiente efêmero também ajuda, porque evita sujeira local e torna a execução mais reproduzível. Mas ele não elimina review. Um agente pode trabalhar num ambiente limpo e ainda implementar a coisa errada.

Branch é outro freio simples. Um agente que só pode abrir draft PR numa branch isolada é muito diferente de um agente com permissão ampla para alterar estado principal do projeto.

Um checklist para começar sem teatro

Se eu fosse ligar automação de agente num repositório pequeno, começaria com um escopo quase chato.

Pode aplicar direto:
- labels de baixa consequência;
- campos de triagem bem definidos;
- type quando a regra for objetiva.

Deve virar sugestão:
- prioridade;
- responsável;
- milestone;
- fechamento de issue;
- alteração que muda fluxo de trabalho de outra pessoa.

Nunca deve ser só "confia":
- merge;
- mudança de permissão;
- deleção;
- publicação;
- qualquer ação difícil de reverter.

Depois eu colocaria algumas regras operacionais:

toda ação automática precisa de rationale;
baixa e média confiança param para revisão;
ação sensível não passa direto mesmo com alta confiança;
alguém é owner da automação, não "o time";
mudanças de threshold entram em review como configuração de produção;
logs precisam mostrar quem pediu, o que o agente fez e por quê;
PR aberto por agente segue review normal.

Isso parece conservador. Na prática, é o jeito mais barato de descobrir onde a automação realmente ajuda.

Quando o fluxo amadurece, você aumenta o escopo. Não o contrário.

O erro caro é automatizar exceção

Triagem repetitiva é um bom lugar para agente. Ela tem sinais recorrentes, baixa criatividade e muito trabalho manual.

O risco aparece quando o time usa o mesmo nível de automação para exceções.

Uma issue duplicada pode parecer óbvia, mas conter um detalhe novo de ambiente. Uma prioridade pode parecer baixa, mas afetar o único cliente que paga a conta. Um assign pode parecer natural, mas jogar trabalho invisível para alguém que não estava no contexto.

Nesses casos, a pergunta não é "o agente acertou na maioria das vezes?"

A pergunta é: "quando ele errar, o erro vai ficar visível cedo o bastante?"

Approval ajuda nessa visibilidade quando a ação para na fila. Rationale ajuda quando a justificativa fica no lugar certo. Confidence ajuda quando roteia o que precisa de atenção. Permissão ajuda quando impede que certas classes de erro sejam executadas.

Separadas, essas camadas dão controle. Misturadas, dão uma sensação de controle.

O teste mental antes de liberar

Antes de ativar uma automação, faça um exercício simples: remova a tela de approval da sua cabeça e olhe só para o que o agente consegue fazer.

Ele pode fechar? Pode reatribuir? Pode mudar prioridade? Pode abrir PR? Pode escolher branch? Pode tocar em configuração? Pode agir em nome de qualquer usuário?

Se a resposta assusta, o problema não é a interface de aprovação. O problema é a permissão.

Agora faça o segundo teste: imagine que ele executou uma ação errada às três da manhã.

Você consegue descobrir quem pediu, qual instrução entrou, qual confidence foi calculada, qual rationale foi registrada e qual configuração permitiu a ação? Consegue reverter sem caçar contexto em comentário solto?

Se não consegue, ainda falta operação.

O botão é útil. Só não é a barreira.

Eu gosto da direção desses controles porque eles deixam agentes menos mágicos e mais revisáveis. Mostrar sugestão, confiança e justificativa é muito melhor do que aplicar mudança em silêncio.

Mas a revisão visível não pode virar desculpa para permissão frouxa.

Se o agente pode agir sem sugerir, o botão de aprovação não é a barreira. A barreira é o escopo que você deu a ele.

Comece pequeno. Automatize labels e campos simples. Deixe ações sensíveis como sugestão. Exija rationale. Trate confidence como roteamento, não como verdade. E quando o agente mexer em código, volte para o básico que continua funcionando: branch isolada, teste, pull request e review humano.

Automação boa não é aquela que remove todas as decisões do caminho. É aquela que tira o trabalho repetitivo e deixa as decisões importantes mais fáceis de enxergar.