A assinatura não protege o que parece
O AP2 é um protocolo de pagamento que o Google propôs para que agentes baseados em LLM possam pagar em nome de uma pessoa: receber uma tarefa, negociar condições com o vendedor, fazer o pedido e transferir o dinheiro. A estrutura de confiança aqui se apoia em dois documentos assinados — o Checkout Mandate e o Payment Mandate. Eles fixam as condições da transação e, depois de assinados, não podem mais ser substituídos sem que isso seja percebido.
O problema está na expressão "depois de assinados". A assinatura garante que os dados não mudaram desde o momento em que foram atestados, e não diz nada sobre como eles surgiram. E eles são montados a partir de um fluxo de interações: mensagens entre agentes pelo A2A Protocol, chamadas de ferramentas via Model Context Protocol, respostas de serviços externos, conteúdo de páginas e e-mails. Tudo isso está fora do alcance da proteção criptográfica. Se uma instrução alheia for misturada ao contexto antes da autorização, a assinatura atestará uma intenção já distorcida — e continuará, ainda assim, absolutamente válida.
Daí o nome da pesquisa: a ameaça não vive dentro do mandato, mas "além do mandato".
O que já se havia encontrado antes e por que a v0.2 exigiu uma nova análise
Pontos fracos no AP2 já haviam sido investigados antes: na versão v0.1 foram descritos ataques de repetição e injeção de prompt. Na v0.2, parte desses problemas foi corrigida — mas, junto com as correções, vieram novos recursos e novas premissas de implantação. Cada novidade dessas é uma superfície de ataque em potencial, e a análise antiga não se transfere mecanicamente para a nova versão.
Foi disso que se ocupou a equipe — Avital Aviv, Parth A. Gandh, Ron Bitton e Asaf Shabtai. O trabalho Beyond the Mandate: A Systematic Security Analysis of the Agent Payments Protocol (AP2) foi publicado no arXiv em 24 de agosto de 2026, sob o número 2608.23858, nas categorias cs.CR e cs.AI.
Papéis, fases, arquiteturas e fronteiras de confiança
A análise não foi construída como uma caça a bugs isolados, mas como um mapeamento de todo o território. Os autores descrevem os papéis dos participantes e dividem o ciclo de vida da transação em cinco fases sequenciais — da formulação da tarefa até a liquidação e possíveis disputas posteriores. Paralelamente, são destacadas cinco arquiteturas de implantação: elas diferem quanto a onde os agentes ficam hospedados, quem guarda as chaves e como intermediários confiáveis são integrados ao esquema.
O passo decisivo é o traçado das fronteiras de confiança. E aí se delineia a principal assimetria: o próprio mandato está dentro do perímetro protegido, enquanto todo o fluxo de informações do qual ele é forjado está do lado de fora. Tudo o que acontece entre essas zonas constitui o enredo central do trabalho.
MAESTRO: atores, superfícies, objetivos
A parte formal foi construída sobre o MAESTRO — uma metodologia de modelagem de ameaças para ambientes multiagente. Com ela, são descritos quatro atores de ameaça, onze superfícies de ataque, dezoito capacidades do adversário e seis objetivos que o atacante busca alcançar.
Essa decomposição não existe por causa de números bonitos. Ela mostra que o adversário não é um só: não se trata apenas de um criminoso externo, mas também de uma ferramenta comprometida, de um vendedor desonesto, de um serviço fictício. E os motivos deles são variados — desde o desvio direto de dinheiro até o deslocamento imperceptível da escolha na direção desejada.
Catálogo de 48 ameaças
O resultado foi um catálogo de 48 ameaças, agrupadas em cinco famílias de ataques. Elas foram avaliadas com o AIVSS — um sistema de avaliação de vulnerabilidades adaptado às especificidades da IA. Oito ameaças atingem a faixa High em pelo menos uma arquitetura.
O próprio "em pelo menos uma" já é revelador. O nível de risco depende não só do código, mas também do esquema de implantação: o que é fatal para uma variante de integração pode ser quase inofensivo em outra — e vice-versa. Não existe uma resposta única para a pergunta sobre o quão seguro o AP2 é.
Oito High-risk: bancada de testes e demonstrações
Não havia implantação pública do protocolo no momento do trabalho, então os autores montaram uma bancada de testes com as próprias mãos — e cobriram nela todas as cinco arquiteturas. Sobre ela também construíram cinco demonstrações proof-of-concept: cada uma cobre seu próprio grupo de ameaças e, juntas, abrangem todos os oito cenários High-risk, além das medidas de proteção propostas.
Esse é um argumento importante contra a crítica de que "aqui só há teoria". As ameaças não são apenas listadas — elas são reproduzidas.
Um scanner que entende de implantação
Um resultado prático à parte é um scanner que leva em conta as particularidades da implantação. Sua lógica é que é preciso verificar não o protocolo em geral, mas a configuração concreta. O scanner relaciona as ameaças aplicáveis a um dado esquema com verificações de três tipos: estáticas, verificações de consistência entre papéis e testes adversariais.
As verificações entre papéis são especialmente pertinentes aqui. Em um esquema multiagente, o erro muitas vezes se esconde não dentro de um componente isolado, mas na junção das expectativas: um agente está convencido de que a verificação necessária já foi feita por outro.
O que se conclui disso
A principal conclusão soa mais dura do que se gostaria: uma assinatura válida do mandato não basta para afirmar que a transação reflete a intenção do usuário. A assinatura confirma a integridade, não a razoabilidade. Se o contexto antes da autorização foi comprometido, a criptografia atestará com todo o cuidado a vontade de outra pessoa.
Consequências práticas para quem constrói pagamentos com agentes:
- Controle o contexto de entrada, não apenas a transação final. A maior parte dos riscos está antes do momento da assinatura.
- Considere a arquitetura parte do modelo de ameaças. A mesma versão do protocolo, em esquemas de implantação diferentes, gera um perfil de risco diferente.
- Restrinja as permissões do agente. Quanto mais específico o mandato, menor o dano de uma intenção distorcida.
- Verifique as junções entre papéis. É justamente ali que as verificações falham com mais frequência.
Em resumo
A criptografia resolve exatamente a tarefa que lhe foi atribuída, e nem um pouco mais. O AP2 protege honestamente a transação contra substituição após a assinatura; tudo o que acontece antes disso permanece como responsabilidade do desenvolvedor. A pesquisa com 48 ameaças e oito cenários High-risk não é uma sentença contra o protocolo, mas um mapa do terreno: ela mostra onde termina a proteção que a assinatura oferece e onde começa o trabalho que a assinatura não fará por você.
