Les agents d’IA peuvent déjà planifier des tâches en plusieurs étapes. Ils peuvent utiliser des outils, comparer des options et coordonner des tâches. Dès qu’une tâche nécessite un paiement, de nombreux processus s’interrompent. Les systèmes de paiement existants ont été conçus pour des humains qui se connectent, saisissent les coordonnées de leur carte et approuvent les transactions. Les agents ne peuvent pas effectuer ces étapes de manière fiable. On ne peut pas non plus leur faire confiance en leur donnant un accès illimité aux fonds ou aux identifiants d’un utilisateur. Ce décalage constitue une contrainte majeure pour l’économie des agents.
Kite répond à cette contrainte en considérant l’autorité de paiement comme une infrastructure plutôt que comme une instruction. Cette autorité est accordée pour une tâche définie, encadrée par des règles et appliquée indépendamment du raisonnement de l’agent. Il en résulte un système dans lequel un agent peut effectuer des tâches rémunérées tandis que l’utilisateur conserve un contrôle cryptographique sur les dépenses autorisées, leur destination et leur durée.
Le problème d’une autorité illimitée ou impossible à faire respecter
La plupart des approches actuelles des paiements par agents entraînent l’un de deux problèmes.
Le premier problème est celui des autorisations excessives. Un utilisateur communique une carte de crédit, une clé API ou la clé privée d’un portefeuille. L’agent dispose alors d’un accès permanent qui dépasse largement le cadre d’une tâche donnée. Si l’agent se comporte mal, si le flux de travail change ou si les identifiants sont compromis, l’exposition n’est pas limitée par conception.
Le second problème est celui des interruptions constantes. L’agent doit attendre l’approbation humaine pour chaque paiement. L’autonomie se réduit alors à une succession de demandes d’autorisation.
Les instructions en langage naturel ne résolvent aucun de ces problèmes. Une consigne telle que « ne dépense pas plus de 20 $ » n’est pas applicable de manière contraignante. L’agent peut l’ignorer, la mal interpréter ou agir dans un contexte où cette restriction n’est plus visible. Une autorité qui n’existe que dans le contexte du modèle ne peut être ni vérifiée ni révoquée par le système sous-jacent.
La conception de Kite repose sur le principe inverse. Les limites doivent être représentées et vérifiées au moment de l’action.
L’identité n’est pas l’autorité
Kite utilise un modèle d’identité à trois niveaux. L’utilisateur détient l’autorité racine. Chaque agent reçoit une adresse déterministe dérivée des éléments cryptographiques de l’utilisateur au moyen d’une dérivation hiérarchique déterministe. L’agent ne peut pas reconstituer la clé parente.
Les sessions sont éphémères. Elles reçoivent des identifiants à courte durée de vie qui expirent après un certain temps ou lorsque leur périmètre autorisé est épuisé. Toute compromission à quelque niveau que ce soit reste circonscrite. L’utilisateur ne confie jamais la clé racine à un agent. La session ne reçoit jamais l’ensemble des capacités de l’agent parent.
Cela crée une distinction importante :
Un agent peut avoir une identité persistante sans disposer d’une autorité de dépense permanente.
Lorsqu’un agent doit effectuer des paiements, il demande une session. L’utilisateur examine la demande et l’approuve avec une clé d’accès. Cette approbation définit un périmètre concret : un budget total, une limite par transaction, une période de validité et, souvent, un ensemble de services ou de commerçants autorisés.
Une fois la session active, l’agent peut découvrir des services, demander des paiements et effectuer des transactions sans autre approbation humaine, à condition que chaque action respecte le périmètre approuvé.
Le système peut rejeter les demandes qui dépassent le budget, sortent du périmètre ou arrivent après l’expiration de la session. L’utilisateur peut révoquer la session. Les autorisations accordées et les dépenses sont consignées, ce qui crée une piste vérifiable de l’autorité accordée et de son utilisation.
L’idée essentielle est que l’identité et l’autorité sont distinctes. L’agent peut rester identifiable tandis que ses autorisations économiques demeurent temporaires et propres à la tâche.
De « faire confiance à l’agent » à « limiter ses capacités »
Cette distinction transforme le modèle de sécurité.
Dans un modèle simple fondé sur des identifiants, l’agent reçoit une capacité et l’on s’attend à ce qu’il l’utilise correctement. La sécurité dépend donc largement du comportement de l’agent.
Un modèle fondé sur des sessions à périmètre défini déplace une partie de cette frontière hors du modèle. L’utilisateur définit ce que l’agent est autorisé à faire, et l’infrastructure de paiement vérifie que chaque action respecte ces limites.
Cela ne rend pas l’agent infaillible. Cela permet quelque chose de plus précis.
Cela limite les conséquences économiques d’un agent qui agit à l’encontre des instructions prévues.
C’est pourquoi une règle comme « ne dépense pas plus de 20 $ » est fondamentalement différente lorsqu’elle est représentée par une contrainte de session applicable, plutôt que laissée sous forme de texte dans une consigne.
Règlement et infrastructures de micropaiement
Les paiements sont réglés en stablecoins sur la couche 1 de Kite, conçue spécifiquement à cet effet. La chaîne est compatible avec l’EVM et optimisée pour les transferts fréquents de faible montant.
Les canaux d’état permettent à un agent d’ouvrir une seule fois un canal sur la chaîne, de transmettre de nombreuses mises à jour signées hors chaîne, puis de procéder à un seul règlement. Ce modèle convient aux paiements à la demande ou par inférence, tout en réduisant le besoin d’effectuer une transaction sur la chaîne pour chaque interaction.
Les utilisateurs n’ont pas besoin de révéler leurs coordonnées bancaires ou leur numéro de carte à l’agent. Celui-ci ne dépense que les fonds mis à sa disposition dans le cadre de la session approuvée.
Les mêmes infrastructures prennent en charge plusieurs normes émergentes. Kite est conçu pour servir de couche d’exécution compatible avec des protocoles tels que x402 et AP2 de Google, plutôt que d’obliger les développeurs à choisir une interface propriétaire unique.
Un service qui émet déjà une demande de paiement HTTP 402 peut être payé par un agent opérant dans le cadre d’une session Passport. La demande de paiement et l’autorité régissant la transaction peuvent donc s’intégrer au même flux de travail de l’agent.
Ce que le système applique réellement
En pratique, plusieurs catégories de risques sont ainsi limitées de manière mécanique.
Un agent ne peut pas continuer à dépenser après l’expiration de sa session. Il ne peut pas dépasser le budget par transaction ou le budget total défini pour la session. Il ne peut pas étendre ses propres autorisations en toute discrétion. Si un flux de travail nécessite davantage d’autorité, une nouvelle session peut être demandée et approuvée.
Ces propriétés ne dépendent pas uniquement de la bonne interprétation d’une consigne par l’agent. Elles sont vérifiées par le système de paiement et d’identité avant tout transfert de valeur.
Pour les développeurs, cela change la façon dont les capacités des agents peuvent être combinées.
Un agent peut recevoir une compétence qui lui permet de découvrir des services de catalogue et de les payer, ou d’initier des transferts directs de stablecoins. Cette compétence ne fonctionne que dans le cadre de la session déjà approuvée par l’utilisateur.
Les développeurs n’ont donc pas besoin de considérer chaque agent comme un acteur économique entièrement digne de confiance. Ils peuvent plutôt intégrer des capacités dans un périmètre d’autorité défini.
Un exemple simple
Prenons une tâche de recherche nécessitant des données payantes.
L’utilisateur approuve une session avec un budget total de 10 $ et une limite de 2 $ par demande. La session est valable deux heures et limitée à un fournisseur de données précis.
L’agent achète l’accès, récupère les données nécessaires, puis s’arrête lorsque le budget est épuisé ou que la période de validité prend fin. L’utilisateur peut consulter les paiements et révoquer la session si les résultats ne sont plus utiles.
Il n’est pas nécessaire de communiquer à l’agent une clé API ou un numéro de carte.
Le même principe peut s’appliquer à la réservation d’un service, à la location de ressources informatiques temporaires ou au déclenchement d’une action conditionnelle sur la chaîne. Dans chaque cas, l’étape déterminante a lieu avant l’exécution : l’utilisateur définit l’autorité économique dont disposera l’agent.
Ce que cela ne résout pas
Une autorité de paiement limitée ne supprime pas le besoin de jugement humain.
Les utilisateurs doivent toujours décider du budget et du périmètre adaptés à une tâche. Même un paiement correctement encadré peut donner lieu à l’achat d’un service médiocre. Un agent peut toujours prendre une mauvaise décision dans les limites de l’autorité qui lui a été accordée.
L’intérêt de ce modèle est plus restreint et plus concret.
Il réduit le besoin pour l’utilisateur d’approuver chaque paiement individuellement, tout en diminuant la nécessité de faire confiance à l’agent en lui accordant une autorité sans restriction.
Cette distinction est importante, car les paiements autonomes nécessitent davantage qu’un moyen de transférer de l’argent. Ils nécessitent un moyen de déléguer une autorité économique sans transformer cette délégation en accès permanent.
Questions ouvertes
L’infrastructure rend pratique la limitation des dépenses des agents, mais plusieurs questions de conception et de fonctionnement restent en suspens pour les utilisateurs et les développeurs.
Comment choisir les paramètres des sessions selon les différentes catégories de tâches afin que les agents puissent les accomplir sans devoir obtenir fréquemment une nouvelle approbation ?
Quels éléments de visibilité ou quels systèmes d’alerte supplémentaires permettraient de surveiller les sessions actives en temps réel sans que cela devienne une contrainte ?
Lorsque plusieurs agents ou services interagissent dans le cadre de sessions distinctes, quelles règles devraient régir la combinaison de leurs autorités ?
Comment les utilisateurs devraient-ils évaluer la fiabilité des services auxquels ils paient, lorsque le paiement lui-même est correctement encadré ?
Ces questions viennent après le mécanisme de base.
Le mécanisme lui-même est simple : l’autorité est demandée, limitée, appliquée au moyen du processus de paiement, puis révocable.
L’importance plus générale de Kite Agent Passport ne tient pas simplement au fait que les agents peuvent payer. Elle tient à ce que l’identité peut rester permanente tandis que l’autorité économique devient temporaire, limitée à un périmètre précis et applicable.
Cette séparation offre aux développeurs une façon plus structurée d’aborder les paiements autonomes : plutôt que de donner à un agent un accès illimité à l’argent ou de l’interrompre pour chaque transaction, ils lui accordent un périmètre de capacités défini dans lequel il peut agir.