Portões de aprovação humana em fluxos de agentes: quais ações precisam de um

O que é

Um portão (gate) é um ponto no ciclo do agente em que uma ação proposta (uma chamada de ferramenta com seus argumentos) é mostrada a uma pessoa, que a permite, nega ou edita antes de ela ser executada. A especificação do Model Context Protocol diz que deve haver sempre um humano no ciclo, com a capacidade de negar invocações de ferramentas, e que as aplicações devem apresentar prompts de confirmação para as operações. A entrada Excessive Agency, do OWASP, atribui o risco a funcionalidade, permissões e autonomia excessivas, e inclui entre as mitigações exigir a aprovação do usuário para ações de alto impacto. Os produtos implementam os portões como políticas por ferramenta; a documentação de managed agents da Anthropic, por exemplo, descreve always_allow, always_ask e um modo auto, em que o servidor avalia cada chamada e a executa, nega ou pausa, com o aviso de que auto não é um ponto de verificação humano.

Por que importa

Colocar portão em tudo torna o agente mais lento do que fazer a tarefa manualmente e acostuma a pessoa a clicar em "permitir" sem ler. Não colocar portão em nada dá a um agente, que pode ser conduzido pelo conteúdo que lê, o poder de enviar, pagar, apagar e fazer deploy. O portão é o ponto em que autonomia e consequência são equilibradas de forma explícita.

Como aplicar

• Classifique cada ferramenta pela consequência: ações somente de leitura e reversíveis rodam sem portão; ações irreversíveis (apagar, enviar, publicar, pagar, fazer merge), ações visíveis externamente e qualquer coisa que altere credenciais ou permissões recebem um.
• Aplique o portão com base nos argumentos, e não apenas no nome da ferramenta: uma ferramenta de shell pode ser livre para listar e ter portão para remover; uma ferramenta de pagamento pode ser livre abaixo de um valor e ter portão acima dele.
• Mostre a chamada exata: ferramenta, argumentos, alvo e uma justificativa de uma linha dada pelo agente. Um portão que mostra apenas "executar comando?" é decoração.
• Torne a negação informativa: devolva-a ao agente como resultado da ferramenta, para que ele replaneje em vez de repetir a mesma chamada.
• Registre cada decisão, com quem aprovou e o que foi executado; revise o registro em busca de portões sempre aprovados (candidatos à automação) e de negações (candidatas a uma ferramenta mais restrita).
• Prefira remover uma capacidade a colocá-la atrás de um portão, se a tarefa raramente precisa dela.

Armadilhas

Fadiga de aprovação. Portões que uma ferramenta equivalente contorna (um delete com portão ao lado de um shell sem portão). Agrupar muitas ações em uma única aprovação. Tratar uma aprovação como consentimento para o resto da sessão.

Como ler o registro de aprovações

Um portão que é sempre aprovado não é, por isso, um candidato à automação. Portões sobre ações raras e irreversíveis são aprovados quase sempre porque o agente quase sempre as propõe corretamente; a taxa de aprovação reflete a taxa-base de propostas ruins, não o valor do portão. Em vez disso, faça duas perguntas ao registro. A pior chamada que este portão poderia deixar passar é aceitável se for executada sem supervisão? Se não for, o portão permanece, qualquer que seja o seu histórico. O portão dispara em chamadas que não podem levar a esse pior caso? Se sim, restrinja-o ao padrão de argumento que leva a ele (o caminho, o destinatário, o valor) em vez de removê-lo. As negações continuam sendo o sinal mais forte de uma ferramenta ampla demais.