Pendant longtemps, la conversation a été le principal moyen d’interagir avec l’IA. Nous posions des questions, recevions des réponses, générions du contenu et utilisions les résultats pour prendre nous-mêmes des décisions.
Cette relation commence à évoluer avec le développement des agents IA.
Les agents IA sont conçus pour faire plus que répondre. Selon leurs capacités et les outils dont ils disposent, ils peuvent planifier des tâches, interagir avec des services externes, utiliser des logiciels et agir avec une intervention humaine limitée.
Ce changement est important, car un système d’IA capable d’agir dans le monde soulève des questions différentes de celles d’un système qui se contente de générer du texte.
Si un assistant d’IA fait une mauvaise recommandation, on peut l’ignorer. Mais si un agent d’IA effectue un achat, paie un service ou réalise une transaction pour le compte d’une personne, les conséquences ne se limitent plus à une conversation.
L’économie des agents repose sur cette évolution. Les agents pourraient de plus en plus devenir à la fois consommateurs et fournisseurs de services numériques, en interagissant avec d’autres agents, des applications et des systèmes de paiement.
Mais l’intelligence à elle seule ne suffit pas.
Un agent doit pouvoir agir. Les autres parties doivent pouvoir déterminer ce qu’il est, ce qu’il est autorisé à faire et si ses actions sont dignes de confiance.
Et c’est là que commence le véritable défi.
Le problème n’est pas seulement la confiance. C’est l’autonomie contrôlée.
L’IA autonome est au cœur d’une tension importante.
Accordez trop peu d’autorité à un agent et il ne sera guère plus qu’un assistant qui demande sans cesse la permission. Il peut être capable de planifier une tâche entière, tout en dépendant d’un humain pour approuver chaque petite étape.
Accordez-lui trop d’autorité et il devient plus difficile de contenir les conséquences d’une erreur. Un agent compromis, une instruction mal conçue ou une décision inattendue pourrait entraîner des actions que l’utilisateur n’a jamais voulu autoriser.
Aucun de ces deux extrêmes n’est particulièrement utile.
L’objectif ne devrait pas être de rendre les agents complètement indépendants, ni de les maintenir dans une dépendance permanente à l’approbation humaine. Il devrait être de leur donner suffisamment de liberté pour accomplir une tâche, tout en maintenant cette liberté dans des limites clairement définies.
Dans l’économie numérique traditionnelle, une personne effectue généralement un paiement ou approuve une transaction. Dans une économie pilotée par des agents, elle peut définir l’objectif tandis que l’agent décide des actions nécessaires pour l’atteindre.
Cela crée une nouvelle exigence : l’autorité déléguée doit être limitée, compréhensible et révocable.
Un agent ne devrait pas avoir besoin d’un accès illimité simplement parce qu’il doit accomplir une seule tâche. Ses permissions devraient refléter ce que l’utilisateur souhaite lui déléguer, le coût potentiel de la tâche et la durée pendant laquelle l’agent doit agir de manière autonome.
C’est le problème qui justifie de s’intéresser aux infrastructures d’identité, d’autorisation et de paiement des agents.
La place de Kite AI
Kite AI développe une infrastructure destinée à soutenir une économie dans laquelle les agents d’IA peuvent interagir avec des services et effectuer des transactions.
Au lieu de considérer les agents uniquement comme des outils logiciels utilisés par des personnes, l’approche de Kite s’intéresse à l’infrastructure nécessaire pour leur permettre de participer aux transactions numériques. Cela comprend l’identité des agents, les permissions déléguées et les mécanismes de paiement.
Cette distinction est importante.
Un agent intelligent peut savoir comment accomplir une tâche, mais savoir quoi faire ne lui donne pas automatiquement un moyen sûr et fiable de le faire. Il doit toujours s’identifier, obtenir une autorisation appropriée, interagir avec des services et effectuer des paiements si nécessaire.
Ce sont des problèmes distincts, et en résoudre un ne résout pas automatiquement les autres.
Kite Passport est particulièrement pertinent, car sa conception documentée permet à un agent de payer des services compatibles pour le compte d’un utilisateur, dans la limite des dépenses approuvées par celui-ci. Le processus documenté relie la configuration du compte, l’approvisionnement du portefeuille, les permissions de dépense limitées à une session et les paiements aux services.
C’est là que la vision plus large de Kite devient concrète. Au lieu d’accorder à un agent un accès financier sans restriction, l’utilisateur peut autoriser une période d’activité définie avec un budget déterminé.
L’idée intéressante n’est pas simplement que les agents puissent effectuer des paiements. C’est que leur capacité à effectuer des transactions puisse être liée à l’autorité que l’utilisateur leur a explicitement accordée.
Pour comprendre pourquoi c’est important, il convient d’examiner le fonctionnement prévu par le processus documenté de Kite Passport.
Identités hiérarchiques : relier les agents à leurs propriétaires
Un aspect important de l’infrastructure des agents consiste non seulement à identifier un agent, mais aussi à établir son lien avec l’entité qui l’autorise.
La documentation de Kite décrit un modèle d’identité à trois niveaux : une identité utilisateur ou racine, une identité d’agent dotée d’une autorité déléguée et une identité de session pour une période d’activité donnée. Une identité d’agent autonome indique quel agent interagit avec un service. La hiérarchie apporte un contexte supplémentaire en reliant cet agent à l’utilisateur qui l’a autorisé et à la session plus limitée dans le cadre de laquelle il agit.
Cela peut être utile lorsqu’une personne ou une organisation gère plusieurs agents, chacun chargé de tâches différentes. Au lieu de traiter chaque agent comme une identité entièrement distincte, dotée de permissions sans lien avec les autres, une hiérarchie peut représenter le lien entre le propriétaire et les agents agissant sous son autorité. La documentation de Kite décrit également des adresses d’agent dérivées du portefeuille de l’utilisateur ainsi que des clés de session conçues pour être de courte durée. Il s’agit de détails de conception de l’architecture documentée, et non d’une garantie que toute compromission ou erreur de mise en œuvre serait sans conséquence.
Cela revient à distinguer qui agit et au nom de quelle autorité cette personne ou cet agent agit. Ces deux questions comptent lorsque des logiciels commencent à prendre des décisions et à effectuer des transactions de manière autonome.
Par exemple, une entreprise pourrait gérer des agents distincts pour la recherche, l’accès aux données et les achats. Chaque agent peut avoir besoin de permissions différentes, mais son autorité provient en définitive de l’organisation qui l’a déployé. Une structure d’identité hiérarchique peut contribuer à rendre ces relations explicites, plutôt que de les laisser implicites dans la logique de l’application.
Cette structure a également d’importantes implications en matière de sécurité. Si un agent ou une session est compromis, un système bien conçu devrait limiter les dommages potentiels aux permissions et aux ressources accessibles à cet agent ou à cette session. La compromission d’un agent ne devrait pas automatiquement donner un accès sans restriction à l’autorité sous-jacente de l’utilisateur, ni à tous les autres agents de l’écosystème.
À mesure que les agents commencent à déléguer des tâches à d’autres agents, il devient encore plus important de maintenir des relations d’identité claires et des limites précises à l’autorité déléguée. Sans cela, une compromission à un niveau donné pourrait avoir des conséquences dépassant la tâche initiale. L’objectif est de rendre l’autorité traçable et compartimentée, afin que chaque agent ne reçoive que l’accès dont il a besoin au lieu d’hériter d’un contrôle sans restriction depuis l’identité qui le chapeaute.
Il s’agit d’un objectif de sécurité, et non d’une garantie contre toutes les défaillances possibles. Son efficacité dépend de la mise en œuvre, de la sécurité des clés sous-jacentes et de l’application correcte des contrôles concernés.
En définitive, l’identité hiérarchique ne sert pas uniquement à organiser plusieurs agents. Elle vise à préserver un lien clair entre l’agent qui effectue une action, l’autorité sous laquelle il agit et les limites de cette autorité. À mesure que les systèmes autonomes deviennent plus interconnectés, cette séparation pourrait constituer un fondement important pour rendre les interactions pilotées par des agents plus sûres et plus faciles à gérer.
Kite Passport : de la configuration aux paiements autonomes
Kite Passport est conçu pour permettre à un agent d’IA de payer des services compatibles pour le compte d’un utilisateur sans que celui-ci ait à approuver manuellement chaque transaction. L’utilisateur configure d’abord Passport, approvisionne son portefeuille et approuve une session de dépense. L’agent peut alors découvrir des services, effectuer des paiements et recevoir les résultats dans les limites de la session.
Ce processus est important, car il distingue trois choses souvent confondues : donner à un agent accès à un système de paiement, lui fournir des fonds et l’autoriser à dépenser ces fonds.
Ces permissions ne sont pas équivalentes.
1. Installer Passport et connecter un agent
Le processus documenté commence par l’interface en ligne de commande de Kite Passport, ou CLI, et par les compétences d’agent qui permettent à un agent d’IA compatible d’interagir avec Passport.
La documentation de Kite couvre à la fois les agents de programmation qui s’exécutent sur l’ordinateur de l’utilisateur et les agents infonuagiques qui fonctionnent sur des ordinateurs hébergés. La méthode d’installation diffère, mais la procédure de connexion au compte suit le même principe général.
Pour les configurations compatibles d’agents de programmation, comme Claude Desktop ou Codex, le processus documenté consiste à exécuter la commande d’installation de Passport depuis l’environnement de développement de l’agent, puis à suivre les instructions de configuration pour s’inscrire à Passport et paramétrer les compétences correspondantes.
Pour les configurations compatibles d’agents infonuagiques, l’utilisateur suit les instructions de configuration correspondantes afin de connecter l’agent hébergé à Passport.
Après l’installation et l’inscription, l’utilisateur reçoit deux courriels : un lien de vérification qui ouvre le tableau de bord Passport et un code de huit caractères qu’il doit transmettre à l’agent. L’utilisateur ouvre le lien de vérification, crée une clé d’accès à l’aide d’une méthode compatible telle que Touch ID, Face ID, Windows Hello ou une clé de sécurité matérielle, puis communique le code pour terminer la connexion.
La clé d’accès est un élément important de ce processus, car l’approbation d’une session de dépense ne devrait pas être une décision sans restriction prise discrètement par l’agent. L’utilisateur doit explicitement donner son approbation avant que l’agent ne reçoive l’autorité de dépense demandée.
L’utilisation d’un agent hébergé soulève également une question pratique importante : le connecter à Passport lui donne accès au compte Passport de l’utilisateur. La documentation de Kite recommande expressément aux utilisateurs de vérifier les limites de session avant de les approuver. La commodité ne devrait pas signifier faire aveuglément confiance aux permissions demandées par un agent.
Une fois le compte et l’agent connectés, il faut ensuite approvisionner le portefeuille.
2. Approvisionner le portefeuille Passport
Passport doit être approvisionné avant qu’un agent puisse effectuer des requêtes payantes. D’après la documentation de Kite, son processus de paiement des services utilise l’USDC.e sur Kite Chain.
Le tableau de bord propose plusieurs moyens d’ajouter des fonds, selon la situation de départ de l’utilisateur.
Achat par carte : les utilisateurs qui ne possèdent pas encore de cryptomonnaies peuvent acheter de l’USDC sur Base depuis la section Ajouter des fonds du tableau de bord Passport. Ils choisissent un montant et un mode de paiement, effectuent l’achat et attendent la mise à jour du solde une fois le règlement effectué.
Dépôt de stablecoins : les utilisateurs qui possèdent déjà des stablecoins compatibles peuvent utiliser l’onglet Crypto pour obtenir l’adresse de dépôt correspondante. La documentation répertorie plusieurs options de dépôt prises en charge sur différents réseaux et avec différents actifs, notamment l’USDC sur Base, Polygon, Avalanche, Tempo, Solana, Arc et d’autres options indiquées. Les utilisateurs doivent envoyer le bon stablecoin à l’adresse correspondant à son réseau. L’envoi d’un actif incorrect ou l’utilisation du mauvais réseau peut empêcher les fonds d’apparaître comme prévu.
Utiliser Kite Bridge : les utilisateurs peuvent également transférer de l’USDC vers Kite Chain avec Kite Bridge. Ils connectent le portefeuille qui détient leurs fonds, sélectionnent le réseau et le jeton source, choisissent Kite comme destination et indiquent l’adresse de leur portefeuille Passport comme destinataire. Après avoir confirmé les transactions et attendu la fin du transfert, le solde Passport devrait être mis à jour.
Transfert depuis un portefeuille déjà sur Kite : si l’utilisateur détient déjà de l’USDC.e sur Kite Chain, il peut l’envoyer directement depuis un portefeuille externe à l’adresse de son portefeuille Passport. La documentation de Kite indique que le portefeuille externe doit disposer de $KITE jetons pour payer les frais de gaz de ce transfert.
L’utilisateur peut consulter le solde obtenu dans le tableau de bord ou avec la commande kpass wallet balance. Il peut aussi demander à l’agent de vérifier le solde.
Ces méthodes d’approvisionnement offrent plusieurs options pour préparer le portefeuille, mais l’approvisionner ne signifie pas automatiquement que l’agent a la permission de dépenser le solde sans restriction.
Cette distinction est au cœur du modèle Passport. Le portefeuille contient les fonds ; la session de dépense définit l’autorité accordée à l’agent pour les utiliser.
3. Créer une session de dépense
C’est sans doute l’étape la plus importante de tout le processus.
Une fois le portefeuille approvisionné, l’agent peut demander une session de dépense. Au lieu de demander simplement un accès général au portefeuille, la session précise la tâche et les limites dans lesquelles l’agent est autorisé à dépenser.
Les paramètres de session documentés par Kite comprennent :
Résumé de la tâche : description de ce que l’agent cherche à accomplir.
Montant maximal par transaction : limite supérieure pour un paiement individuel.
Montant total maximal : budget global disponible pendant la session.
Durée de validité (TTL) : durée pendant laquelle la session reste valide.
Actifs approuvés : actifs que la session peut utiliser.
Par exemple, imaginons un agent qui doit effectuer une seule requête payante auprès d’une API météo. L’utilisateur pourrait autoriser une session limitée à 2 $ par transaction, à un budget total de 10 $ et à une durée de validité de 24 heures.
L’agent demande la session et reçoit une URL d’approbation. L’utilisateur ouvre cette URL sur un appareil où sa clé d’accès est disponible et approuve explicitement la demande.
La session ne devient active qu’après cette approbation.
La distinction entre la limite par transaction et le budget total est particulièrement utile. Un montant maximal par transaction limite la taille de chaque paiement, tandis que le budget total plafonne les dépenses cumulées pendant la session. La date d’expiration ajoute une limite temporelle et empêche la session de rester valide indéfiniment.
Une fois la session approuvée, l’agent peut effectuer les paiements admissibles dans les limites prévues sans demander une nouvelle approbation pour chaque paiement. La session expire lorsque sa durée de validité est écoulée ou que son budget est épuisé.
C’est le compromis central que Passport cherche à gérer : l’utilisateur conserve le contrôle de la portée de l’autorisation, tandis que l’agent dispose d’une autonomie suffisante pour accomplir la tâche.
Sans cette séparation, l’autonomie pourrait signifier accorder à un agent un large accès financier. Avec des permissions liées à une session, l’intention est de n’accorder que l’autorité nécessaire pour une période de travail donnée.
Bien entendu, l’utilité d’un système de permissions dépend de la qualité de sa mise en œuvre. L’utilisateur doit comprendre ce qu’il approuve, et le système doit appliquer correctement les limites. Une session ne garantit pas que l’agent choisira le bon service ou prendra la bonne décision. Elle permet de limiter les actions qu’il est autorisé à entreprendre.
4. Découvrir des services et effectuer des paiements
Une fois le portefeuille approvisionné et la session de dépense approuvée, l’agent peut rechercher un service payant adapté dans le catalogue de Kite.
La CLI documentée permet de découvrir des services à l’aide de la commande ksearch. L’utilisateur peut également demander à un agent compatible de rechercher des services disponibles correspondant à une tâche, par exemple une API météo.
Une fois qu’il a trouvé un service adapté, l’agent peut envoyer une requête payante au moyen du processus de paiement pris en charge.
L’un des mécanismes documentés par Kite est x402, un protocole de paiement fondé sur la réponse HTTP 402 Payment Required. L’idée générale est qu’un service peut signaler qu’une requête nécessite un paiement et fournir les conditions nécessaires pour poursuivre.
L’interaction peut être comprise comme une séquence :
L’agent demande une ressource à un service.
Si un paiement est requis, le service renvoie une demande de paiement qui en décrit les conditions.
L’agent Passport obtient une autorisation de paiement dans le cadre de la session de dépense approuvée par l’utilisateur.
L’agent renvoie la requête avec les informations de paiement requises.
Le service vérifie et règle le paiement au moyen de l’infrastructure de paiement qu’il prend en charge.
Une fois le paiement confirmé, le service renvoie la ressource ou la réponse demandée.
L’agent peut ensuite utiliser cette réponse dans le cadre de la tâche plus vaste qu’il accomplit.
C’est important, car le paiement peut faire partie intégrante de l’interaction logicielle. L’agent n’a pas nécessairement besoin de s’arrêter, de rediriger l’utilisateur vers une page de paiement classique et d’attendre qu’il effectue manuellement chaque petit achat.
Le service définit ses exigences de paiement, Passport applique l’autorité de dépense approuvée par l’utilisateur et le service fournit la ressource une fois le paiement effectué.
La documentation de Kite destinée aux fournisseurs de services décrit également la prise en charge du Machine Payments Protocol, ou MPP, comme autre moyen pour les services d’accepter les paiements des agents Passport. Les détails varient selon le protocole, mais l’objectif général est similaire : permettre aux services de spécifier des exigences de paiement que les agents logiciels peuvent gérer.
Passport documente également la prise en charge des transferts directs d’USDC initiés par un agent dans les limites de la session approuvée. Ce mécanisme diffère du paiement d’un service au moyen d’une requête utilisant un protocole, même si tous deux dépendent des permissions accordées à l’agent.
Il est important de préciser ce que cela signifie et ce que cela ne signifie pas. Tous les sites web et toutes les API ne deviennent pas automatiquement accessibles aux agents Passport. Un service doit prendre en charge un processus de paiement compatible, et l’agent doit pouvoir interagir correctement avec lui. Le système offre un moyen de relier autorisation et paiement ; il ne supprime pas la nécessité d’intégrer les services.
5. Surveiller l’activité et garder le contrôle
L’autonomie ne devrait pas impliquer de perdre toute visibilité.
Une fois qu’un agent commence à dépenser, les utilisateurs peuvent consulter les paiements effectués et l’activité des sessions dans le tableau de bord Passport. La CLI propose également des commandes pour répertorier les sessions actives et afficher l’activité récente.
C’est important, car l’autorité déléguée doit rester compréhensible après avoir été accordée. Les utilisateurs doivent pouvoir examiner les actions de leurs agents, le montant dépensé et vérifier si une session est toujours active.
Le budget et la date d’expiration d’une session définissent des limites à l’avance. Les journaux d’activité assurent la visibilité après coup. Les deux sont importants, mais remplissent des fonctions différentes.
Les limites de dépense restreignent les actions autorisées de l’agent. L’historique d’activité aide l’utilisateur à comprendre ce qu’il a réellement fait.
Ni l’un ni l’autre ne garantit que chaque transaction était judicieuse ou que chaque service était légitime. La surveillance ne remplace pas la sécurité, et le journal d’une transaction ne prouve pas à lui seul que le logiciel sous-jacent s’est comporté correctement.
Cela dit, cette combinaison est plus utile que de simplement donner un portefeuille à un agent et d’espérer qu’il se comporte comme prévu.
Le principe général est que l’autonomie déléguée nécessite à la fois des limites et de la visibilité. Les utilisateurs ne devraient pas avoir à choisir entre approuver chaque petite action et renoncer à tout contrôle réel du processus.
6. Révocation : un contrôle à vérifier
La délégation d’autorité n’est que la moitié de l’équation. Un modèle de permissions robuste devrait également expliquer comment un utilisateur peut retirer cette autorité si les circonstances changent. La tâche peut être terminée, l’agent peut ne plus être nécessaire ou son comportement peut inciter l’utilisateur à l’arrêter.
Dans le cadre de l’autorisation des agents, la révocation consiste à invalider l’autorité précédemment accordée plutôt qu’à attendre son expiration naturelle. Les sessions limitées dans le temps offrent une échéance automatique, mais celle-ci peut être trop éloignée si l’utilisateur veut interrompre une tâche plus tôt.
Un plafond budgétaire et un mécanisme de révocation résolvent des problèmes différents. Le budget limite les dépenses potentielles ; la révocation détermine si l’agent devrait toujours être autorisé à agir. Ces deux questions sont importantes lorsqu’on évalue l’autonomie déléguée.
En définitive, un contrôle réel exige davantage que la définition de limites au départ. Les utilisateurs doivent savoir clairement quels contrôles existent et lesquels restent à vérifier.
L’autonomie inspire davantage confiance lorsque la portée de l’autorité déléguée est claire, limitée dans le temps et, lorsque cela est possible, révocable.
Ce que ce processus change concrètement
Pris dans son ensemble, le processus Passport établit un chemin défini entre l’autorisation de l’utilisateur et le paiement effectué par un agent.
L’utilisateur connecte un agent, approvisionne un portefeuille, approuve une session avec des paramètres de dépense explicites et laisse l’agent interagir avec les services payants compatibles. Il peut ensuite examiner l’activité qui en résulte.
Cette approche de l’autonomie des agents est plus concrète que le simple fait de donner à un système d’IA accès à un moyen de paiement.
Elle montre également où subsistent les questions difficiles. Les utilisateurs comprennent-ils facilement les permissions qu’ils approuvent ? Ces limites sont-elles appliquées de manière fiable ? Que se passe-t-il lorsqu’un agent fait un mauvais choix dans le cadre du budget autorisé ? Les environnements des agents, les portefeuilles et les services qui reçoivent les paiements sont-ils suffisamment sécurisés ?
Passport répond à une partie du problème de l’autorisation et du paiement, mais ne peut éliminer tous les risques associés aux logiciels autonomes.
Ce n’est pas une raison pour écarter cette approche. C’est une raison de l’évaluer en fonction de ce qu’elle offre réellement.
L’autre volet : les services doivent accepter les paiements des agents
Il est facile de négliger un autre aspect de ce système.
Un agent peut disposer d’un portefeuille, d’une identité et de permissions de dépense approuvées, mais il lui faut tout de même un endroit où dépenser ses fonds. Pour que l’économie des agents fonctionne, les fournisseurs de services doivent pouvoir accepter les paiements des agents comme ceux des personnes.
C’est pourquoi la documentation de Kite destinée aux fournisseurs de services est pertinente pour comprendre la situation dans son ensemble.
Kite décrit deux voies d’intégration des paiements pour les fournisseurs : x402 et MPP. Avec x402, un fournisseur peut renvoyer une réponse HTTP 402 Payment Required contenant les conditions de paiement. L’agent Passport obtient alors l’autorisation appropriée dans le cadre de la session approuvée par l’utilisateur et renvoie la requête avec les informations de paiement. Le fournisseur vérifie et règle le paiement par l’intermédiaire d’un facilitateur compatible avant de fournir le service.
MPP suit un schéma général similaire — demande d’une ressource, présentation des conditions de paiement, réception des justificatifs de paiement, vérification du paiement et fourniture de la ressource —, mais prend en charge un ensemble différent de mécanismes de paiement et de modes d’interaction.
L’idée essentielle est que ce système ne vise pas seulement à aider les agents à dépenser de l’argent. Il s’agit aussi de rendre les services accessibles aux agents au moyen de processus de paiement conçus pour les logiciels.
Imaginons un développeur qui propose l’accès à une API spécialisée. Si un agent peut découvrir le service, comprendre ses exigences de paiement, obtenir une autorisation dans les limites du budget de son utilisateur et recevoir la réponse de l’API après le paiement, le développeur dispose d’un moyen potentiel de servir des clients automatisés sans devoir créer une expérience de paiement manuel entièrement distincte.
Cela ne garantit ni la demande ni une intégration sans effort. Les fournisseurs doivent toujours mettre en œuvre le protocole concerné, configurer leur infrastructure de paiement et veiller à ce que leur service traite les requêtes de manière sécurisée. Les agents ont également besoin d’un moyen fiable de découvrir et d’interpréter le service.
Cette structure à deux volets est toutefois importante. Un système de paiement pour agents gagne en utilité à mesure que davantage de services pertinents peuvent accepter des paiements, et les services ont davantage de raisons de prendre en charge les paiements des agents lorsqu’il existe des agents et des clients prêts à les utiliser.
Autrement dit, l’infrastructure doit relier les deux parties à la transaction.
Pourquoi les paiements comptent pour l’économie des agents
L’autonomie devient plus utile lorsque les agents peuvent payer les ressources dont ils ont besoin.
Un agent peut avoir besoin d’accéder à une API, à une source de données, à un service informatique ou aux capacités d’un autre agent. Si chaque interaction exige qu’un humain négocie et effectue manuellement le paiement, l’automatisation peut vite devenir contraignante.
C’est l’une des raisons pour lesquelles l’infrastructure de paiement compte pour l’économie émergente des agents.
Les stablecoins sont utiles dans ces situations, car ils sont conçus pour suivre la valeur d’une monnaie de référence, ce qui rend les montants des transactions plus faciles à évaluer que ceux d’actifs dont le cours fluctue considérablement. Dans le processus de paiement documenté de Kite Passport, l’actif requis pour approvisionner le portefeuille Passport est l’USDC.e sur Kite Chain.
L’avantage potentiel n’est pas que chaque interaction avec l’IA nécessite un paiement. La plupart n’en nécessitent pas. L’intérêt est que lorsqu’un agent doit réellement acheter une ressource, le paiement peut être intégré à son processus au lieu de l’interrompre manuellement.
Mais une transaction qui fonctionne techniquement n’est pas nécessairement utile. Les frais de réseau, le prix des services, les requêtes échouées, les risques de sécurité et la complexité de l’autorisation déterminent tous si les paiements automatisés sont pertinents en pratique.
L’économie des agents a besoin de plus que la capacité de transférer de l’argent. Elle a besoin de systèmes de paiement comme Kite Passport, pratiques à utiliser pour les logiciels et suffisamment sûrs pour que les utilisateurs puissent déléguer en toute confiance.
Un cadre utile pour évaluer l’infrastructure des agents
Lorsque j’examine les projets qui développent une économie des agents, cinq questions me semblent plus utiles que de simplement demander si un projet prend en charge les agents d’IA.
1. Paiements natifs en stablecoins
Les agents peuvent-ils payer des services avec des actifs et des mécanismes de paiement adaptés aux transactions numériques ? Il importe de savoir si le processus de paiement est utile en pratique, et pas seulement s’il existe un jeton ou un portefeuille.
2. Permissions programmables
Les utilisateurs peuvent-ils définir l’autorité accordée à un agent ? Des limites de dépense, des actions restreintes et des permissions limitées dans le temps peuvent aider à garantir que l’accès délégué reste proportionné à la tâche.
3. Authentification conçue d’abord pour les agents
Un agent peut-il s’identifier et interagir avec un service au moyen d’un processus conçu pour les logiciels, tout en respectant l’autorisation accordée par son propriétaire ?
4. Activité vérifiable
Les utilisateurs peuvent-ils examiner les actions et les transactions pertinentes ? La visibilité est importante lorsqu’un agent agit pour le compte de quelqu’un, même si un historique des transactions ne peut à lui seul prouver que chaque décision était correcte ou que tous les processus sous-jacents étaient sécurisés.
5. Transactions économiquement viables
Le système peut-il prendre en charge des transactions à un coût et à une vitesse adaptés aux services concernés ? Si les petits paiements sont trop coûteux ou difficiles à effectuer, de nombreux cas d’usage potentiels pourraient rester impraticables.
Ensemble, ces questions offrent un cadre utile pour évaluer l’infrastructure destinée aux agents autonomes. Elles montrent également pourquoi aucune fonctionnalité isolée ne devrait être confondue avec une solution complète.
Un portefeuille ne résout pas le problème de l’autorisation. Un système d’identité ne garantit pas de bonnes décisions. Une piste d’audit n’élimine pas les failles de sécurité. Et un protocole de paiement ne crée pas automatiquement une demande durable.
Les systèmes les plus robustes doivent faire fonctionner ces éléments ensemble. Kite présente son approche à travers un cadre connexe appelé SPACE : paiements natifs en stablecoins, contraintes programmables, authentification conçue d’abord pour les agents, infrastructure prête à répondre aux exigences de conformité et micropaiements économiquement viables. Ce cadre expose utilement les objectifs du projet, mais ne prouve pas que tous les défis de chaque catégorie ont déjà été résolus. Le véritable test consiste à voir comment ces éléments fonctionnent ensemble dans des déploiements réels.
Qu’est-ce que cela pourrait permettre ?
Si l’identité, les permissions et les paiements des agents deviennent suffisamment fiables, plusieurs types d’interactions pourraient être plus faciles à automatiser.
Les agents pourraient acheter l’accès à des API ou à des données, payer des ressources informatiques et collaborer avec des agents spécialisés qui fournissent des services qu’ils ne peuvent pas assurer eux-mêmes. Les entreprises pourraient également déployer des agents capables d’exécuter certaines étapes d’un processus sur plusieurs services sans qu’un humain ait à approuver chaque interaction individuellement.
Ce sont des pistes plausibles pour une économie des agents, et non la preuve que tous ces cas d’usage fonctionnent déjà à grande échelle.
Leur réussite dépendra de bien plus que la disponibilité de l’infrastructure. Les développeurs doivent créer des services utiles, les utilisateurs doivent avoir des raisons de déléguer des tâches et les entreprises doivent faire confiance aux systèmes qui gèrent leurs ressources.
La technologie peut réduire les frictions, mais elle ne peut pas créer la demande à elle seule.
Le rôle du jeton KITE
Kite possède également un jeton natif, $KITE , qu’il convient de distinguer des stablecoins utilisés pour les paiements de services avec Passport. Dans le processus d’approvisionnement documenté, l’USDC.e sert aux paiements des agents sur Kite Chain, tandis que $KITE est nécessaire pour payer les frais de gaz lors du transfert de fonds depuis un portefeuille externe déjà sur Kite Chain.
Ce rôle documenté dans le paiement des frais de gaz ne constitue pas une description complète de l’utilité plus générale du jeton. Tout rôle supplémentaire devrait être évalué au regard de la documentation actuelle du projet, en distinguant les fonctionnalités disponibles de celles qui sont prévues. Il ne faut pas déduire l’utilité du jeton de la seule vision générale du projet.
Le véritable test consiste à déléguer en toute sécurité
La promesse des agents d’IA est facile à comprendre. Ils pourraient prendre en charge une plus grande partie du travail entre la définition de ce que nous voulons et sa réalisation.
Mais plus nous leur accordons d’autorité, plus il devient important de décider où celle-ci s’arrête.
À mes yeux, c’est l’un des défis centraux de l’économie des agents. Les développeurs ne cherchent pas seulement à créer des systèmes capables d’agir de manière autonome. Ils cherchent à créer des systèmes auxquels les gens peuvent raisonnablement faire confiance pour agir en leur nom.
L’attention que Kite porte à l’identité des agents, aux permissions déléguées et à l’infrastructure de paiement répond à certains aspects de ce défi. Passport rend cette idée particulièrement concrète en reliant les limites de dépense fixées par l’utilisateur aux actions qu’un agent peut effectuer dans le cadre d’une session approuvée. Son importance à long terme dépendra de la fiabilité de ces contrôles, de la facilité avec laquelle les services s’intègrent aux processus de paiement et de l’utilité de l’expérience pour les utilisateurs.
Des questions restent ouvertes concernant la sécurité, la responsabilité, la facilité d’utilisation et l’adoption. Il ne faut pas les écarter sous prétexte que la technologie est prometteuse. Ce sont précisément ces questions qui détermineront si cette promesse devient utile en pratique.
Un agent capable d’exécuter une tâche est utile. Un agent capable de l’exécuter dans des limites clairement définies l’est davantage. Et un agent dont les actions peuvent être comprises, surveillées et interrompues au moyen de contrôles réellement pris en charge inspire plus facilement confiance. C’est l’orientation générale que Kite cherche à suivre, même si le véritable test sera de voir comment ces contrôles fonctionnent en pratique.
L’avenir de l’IA autonome ne devrait pas se mesurer à la liberté que nous accordons aux agents, mais à l’intelligence avec laquelle nous définissons celle dont ils ont besoin.