Signez les limites, pas l’achat

Si votre agent vous demande votre empreinte chaque fois qu’il s’apprête à agir, vous ne déléguez pas, vous faites du baby-sitting. AP2, l’Agent Payments Protocol, règle ça avec un mandat : vous signez les limites une fois, sur un écran qu’aucun agent ne contrôle, et l’agent agit plus tard à l’intérieur, sans vous. Celui à qui il remet le mandat peut vérifier, par la cryptographie, qu’il est resté dans les clous. Il a été conçu pour les achats, mais comme l’a dit Alan, de Google, sur scène, c’est en réalité de l’autorité déléguée par l’utilisateur, et ça s’applique largement.

Cette phrase vient de la dernière conversation du direct du deuxième jour d’AGNTCon + MCPCon North America, le 23 octobre, un tour de la pile de protocoles d’agents de Google. Le passage dure environ deux minutes, et il met un nom sur un problème que j’ai avec chacun des agents que je fais tourner.

Les paiements étaient le test le plus dur, pas le but

Alan est product manager chez Google. Il a aidé sur A2A et sur l’adoption de MCP en interne, et il siège au comité technique de l’Agentic AI Foundation. Il a aussi travaillé six ans dans les paiements chez Google, et c’est de là que vient AP2.

Son avis sur le nom : il est mal choisi. L’animateur a résumé l’idée ainsi : « moi, humain, je pose mon empreinte sur mon téléphone pour dire, oui l’agent, vas-y, fais-le pour moi ». La réponse d’Alan : « C’est en fait un mandat. On l’utilise pour les achats parce qu’on s’est dit : quel est le problème le plus dur qu’on peut attaquer maintenant ? » Puis : « Mais cette délégation d’autorité a de la valeur dans plein d’autres contextes. »

Les paiements font un bon premier test, parce que l’argent a un juge intégré. Un remboursement ou une rétrofacturation, c’est une dispute pour savoir si vous le vouliez vraiment, donc, selon ses mots, « il faut forcer la délégation pour qu’elle soit prouvable ». Il qualifie AP2 de pièce stratégique, et il admet que ça mettra longtemps à se répandre. Son cousin, UCP, l’Universal Commerce Protocol, est la pièce tactique : les conventions du commerce en ligne (panier, stock, options de livraison) en petits modules sur MCP et A2A, utilisables dès aujourd’hui.

Tout approuver au moment même fait rater le vol

L’installation de l’animateur, je l’aurais construite aussi. Son agent a accès à l’API de 1Password. Quand il veut quelque chose, disons un numéro de passeport, il interroge le coffre et une notification arrive sur le téléphone. Un tap, c’est approuvé.

Le nom qu’Alan lui donne : human present, humain présent. Vous autorisez cette action-là, maintenant. Ça marche, jusqu’à ce que la tâche dure plus longtemps que votre attention.

Puis est venu le billet d’avion. Vous lancez l’agent sur la recherche, il fait tout le travail, vous vous éloignez de l’ordinateur. Il revient : « Je suis prêt à payer ce vol. Vous l’autorisez ? » Vous pensiez l’avoir autorisé il y a vingt minutes. Vous l’avez autorisé cinq fois, et il ne l’a jamais acheté. Alors vous autorisez encore, et maintenant le prix n’est plus disponible, et tout le parcours recommence.

Le verdict sans détour, sur scène : retirez l’agent de l’équation et un script ferait ça. L’agent n’est pas la partie lente. Le modèle d’approbation, si.

Humain présent, humain absent

La solution qu’Alan a décrite, c’est l’autre mode, human not present, humain absent. Son exemple : « Quand ces baskets passent en solde, si elles sont à ta taille, chez un de tes vendeurs de confiance, achète-les. »

Cette phrase contient trois limites (l’article, votre taille, une liste de boutiques) et un déclencheur. Vous l’approuvez une fois, avant que quoi que ce soit n’arrive. L’agent achète ensuite à 3 h du matin sans vous réveiller, et la boutique peut quand même savoir que vous avez accepté exactement ça.

Même empreinte, autre moment. En mode humain présent, vous signez l’achat. En mode humain absent, vous signez les limites, et l’achat, c’est le travail de l’agent.

Un mandat ouvert, puis un mandat fermé

Voici comment AP2 s’y prend vraiment. J’ai lu la spec v0.2, publiée en avril, après le direct. Elle est courte et concrète.

Un mandat est une attestation numérique signée, un SD-JWT, la variante à divulgation sélective du JSON Web Token. Il y en a deux sortes : un mandat de checkout (ce qui est acheté, à qui) et un mandat de paiement (combien, avec quelle carte ou quel compte). Chacun existe en deux étapes.

Le mandat ouvert, c’est ce que vous signez. L’agent rédige les limites, et une Trusted Surface, une surface de confiance, vous les montre, prend votre biométrie et signe avec votre clé. La spec dit que cette surface DOIT être non agentique : le modèle ne tient jamais votre stylo. Le mandat ouvert porte aussi la clé publique de l’agent dans un claim cnf, donc il est lié à cet agent-là. Une copie dans d’autres mains ne sert à rien.

Le mandat fermé, c’est ce que l’agent fabrique plus tard, seul. Il trouve un vrai panier, écrit la transaction exacte, et la signe avec sa propre clé, celle nommée dans votre mandat ouvert. Cette signature relie le mandat fermé au mandat ouvert.

Les limites sont une liste de contraintes typées. La version 0.2 définit celles-ci :

• Côté checkout : checkout.allowed_merchants et checkout.line_items, avec les produits et quantités acceptables.
• Côté paiement : payment.amount_range, payment.allowed_payees, payment.allowed_payment_instruments, payment.execution_date, et la paire pour les tâches répétées, payment.agent_recurrence (par exemple mensuel, 12 fois au plus) avec payment.budget, un plafond sur le total.
• Plus iat et exp sur le mandat ouvert, pour que l’ensemble expire.

Réduit à l’essentiel, le côté paiement des baskets d’Alan ressemblerait à ceci :

{
  "vct": "mandate.payment.open.1",
  "cnf": { "jwk": "the agent's public key" },
  "constraints": [
    { "type": "payment.amount_range", "currency": "USD", "min": 0, "max": 20000 },
    { "type": "payment.allowed_payees", "allowed": ["one of your trusted shops"] }
  ]
}

Ma phrase préférée de la spec, c’est la raison d’être des mandats ouverts : « même des agents qui se comportent bien doivent voir leur comportement contraint bien plus étroitement que ce qu’un modèle d’autorisation normal exigerait d’utilisateurs humains ». Personne ne donne à un humain une carte qui ne marche que dans trois boutiques, sous deux cents dollars, jusqu’à vendredi. Un agent devrait recevoir exactement ça.

Trois vérificateurs, et aucun n’est vous

En mode humain absent, personne ne vous demande rien au moment de payer. Trois autres parties vérifient à votre place.

Le fournisseur d’identifiants de paiement (votre banque ou votre portefeuille) reçoit les deux mandats de paiement, ouvert et fermé, les vérifie, et seulement ensuite émet un jeton de paiement. Le marchand compare le mandat de checkout fermé à son panier actuel et vérifie que vos limites ouvertes sont respectées. Le prestataire de paiement du marchand vérifie que les mandats dans le jeton sont liés à ce checkout précis. Chacun signe un reçu.

Quelques règles là-dedans sont petites et très bonnes :

• Une contrainte inconnue compte comme un échec. Si un vérificateur ne comprend pas une de vos limites, il dit non plutôt que de la sauter.
• Après un reçu réussi, l’agent réduit la portée du mandat ouvert de ce qu’il vient de dépenser. C’est comme ça qu’un budget tient sur des achats répétés.
• L’agent ne doit pas présenter de mandats qui se chevauchent tant qu’un reçu ne revient pas en erreur. Pas de double dépense en faisant la course entre deux boutiques.
• Quand une limite ne peut pas être tranchée, le vérificateur renvoie unresolved_constraint et le parcours repasse en humain présent. On vous demande, une fois, la seule chose qui est vraiment nouvelle.

Cette dernière règle, c’est le billet d’avion réparé. L’agent ne revient pas cinq fois. Il revient quand le prix est sorti de ce que vous avez signé.

Chaque approbation de ma flotte est en humain présent

Puis j’ai regardé ma propre installation, et c’est partout le modèle 1Password de l’animateur.

Mon agent de vente pilote un Chrome sur le Mac mini, connecté à mes comptes de revente sous mon nom. Il rédige chaque réponse aux acheteurs et attend mon OK dans le chat avant d’envoyer. Quand j’ai demandé à un agent de laisser un autre de mes agents envoyer des SMS depuis mon téléphone, le mode auto de Claude Code a refusé d’appliquer seul le changement de config, parce que c’était une attribution de permission. Il n’est passé qu’une fois approuvé par moi, à la main. Et cette note arrivera sur le site de la même façon. L’agent qui l’a rédigée peut ouvrir la pull request, mais le merge, c’est mon clic.

Tout ça va bien pour l’instant. Voilà ce qui me gêne après ce passage. Le navigateur connecté porte toute mon autorité : n’importe quelle annonce, n’importe quel prix, n’importe quel message. Mon OK est un message de chat que personne en aval ne peut vérifier. Les limites vivent dans ma tête et dans un prompt, pas dans quoi que ce soit de signé.

C’est l’autre moitié d’une note que j’ai écrite hier, sur la conférence DotSpace de Chi Wang. Sa règle : un agent porte votre demande, pas votre autorité. AP2, c’est la façon dont une part bornée d’autorité peut quand même voyager : comme un objet signé, avec les limites écrites dedans, vérifié par celui qui le reçoit. C’est aussi la même idée que la passerelle de ma note sur les agents en entreprise, où les clés n’entrent jamais dans la sandbox. Ici, votre clé ne touche jamais l’agent ; elle reste sur la Trusted Surface.

Ce que je n’ai pas fait : je n’ai pas lancé les exemples d’AP2, et la v0.2 ne définit que des mandats de checkout et de paiement. Rien dans la spec ne couvre « réponds aux acheteurs de cette annonce-là, jamais sous ce prix, jusqu’à dimanche ». C’est le mandat que je voudrais vraiment, et personne n’en donne le format pour l’instant.

À essayer

Le passage sur AP2 dure deux minutes, à partir de 5:19:25. Regardez-le, puis lisez la page agent authorization de la spec. C’est l’explication la plus claire que j’aie vue de pourquoi les agents ont besoin de limites plus serrées que les gens.

Pour aller plus loin :

• Le moment AP2 du direct, Live from AGNTCon + MCPCon North America, deuxième jour, le 23 octobre 2026, en anglais
• Agent Payments Protocol, le site, avec les pages agent authorization et flows (en anglais)
• google-agentic-commerce/AP2, la spec et les exemples, Apache 2.0, v0.2.0 depuis avril 2026
• Un agent peut porter votre demande, pas votre autorité, les salles de Chi Wang où des agents de propriétaires différents travaillent ensemble
• Espérer n’est pas sécuriser, où les clés n’entrent jamais dans la sandbox

Si vous avez signé un mandat ouvert pour autre chose qu’un achat, dites-moi à quoi ressemblaient les limites. J’aimerais beaucoup en voir un pour des messages.

Texte brut: sign-the-limits-not-the-purchase.md · Flux Atom · Toutes les notes