La signature ne protège pas ce que l'on croit
AP2 est un protocole de paiement que Google a proposé pour permettre aux agents LLM de payer à la place d'un humain : recevoir une tâche, négocier les conditions avec le vendeur, passer commande et transférer l'argent. Le cadre de confiance repose ici sur deux documents signés — Checkout Mandate et Payment Mandate. Ils fixent les conditions de la transaction, et une fois signés, il n'est plus possible de les substituer sans que cela se remarque.
Le hic, c'est la formulation « une fois signés ». La signature garantit que les données n'ont pas changé depuis leur certification, et ne dit rien sur la manière dont elles sont apparues. Or elles se construisent à partir d'un flux d'interactions : messages entre agents via A2A Protocol, appels d'outils via Model Context Protocol, réponses de services externes, contenu de pages et d'e-mails. Tout cela se situe en dehors de la protection cryptographique. Si une instruction étrangère est injectée dans le contexte avant l'autorisation, la signature certifiera une intention déjà faussée — tout en restant parfaitement valide.
D'où le nom de l'étude : la menace ne vit pas à l'intérieur du mandat, mais « au-delà du mandat ».
Ce que l'on avait trouvé auparavant et pourquoi la v0.2 a exigé une nouvelle analyse
Les failles d'AP2 avaient déjà été recherchées : dans la version v0.1, des attaques par rejeu et par injection de prompt avaient été décrites. Dans la v0.2, une partie de ces problèmes a été corrigée — mais les correctifs ont apporté avec eux de nouvelles fonctionnalités et de nouvelles hypothèses de déploiement. Chaque nouveauté de ce type est une surface d'attaque potentielle, et une ancienne analyse ne se transpose pas mécaniquement à une nouvelle version.
C'est ce dont s'est chargée l'équipe — Avital Aviv, Parth A. Gandh, Ron Bitton et Asaf Shabtai. Le travail Beyond the Mandate: A Systematic Security Analysis of the Agent Payments Protocol (AP2) a été publié sur arXiv le 24 août 2026 sous le numéro 2608.23858, dans les rubriques cs.CR et cs.AI.
Rôles, phases, architectures et frontières de confiance
L'analyse n'est pas construite comme une chasse aux bugs isolés, mais comme une cartographie de tout le territoire. Les auteurs décrivent les rôles des participants et divisent le cycle de vie d'une transaction en cinq phases successives — de la formulation de la tâche jusqu'aux règlements et aux éventuels litiges qui suivent. En parallèle, cinq architectures de déploiement sont distinguées : elles diffèrent par l'emplacement des agents, le détenteur des clés et la manière dont les intermédiaires de confiance sont intégrés au schéma.
L'étape clé est la délimitation des frontières de confiance. Et c'est là qu'apparaît l'asymétrie principale : le mandat lui-même se trouve à l'intérieur du périmètre protégé, tandis que tout le flux d'informations dont il est issu se trouve à l'extérieur. Tout ce qui se passe entre ces zones constitue l'intrigue principale du travail.
MAESTRO : acteurs, surfaces, objectifs
La partie formelle a été construite sur MAESTRO — une méthodologie de modélisation des menaces pour les environnements multi-agents. Elle permet de décrire quatre acteurs de menace, onze surfaces d'attaque, dix-huit capacités d'adversaire et six objectifs que l'attaquant cherche à atteindre.
Une telle décomposition n'est pas là pour faire de beaux chiffres. Elle montre que l'adversaire n'est pas unique : ce n'est pas seulement un malfaiteur externe, mais aussi un outil compromis, un vendeur malhonnête, un service factice. Et leurs motivations diffèrent — du retrait direct d'argent au décalage discret du choix dans la direction souhaitée.
Un catalogue de 48 menaces
Le résultat est un catalogue de 48 menaces, regroupées en cinq familles d'attaques. Elles ont été évaluées à l'aide d'AIVSS — un système de notation des vulnérabilités adapté aux spécificités de l'IA. Huit menaces atteignent au moins la bande High dans au moins une architecture.
Ce « au moins une » est déjà révélateur en soi. Le niveau de risque dépend non seulement du code, mais aussi du schéma de déploiement : ce qui est mortel pour une variante d'intégration peut être presque inoffensif dans une autre — et inversement. Il n'existe pas de réponse unique à la question de savoir à quel point AP2 est sûr.
Huit scénarios High-risk : banc d'essai et démonstrations
Il n'existait pas de déploiement public du protocole au moment du travail, les auteurs ont donc assemblé eux-mêmes un banc d'essai — et y ont couvert les cinq architectures. C'est sur celui-ci qu'ils ont aussi construit cinq démonstrations proof-of-concept : chacune couvre son propre groupe de menaces, et ensemble elles englobent les huit scénarios High-risk ainsi que les mesures de protection proposées.
C'est un argument important contre le reproche « tout cela n'est que de la théorie chez vous ». Les menaces ne sont pas simplement énumérées — elles sont reproduites.
Un scanner qui tient compte du déploiement
Un autre résultat pratique est un scanner qui prend en compte les spécificités du déploiement. Sa logique repose sur l'idée qu'il faut vérifier non pas le protocole en général, mais une configuration concrète. Le scanner met en correspondance les menaces applicables à un schéma donné avec trois types de contrôles : statiques, contrôles de cohérence inter-rôles et tests adversariaux.
Les contrôles inter-rôles sont ici particulièrement pertinents. Dans un schéma multi-agents, l'erreur se cache souvent non pas à l'intérieur d'un composant isolé, mais à la jonction des attentes : un agent est convaincu qu'un autre a déjà effectué la vérification nécessaire.
Ce qu'il faut en retenir
La conclusion principale est plus dure qu'on ne le souhaiterait : une signature de mandat valide ne suffit pas pour affirmer que la transaction reflète l'intention de l'utilisateur. La signature confirme l'intégrité, pas la pertinence. Si le contexte a été compromis avant l'autorisation, la cryptographie certifiera soigneusement la volonté d'un autre.
Conséquences pratiques pour ceux qui construisent des paiements agentiques :
- Contrôlez le contexte d'entrée, pas seulement la transaction finale. L'essentiel des risques se situe avant le moment de la signature.
- Considérez l'architecture comme partie intégrante du modèle de menaces. Une même version du protocole donne un profil de risque différent selon les schémas de déploiement.
- Restreignez les pouvoirs de l'agent. Plus le mandat est précis, plus les dommages d'une intention faussée sont limités.
- Vérifiez les jonctions entre rôles. C'est là que les contrôles échouent le plus souvent.
En bref
La cryptographie résout exactement le problème qu'on lui a posé, et pas un iota de plus. AP2 protège honnêtement la transaction contre la substitution après signature ; tout ce qui se produit avant reste du ressort du développeur. L'étude, avec ses 48 menaces et ses huit scénarios High-risk, n'est pas un verdict sur le protocole, mais une carte du terrain : elle montre où s'arrête la protection offerte par la signature et où commence le travail que la signature ne fera pas à votre place.
