29 de agosto de 2026
O pedido de aprovação do seu agente de IA é um limite de permissão
Peça confirmação para tudo e os usuários param de ler. Confirme só o objetivo e o consentimento fica perigosamente amplo. O limite útil está na ação exata que muda algo no mundo real.
Um usuário diz a um agente de IA: “Exclua o sandbox do Q3.” O agente abre as configurações, encontra o workspace e chega ao controle de exclusão. Se pedir confirmação a cada clique, fica impossível de usar. Se tratar a frase original como consentimento ilimitado, é imprudente. Se perguntar “Continuar?” no fim, o usuário ainda não sabe o que vai acontecer. A decisão de produto difícil não é se vale manter um humano no loop. É onde esse loop começa, o que exatamente o humano está aprovando e quando essa aprovação deixa de valer.
Por isso o pedido de aprovação deve ser tratado como parte do modelo de permissões, e não como uma fricção educada acrescentada depois que o agente já está pronto.
Os dois extremos ruins
O primeiro design ruim pede confirmação para cada mudança de estado. Abrir a página de cobrança? Confirme. Escolher a aba anual? Confirme. Preencher o nome da empresa? Confirme. O produto parece cauteloso, mas tantos pedidos seguidos treinam o usuário a aprovar no reflexo. O sistema produziu um teatro do consentimento: muitos cliques, pouca atenção.
O design oposto pergunta uma única vez, no início: “Vou fazer uma limpeza no workspace. Posso prosseguir?” Parece eficiente, até a tarefa se expandir para arquivar registros, remover membros e enviar um e-mail de resumo. O usuário aprovou um objetivo, não cada consequência. Uma instrução ampla em linguagem natural virou um cargo temporário de administrador.
As duas falhas vêm de usar a conversa como camada de autorização. A conversa é boa para estabelecer a intenção. É ruim para definir a capacidade exata que está sendo concedida.
A taxonomia de 2026 da Microsoft sobre modos de falha de agentes deixa explícita a versão de segurança desse argumento. Ela recomenda revisão humana determinística, aprovação separada para subações de impacto, descrições derivadas das chamadas de ferramenta subjacentes e níveis de aprovação baseados em reversibilidade e raio de impacto. Quem tem de impor o limite é a aplicação, não o modelo.
Se mudar uma frase na explicação do agente pode mudar se a revisão aparece ou não, quem controla a revisão é o texto. Um limite de permissão de verdade é controlado pela ação que a aplicação está prestes a executar.
Classifique a consequência, não o botão
Os times costumam começar com uma lista de palavras perigosas: excluir, enviar, pagar, cancelar. Isso ajuda, mas o texto de um botão não é uma política. “Cancelar” pode fechar uma caixa de diálogo ou encerrar uma assinatura. “Remover” pode limpar um filtro ou revogar o acesso de alguém. “Continuar” pode ser o último botão de uma compra.
A classificação precisa da ação, do alvo e do estado ao redor. Uma política prática pode começar com cinco perguntas:
1. Essa ação cria um efeito externo, como uma mensagem, um convite, uma publicação ou uma alteração publicada?
2. Ela movimenta dinheiro ou cria um compromisso financeiro?
3. Ela muda quem pode acessar os dados ou quais permissões essas pessoas têm?
4. Ela exclui dados, encerra uma conta ou altera uma assinatura?
5. Se estiver errada, o mesmo usuário consegue revertê-la de forma rápida e completa?
Isso gera um limite mais útil do que “toda operação de escrita exige confirmação”.
Ação proposta · Comportamento padrão · Por quê
Ler uma página, buscar, filtrar ou abrir uma aba · Prosseguir · Nenhum efeito externo duradouro
Preencher um campo de rascunho não sensível · Prosseguir e manter a ação visível · Reversível antes do envio
Mudar uma preferência local que tem um desfazer claro · Em geral, prosseguir · Raio de impacto pequeno e recuperação fácil
Enviar, publicar, convidar, compartilhar ou alterar acessos · Revisar a ação exata · Afeta outra pessoa ou cruza um limite
Comprar, fazer upgrade, cancelar, encerrar ou excluir · Revisar imediatamente antes da execução · Financeiro ou difícil de reverter
Inserir credenciais ou tomar uma decisão regulada · Exigir controle direto do usuário ou recusar · A aprovação, por si só, não torna toda ação adequada para delegar
Isso se aproxima do modelo de risco de ferramentas do guia da OpenAI para construir agentes, que recomenda classificar as ferramentas por acesso de escrita, reversibilidade, permissões da conta e impacto financeiro. O passo importante é transformar essas propriedades em código e política, e não em mais uma instrução que o modelo pode interpretar com criatividade.
Pergunte no momento da consequência
A aprovação deve aparecer o mais tarde possível, mas antes do efeito externo.
Pense no pedido “Cancele minha assinatura Growth”. O agente pode abrir as configurações, ir até a cobrança e verificar o plano atual sem interromper ninguém. Nenhum desses passos compromete o usuário. A revisão útil aparece quando o agente encontrou o controle Cancelar assinatura de verdade e sabe qual assinatura ele afeta.
Esse momento dá fatos concretos ao pedido de aprovação. Ele pode nomear a ação e o alvo em vez de parafrasear a instrução inicial. E evita pedir ao usuário que aprove uma operação que o agente talvez nem consiga encontrar.
Há uma distinção clara aqui:
– Esclarecimento é quando a ação pretendida ou o alvo é ambíguo. “Remova o Alex” exige uma pergunta se dois membros se chamam Alex.
– Aprovação é quando a ação pretendida está clara e a aplicação está pronta para executar um passo de impacto. Deve ser uma decisão fechada: Aceitar ou Recusar.
Misturar os dois cria conversas enlouquecedoras. O agente pergunta “Tem certeza?” quando ainda nem sabe a qual registro o usuário se referia. Ou colhe a aprovação primeiro, encontra depois outro controle de confirmação e trata a resposta anterior como permissão para essa nova ação.
A sequência mais segura é intenção, resolução, revisão, execução. Uma confirmação que o próprio site pede depois é uma nova ação executável e merece a sua própria decisão.
O pedido de aprovação deve descrever a ação executável
Um agente pode dizer “Só estou arrumando o workspace” enquanto a próxima chamada de ferramenta remove um membro. Não importa se essa discrepância é maliciosa, injetada ou um simples engano. A interface de aprovação não pode confiar na narração do agente para descrever a autoridade que ele está pedindo.
Em vez disso, monte o texto da revisão a partir do objeto de execução. Mostre o controle, o alvo, o valor selecionado, o destino e o escopo relevante que a aplicação resolveu. “Clicar em Excluir conta da Acme” é útil. “Prosseguir com a limpeza” não é.
A taxonomia da Microsoft chama a versão fraca de lavagem de descrição (description laundering): o agente apresenta um resumo inofensivo que esconde uma ação subjacente de impacto maior. A defesa proposta é direta. Gere a descrição da aprovação a partir da chamada de ferramenta real ou do controle da página, e não de um texto livre do modelo.
Isso importa mesmo quando ninguém está atacando o sistema. Modelos comprimem. Omitem ressalvas. Usam “isso” para se referir ao objeto errado. A camada de execução já tem os argumentos exatos, então a revisão deve usá-los.
– Aparece porque uma política determinística classificou a ação executável, não porque o modelo resolveu perguntar por conta própria.
– Nomeia a ação, o alvo, o destino e o escopo em termos que o usuário consegue verificar.
– Oferece uma forma real de recusar e não esconde o passo de impacto dentro de um lote.
– Autoriza uma tentativa, não o resto da conversa.
O consentimento deve ser de uso único e vinculado ao estado
A pergunta mais esquecida vem depois que o usuário clica em Aceitar: o que exatamente esse clique autorizou?
Suponha que a revisão mostrava “Excluir sandbox do Q3”. Enquanto o card estava aberto, a página foi renderizada de novo e o elemento por trás dele agora aponta para o workspace de produção. Ou a rota mudou. Ou o destinatário de um formulário mudou. Se a aprovação é representada por um booleano chamado approved, o agente pode executar a ação sobre um estado que o usuário nunca viu.
Em vez disso, a aprovação deve ficar vinculada a uma impressão digital da ação pendente. Ela pode incluir a identidade do elemento, o tipo de ação, o rótulo do alvo, o destino, o estado do formulário, o contêiner, a origem e a rota. Imediatamente antes da execução, a aplicação compara a ação atual com a que foi revisada.
Se algo relevante para a segurança mudou, a execução para. A aprovação antiga é consumida mesmo assim, para que não possa ser reaproveitada quando a página voltar ao estado anterior. Se a execução der certo, ela também é consumida. Uma revisão, uma tentativa, um alvo inalterado.
Não é cerimônia demais. É o mesmo princípio das requisições assinadas e dos tokens de uso único: a autoridade deve ser restrita, atribuível e de curta duração. As orientações da Microsoft para a camada de aplicação defendem que a revisão humana impeça os agentes de se autoautorizarem em ações de impacto, com gatilhos impostos por código e a possibilidade de intervir durante a execução. O consentimento vinculado ao estado é o que permite a esse princípio sobreviver a uma interface dinâmica.
A aprovação é uma camada, não o sistema de segurança
Nem o pedido de aprovação mais bem desenhado consegue sustentar sozinho todo o modelo de segurança. Um usuário pode aprovar uma ação ruim porque o alvo é confuso. Uma injeção de prompt pode distorcer o caminho que levou à revisão. Uma página comprometida pode apresentar um contexto enganoso. Algumas tarefas devem ficar fora da autoridade do agente, com ou sem consentimento.
O system card do ChatGPT agent, da OpenAI, apresenta as confirmações ao lado do treinamento do modelo, de monitores automatizados, de capacidades restritas e de supervisão ativa em contextos sensíveis. Essa estrutura em camadas é o modelo mental certo. A aprovação limita o estrago de um erro. Não prova que o raciocínio anterior estava correto.
O resto do sistema ainda precisa de:
– acesso com privilégio mínimo a ferramentas e dados;
– bloqueios determinísticos para alvos proibidos e entradas sensíveis;
– um controle para parar durante uma tarefa de várias etapas;
– uma nova leitura da interface depois de cada ação;
– uma auditoria final do resultado pedido antes de declarar sucesso;
– logs que conectem o pedido do usuário, a revisão, a execução e o resultado.
A auditoria final é especialmente importante. Aceitar significa “você pode tentar exatamente esta ação”. Não significa que o clique funcionou, que o estado certo mudou ou que a tarefa está concluída.
O que escolhemos para o Barkan
No modo execução do Barkan, a navegação de rotina e o trabalho reversível na interface seguem sem um desfile de confirmações. O widget pausa localmente antes de ações classificadas como exclusão de dados, alterações de conta ou de assinatura, movimentação de dinheiro, comunicação externa ou alterações de acesso. A revisão é disparada no caminho de execução, e não fica a critério do modelo.
Uma revisão aceita fica vinculada ao alvo atual da ação e ao estado da página, e é consumida na primeira tentativa de execução. Se o alvo mudar, a aprovação não pode ser reutilizada. Se o site abrir a sua própria confirmação final, esse controle é revisado como uma ação separada. Depois que as ações rodam, o Barkan lê uma versão recém-renderizada da página e faz uma rodada separada de auditoria final antes de informar que concluiu.
Essas escolhas adicionam atrito exatamente onde queremos. O objetivo não é autonomia máxima nem cautela máxima. É o máximo de trabalho útil dentro de um limite de permissão que o usuário consegue entender.
Meça o limite, não só a aceitação
A taxa de aprovação, sozinha, é uma métrica de sucesso fraca. Uma taxa de aceitação de 99% pode significar que o agente sempre acerta. Mas também pode significar que os pedidos de aprovação são tão frequentes e vagos que os usuários já nem leem.
Acompanhe o sistema como um controle:
– Cobertura de revisão: ações de impacto que foram interrompidas antes da execução.
– Taxa de falsas interrupções: ações inofensivas que dispararam uma revisão.
– Taxa de decisão por categoria: aceites e recusas para exclusão, dinheiro, comunicação, acesso e alterações de conta.
– Rejeições por consentimento vencido: tentativas bloqueadas porque o alvo ou o estado mudou durante a revisão.
– Conclusão verificada: ações aprovadas cujo estado final pretendido foi confirmado depois.
– Paradas e correções: tarefas que os usuários interromperam ou redirecionaram antes de um passo de impacto.
Depois, examine exemplos das duas pontas: ações de impacto que escaparam da revisão e ações inofensivas que irritaram os usuários. A política melhora quando os dois grupos encolhem, não quando toda tarefa é empurrada para mais aprovação.
O pedido de aprovação é o momento em que um produto de IA transforma uma previsão em autoridade. Trate-o com o rigor de uma concessão de permissão. Deixe o agente avançar rápido pelo trabalho reversível, parar na ação de impacto exata, mostrar o que vai realmente ser executado e fazer cada “sim” expirar depois de uma tentativa.
O Barkan conclui tarefas de várias etapas no seu produto e pausa na ação exata de alto impacto antes de executá-la.
“A maioria dos usuários não quer mais uma resposta. Quer que mostrem o caminho, ou quer a tarefa pronta. O produto inteiro é isso.”
Gabriel Lancelot
Cofundador, Barkan
