Doze ataques contra aprovacao de agentes de pagamento revelam que o “segundo fator” de agentes de IA pode ser forjado em grande parte dos runtimes atuais

A pergunta que da titulo ao artigo — “aprovar o que, exatamente?” — ataca uma premissa implicita em quase todo sistema de aprovacao humana para agentes de IA hoje: que pedir confirmacao antes de uma acao sensivel (pagar, apagar, enviar) funciona como um segundo fator de autenticacao. Os autores argumentam, e demonstram experimentalmente, que isso so e verdade sob duas condicoes raramente garantidas: que comprometer o agente nao seja suficiente para produzir a aprovacao, e que a aprovacao nomeie exatamente o efeito que esta sendo autorizado — nao uma descricao generica ou editavel depois do fato.

Para testar essas condicoes, os autores definem doze classes de ataque contra o caminho de aprovacao — destinatarios-isca escondidos atras de um nome legitimo, cancelamento silencioso de um valor apos a aprovacao, preenchimento de campos de cartao com dados diferentes dos mostrados, falsificacao do rotulo exibido ao usuario, ocupacao fraudulenta de um processo de inscricao e divisao de uma transacao grande em varias pequenas para escapar de limiares de revisao — e os aplicam contra tres sistemas reais de agentes de pagamento: o Agent Payments Protocol (AP2), o design de aprovacao vinculada a acao da Microsoft, e o mecanismo de elicitacao do Model Context Protocol (MCP). Uma auditoria complementar de dez runtimes de agentes em producao encontrou que nenhum mantem um registro de aprovacao verificavel por um terceiro independente, que limites de taxa contra tentativas repetidas de aprovacao (flood limits) estao ausentes onde seria possivel medi-los, e que em quatro de oito runtimes onde a vinculacao era mensuravel, os argumentos da chamada podiam ser alterados depois que a aprovacao humana ja havia sido concedida.

Como contramedida de referencia, os autores constroem o ASU (Agent Step-Up): um gateway que renderiza o cartao de aprovacao a partir de um descritor canonico do efeito da acao (nao uma descricao livre que o agente pode manipular), faz um passkey no proprio telefone do usuario assinar o digest criptografico desse cartao, e executa apenas a chamada exatamente correspondente ao que foi assinado — eliminando a janela entre “o que foi mostrado” e “o que foi executado”. As propriedades de vinculacao, uso unico e nao-repudio em nivel de chave sao provadas formalmente com a ferramenta Tamarin sob tres hipoteses declaradas e 53 lemas, e testadas empiricamente em 27.108 execucoes automatizadas e 609 pares de ataque do benchmark AgentDojo, onde o ASU bloqueia substituicao, replay e expansao de concessao, reduzindo o sucesso de ataques de narrativa forjada de 0,54 para 0,03.

O achado mais importante para quem avalia a seguranca de agentes de pagamento hoje e que a defesa nao e gratuita nem completa: usando 15 modelos de linguagem atuais como aprovadores automatizados, o cartao confiavel eleva a taxa de captura de ataques de 0,30 para 0,98, mas ao custo de rejeitar 16% de quase-acertos inofensivos (atribuido em boa parte a um artefato de placeholder nos proprios estimulos de teste), um segundo dispositivo de confirmacao nao adiciona nada mensuravel sobre uma confirmacao confiavel no mesmo host, inundacao de tentativas (flooding) ainda tem sucesso entre 0,45 e 0,60 contra um aprovador modelado, e — o ponto mais fundamental — nenhum mecanismo de aprovacao impede efeitos que a politica subjacente ja permite. Ou seja, mesmo a melhor defesa testada protege contra forjar ou adulterar uma aprovacao, mas nao substitui a necessidade de politicas de permissao corretamente restritivas antes de delegar poder de pagamento a um agente autonomo.