En bref. AP2 représente l’autorisation de l’acheteur par des mandats signés que les vérificateurs contrôlent au regard de la commande et des éventuelles contraintes approuvées par l’utilisateur.

Définition : Au 17 octobre 2026, le protocole Agent Payments Protocol (AP2) représente l’autorisation d’un acheteur au moyen de mandats signés cryptographiquement : des enregistrements d’une commande ou d’un paiement approuvés. L’acheteur peut approuver directement une transaction précise ou approuver des contraintes qu’un agent doit respecter lorsqu’il effectue un achat de manière autonome.

Points clés

La spécification AP2 définit des mandats de commande (Checkout Mandates) et des mandats de paiement (Payment Mandates), reliés par une empreinte cryptographique de la commande signée par le marchand.
Le modèle d’autorisation des agents (Agent Authorization) propose deux approches de confiance : le justificatif utilisateur (User Credential) et le fournisseur d’agent de confiance (Trusted Agent Provider).
Le schéma Payment Mandate comprend le bénéficiaire, le montant du paiement, l’instrument de paiement et un identifiant de transaction dérivé de la commande signée.

Qu’approuve l’acheteur ?

La spécification AP2 distingue le fonctionnement direct du fonctionnement autonome. En mode direct, avec présence humaine, l’acheteur voit la commande finale et approuve explicitement la commande et son paiement. Les mandats fermés qui en résultent s’appliquent à cette transaction précise.

En mode autonome, sans présence humaine, l’acheteur approuve d’abord des mandats de commande et de paiement ouverts. Un mandat ouvert contient des contraintes sur la transaction finale et indique la clé publique de l’agent dans le champ cnf. L’agent signe ensuite des mandats fermés avec sa propre clé et les présente avec les mandats ouverts approuvés par l’acheteur.

L’interface de confiance (Trusted Surface) est l’interface chargée de recueillir le consentement éclairé avant de créer un mandat signé par l’utilisateur. La spécification impose à ce rôle d’utiliser du code déterministe, sans déléguer de traitement à un modèle de langage. Les vérificateurs reçoivent des mandats fermés dans les deux modes ; le fonctionnement autonome y ajoute la preuve de la délégation d’autorité.

À qui fait-on confiance pour recueillir le consentement ?

La spécification AP2 considère un agent comme un attaquant potentiel dès lors qu’un rôle en utilise un. Les mandats signés et la vérification déterministe servent de base au contrôle de son autorité.

Le modèle Agent Authorization définit le vérificateur comme la partie qui contrôle si un agent est habilité à agir. Son approche User Credential repose sur un émetteur externe de justificatifs auquel ce vérificateur fait confiance. Le vérificateur se fie à l’émetteur pour veiller à ce que l’interface de confiance ne crée des mandats qu’après avoir obtenu le consentement et l’autorisation appropriés de l’utilisateur. Un justificatif peut ainsi déléguer une autorité à différents agents sans relation de confiance distincte avec chacun d’eux.

Dans l’approche Trusted Agent Provider, le vérificateur fait directement confiance au fournisseur de l’agent pour recueillir le consentement et construire les mandats. Cette approche ne nécessite aucun justificatif utilisateur émis au préalable. Le fournisseur doit rendre sa clé de signature inaccessible à l’agent et empêcher son utilisation sans l’interface de confiance.

Le même modèle impose de vérifier la chaîne de mandats, de préserver les valeurs approuvées dans les mandats ouverts et d’évaluer chaque contrainte. Une contrainte inconnue entraîne l’échec de l’évaluation.

Que doit vérifier un marchand ou un prestataire de paiement ?

Selon les règles de vérification AP2, le marchand vérifie le mandat de commande et contrôle que checkout_hash correspond à sa commande signée. Lorsque des mandats ouverts sont joints, il évalue également leurs contraintes. Le fournisseur de données de paiement (credential provider) vérifie le mandat de paiement avant de transmettre une donnée de paiement (payment credential), et le prestataire de traitement des paiements du marchand contrôle que cette donnée est limitée à la commande concernée. Ces contrôles doivent s’exécuter dans du code déterministe, y compris lorsque le rôle qui les assure utilise un agent.

Les exemples de Payment Mandate comprennent cette contrainte dans un mandat ouvert décodé :

{
  "type": "payment.amount_range",
  "currency": "USD",
  "max": 20000,
  "min": 0
}

Ce fragment définit une plage de montants ; il fait partie du contenu du mandat, qui nécessite également une protection cryptographique. Le schéma exprime ces limites en unités monétaires mineures. L’évaluation contrôle que le montant du paiement se situe dans cette plage et exige que les devises correspondent. D’autres contraintes définies restreignent les bénéficiaires ou les instruments de paiement autorisés.

La spécification impose aussi des reçus de commande et de paiement après acceptation ou rejet. Les mandats et les reçus peuvent être réunis pour servir de preuves de la transaction en cas de litige ; les procédures de règlement des litiges et les exigences de conservation restent hors de son périmètre.

Termes associés

Questions fréquentes

Un agent peut-il approuver un achat en mon absence ?

Oui. En mode autonome, votre approbation préalable porte sur des mandats ouverts. L’agent signe les mandats finaux, et les vérificateurs les contrôlent au regard de cette délégation d’autorité et de ses contraintes.

Que se passe-t-il si un vérificateur ne peut pas évaluer une contrainte ?

Les définitions d’erreurs d’Agent Authorization prévoient unresolved_constraint pour une contrainte inconnue ou invérifiable. Cette erreur peut signaler un retour à l’approbation directe de mandats fermés ou à un autre parcours sans agent.

Sources

Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO

Comment AP2 représente-t-il l’autorisation de paiement d’un acheteur ?