Comment un marchand vérifie un agent IA, et qui en fixe les règles

Publié le . Chaque affirmation renvoie à une source primaire.

Réponse courte : Un marchand dont les défenses anti-bots fonctionnent a un nouveau problème : ces défenses bloquent les agents d’achat qu’il souhaite accueillir. Le résoudre suppose de répondre à trois questions à la porte, pas une. Cet agent est-il bien celui qu’il prétend être ? Agit-il pour une personne réelle et authentifiée ? Et cette personne a-t-elle autorisé cette dépense précise ? Trois organisations différentes répondent à ces questions, et elles ne se concurrencent pas. Visa TAP traite l’identité de l’agent en bordure de site par signatures cryptographiques. Mastercard Agent Pay l’attaque depuis l’émission et la tokenisation. La FIDO Alliance normalise la preuve d’autorisation. Ce qu’un marchand doit construire dépend de celle des trois questions qui bloque réellement son trafic.

Le problème qui n’existait pas il y a deux ans

La gestion des bots fonctionne. C’est là toute la difficulté. Un marchand qui a passé des années à apprendre à sa bordure de site à rejeter le trafic automatisé découvre que le trafic neuf le plus précieux d’internet est automatisé : des agents d’achat agissant pour de vrais acheteurs avec de vrais moyens de paiement. Vu de la bordure, un agent qui ajoute au panier et un scraper qui relève vos prix sont identiques. Les deux sont sans interface, viennent d’un centre de données, et aucun ne bouge une souris.

On ne résout pas cela par des heuristiques, parce que la distinction n’est pas comportementale. C’est une question d’identifiants. D’où le fait que la réponse soit arrivée sous forme de travail de protocole plutôt que de meilleure empreinte.

Trois questions, trois réponses différentes

La chose la plus utile à comprendre ici, c’est que « vérifier un agent » recouvre trois problèmes distincts, que la plupart des articles fusionnent en un seul.

QuestionCe qu’il fautQui y répond
Cet agent est-il légitime ?Un identifiant vérifiable présenté par l’agent, et un moyen de le contrôler en bordureVisa TAP, Web Bot Auth, CDN et éditeurs anti-bots
Agit-il pour une personne réelle ?Un lien entre l’agent et un utilisateur authentifié, avec consentementReconnaissance du consommateur de TAP, Agentic Tokens de Mastercard, authentification d’agent FIDO
Cette personne a-t-elle autorisé cette dépense ?Une preuve d’intention inviolable, avec limites, utilisable en cas de litigeMandats AP2 et Verifiable Intent de Mastercard, tous deux à la FIDO Alliance

Un marchand dont le problème est la première ligne n’a pas besoin de la troisième, et inversement. C’est ainsi que des budgets d’intégration se dépensent sur la mauvaise couche.

Ce que Visa a livré, et pourquoi cela commence au CDN

Visa a dévoilé le Trusted Agent Protocol le 14 octobre 2025, développé avec Cloudflare. Le choix du partenaire est révélateur : TAP est conçu pour être contrôlé en bordure, avant que la requête n’atteigne votre application. L’agent présente une signature cryptographique construite sur les signatures de messages HTTP (RFC 9421), alignées sur Web Bot Auth. La signature est liée à votre domaine et à l’opération précise, navigation ou paiement, et porte horodatages, identifiant de session et identifiants de clé et d’algorithme, de sorte qu’elle ne peut pas être rejouée ailleurs.

Trois couches d’information l’accompagnent : l’intention de l’agent, la reconnaissance du consommateur (compte ou relation existante, avec consentement) et, en option, des données de paiement comme des Payment Account References pour les cartes enregistrées. La spécification et une implémentation d’exemple complète, incluant un proxy CDN qui vérifie les signatures, sont publiques sur GitHub.

Huit mois plus tard, au Visa Payments Forum du 10 juin 2026, Visa a ajouté les briques qui rendent la vérification opérationnelle plutôt que théorique : Agent Score, qui permet à un marchand de tester si des agents parviennent réellement à accomplir des tâches sur son site, un Agentic Directory jouant le rôle de registre de confiance des agents légitimes, et un Large Transaction Model appliquant l’IA à l’autorisation.

Ce que Mastercard a livré, et pourquoi cela commence au jeton

Mastercard a annoncé Agent Pay plus tôt, le 29 avril 2025, et a pris le même problème par l’autre bout. Plutôt que de prouver l’identité en bordure de site marchand, Agent Pay enregistre et vérifie les agents de confiance avant qu’ils puissent payer, et émet des Mastercard Agentic Tokens bâtis sur la tokenisation que le réseau opère déjà. Des contrôles consommateur définissent ce qu’un agent peut acheter, et la transaction arrive identifiable comme initiée par agent auprès de chaque acteur de la chaîne.

Le 20 janvier 2026, Mastercard a exposé comment les pièces s’assemblent. Le réseau a rejoint Google sur l’Universal Commerce Protocol la semaine du NRF, a indiqué travailler avec Microsoft pour amener Agent Pay dans Copilot Checkout, et a cité des travaux continus avec OpenAI, Cloudflare et PayPal. Le cadrage était explicite : l’écosystème était passé « de l’expérimentation à une véritable infrastructure commerciale ». Le 10 juin 2026, le programme a été étendu avec Agent Pay for Machines pour les paiements entre agents et les microtransactions.

Pourquoi la troisième question est partie chez FIDO

L’identité se règle par des signatures. Prouver qu’un humain a autorisé un achat précis, non, parce que c’est un problème de preuve qui doit survivre à un litige des mois plus tard. C’est pourquoi il a quitté les éditeurs. Le 28 avril 2026, la FIDO Alliance a créé un groupe de travail technique Agentic Authentication, présidé par des membres de CVS Health, Google et OpenAI, et a reçu en contribution l’AP2 de Google et le Verifiable Intent de Mastercard dans un groupe de travail Paiements présidé par Mastercard et Visa.

Ses trois axes de travail annoncés recouvrent exactement le tableau ci-dessus : instructions utilisateur vérifiables, authentification de l’agent, délégation de confiance pour le commerce. Andrew Shikiar, CEO de l’Alliance, a formulé l’exigence ainsi : les gens doivent pouvoir se fier au fait que les actions d’agent sont « sûres, autorisées et reflètent réellement leur intention ». Sur les conséquences de gouvernance de ce transfert, voir AP2 a quitté Google.

Que faire concrètement

  1. Mesurer avant de construire. Vérifiez si des agents légitimes sont rejetés en bordure. Si votre défense anti-bots ne bloque pas de trafic d’agents, la vérification n’est pas votre goulot d’étranglement, et la qualité de vos flux l’est probablement.
  2. Commencer par la bordure, pas par le checkout. TAP est vérifiable au CDN et bâti sur une RFC publiée de l’IETF : la couche d’identité peut être testée sans toucher à votre tunnel de paiement.
  3. Traiter l’autorisation comme un chantier à part, sur une horloge plus lente. Elle se normalise chez FIDO avec les réseaux aux présidences, et sa forme se stabilisera avant que vous ayez à vous engager.
  4. Ne pas parier sur un seul réseau. Visa et Mastercard abordent le sujet par des bouts différents et convergent tous deux vers les protocoles ouverts plutôt que de les remplacer, comme nous l’exposions dans réseaux cartes contre protocoles ouverts.

Pour la couche en dessous, voir comment les agents IA paient. Pour la partie qui décide si un agent vous trouve, voir comment les agents lisent vos produits.

Questions fréquentes

Pourquoi un marchand bloquerait-il un agent qu’il veut ?
Parce qu’une défense anti-bots ne peut pas distinguer un agent d’achat d’un scraper sans identifiant à vérifier. Les deux arrivent comme du trafic HTTP automatisé venu d’un centre de données. La vérification d’agent existe précisément pour donner à la défense quelque chose à contrôler.
Que vérifie réellement TAP ?
Qu’une signature cryptographique, construite sur les signatures de messages HTTP (RFC 9421) et alignée sur Web Bot Auth, est liée au domaine du marchand et à l’opération précise, avec horodatages et identifiant de session contre le rejeu. Elle transporte l’intention de l’agent, la reconnaissance du consommateur et, en option, des données de paiement.
Vérifier un agent et autoriser un paiement, est-ce la même chose ?
Non, et les confondre est l’erreur courante. La vérification répond à qui appelle. L’autorisation répond à la question de savoir si un humain a accepté cette dépense. TAP et Agent Pay traitent la première ; AP2 et Verifiable Intent, désormais à la FIDO Alliance, traitent la seconde.
Faut-il en choisir un seul ?
Pas pour l’identité. TAP est publié sur GitHub et bâti sur une RFC de l’IETF, donc un marchand ou un CDN peut vérifier les signatures sans relation avec Visa, même si les spécifications initiales s’appliquent au réseau Visa. Agent Pay est un programme réseau propriétaire : il vient avec votre relation d’acquisition, pas à sa place.
Quelle est la première étape la moins coûteuse ?
Déterminer si votre problème relève de l’identité ou de l’autorisation, puis instrumenter avant de construire. Si des agents légitimes sont bloqués, cela se voit dans le trafic automatisé que vos défenses rejettent sur des pages qu’un agent lirait plausiblement. Vérifiez-le avant d’adopter un protocole.

Stay current on the standards

A note when a standard moves (ACP, UCP, AP2, MCP, x402). No spam.

Unsubscribe anytime.