En 1984, Apple (Macintosh) a tué la ligne de commande avec une souris. En 2026, l'Agent est en train de tuer la souris.

Ce n'est pas une métaphore. Google, Amazon, Nvidia, Visa, Microsoft, Alibaba, ces entreprises qui ont dépensé des milliards de dollars pour perfectionner les interfaces graphiques, contournent activement les GUI pour se tourner vers les CLI, API et les interfaces natives d'Agent. La logique est simple : la croissance de 0 à 1 dépend des humains, mais le prochain facteur de dix utilisateurs ne regardera plus l'écran.

Mais ce que tout le monde évite de dire est : lorsque l'utilisateur du logiciel devient un Agent, l'homme a-t-il encore besoin d'être présent ?

Dès 1950, le fondateur de la cybernétique, Norbert Wiener, avait émis un avertissement : une fois que les humains perdent leur capacité d'observation et d'intervention, la boucle de rétroaction se rompt et le système devient incontrôlable. Aujourd'hui, ce qu'OpenAI met en avant avec le « Harness Engineering » est essentiellement la continuation de cette pensée.

Plus de soixante-dix ans plus tard, l'Agentic Wallet est confronté à la version cryptographique de ce problème. Les fenêtres pop-up de confirmation, les demandes de signature, les processus d'approbation, la sauvegarde des phrases de récupération, l'authentification multi-facteurs... Les mécanismes de sécurité que les portefeuilles cryptographiques ont mis dix ans à construire répondent tous à une question : « Cette opération est-elle vraiment autorisée par vous-même ? » L'Agent rend ce mécanisme d'interaction humaine obsolète : continuer à exiger une confirmation manuelle opération par opération empêche l'Agent d'exécuter de manière continue, en temps réel et automatisée ; donner directement un contrôle illimité de la clé privée à l'Agent fait courir un risque inacceptable à l'humain.

La réponse ne se trouve pas dans les deux extrêmes. L'autonomie totale est le récit le plus sexy de l'ère de l'Agent, mais l'avertissement de Wiener reste valable.

Nous pensons que l'Agentic Wallet doit servir simultanément deux types d'entités : d'une part, fournir aux humains des capacités de définition de règles, de contrôle des risques et d'intervention de gouvernance ; d'autre part, fournir à l'Agent des droits d'exécution contraints, lui permettant d'effectuer des opérations on-chain de manière autonome dans des limites clairement définies. En d'autres termes, le portefeuille doit évoluer d'un conteneur d'actifs et d'un outil de signature utilisé par l'homme vers un système de permissions et d'exécution qui permet à l'homme de définir des limites et à l'Agent d'agir à l'intérieur de ces limites.

À quoi devrait ressembler ce système ? C'est précisément la question à laquelle cet article répond.

I. Au-delà du Fat Wallet, une autre guerre des portefeuilles

Delphi Digital, dans son article « Fat Wallet Thesis », a avancé un jugement pertinent : Alors que les couches de protocole et d'application deviennent de plus en plus homogènes, la valeur se déposera au niveau de la couche portefeuille, car le portefeuille est le plus proche de l'utilisateur, maîtrise les canaux de distribution et le flux des ordres, et les utilisateurs resteront également longtemps dans un portefeuille donné en raison de l'interface familière, des actifs détenus et des frictions de migration.

Mais l'Agent ne suit pas la même logique. En tant qu'exécutant machine « impassible », l'Agent ne restera pas dans un portefeuille particulier par familiarité de l'interface, préférence de marque ou habitude d'utilisation comme le ferait un humain. Il recherchera continuellement la combinaison d'infrastructures la moins chère, avec la latence la plus faible et l'exécution la plus stable. Avec la popularisation progressive de standards comme l'ERC-8004, la couche d'identité et de réputation de l'Agent devrait également migrer entre différents systèmes, ce qui signifie que l'effet de verrouillage du portefeuille sur l'Agent est naturellement plus faible que sur l'homme.

Cependant, cela ne signifie pas que la valeur du portefeuille disparaît, mais que l'endroit où la valeur se dépose va changer. Dans les scénarios d'utilisation personnelle simples, l'Agent affaiblira le fossé existant du portefeuille basé sur l'interface, les habitudes et l'accès ; tandis que dans les scénarios de déploiement organisationnel plus complexes, une fois que l'entreprise a configuré des règles de stratégie, des processus d'approbation, des paramètres de gestion des risques et un système d'audit pour toute une « flotte d'Agents », le coût de migration ne provient plus de l'expérience frontale, mais de la reconstruction de l'ensemble des configurations de permissions, de gouvernance et d'exploitation.

Par conséquent, l'Agentic Wallet répond à une autre problématique au-delà du Fat Wallet : Le Fat Wallet se dispute l'entrée utilisateur, l'Agentic Wallet se dispute le contrôle lorsque le logiciel commence à支配直接支配 les fonds.

Si l'on revient sur l'évolution des portefeuilles, on constate qu'à chaque changement de forme du produit, il correspond essentiellement à un changement de l'objet de confiance de l'utilisateur :

· Portefeuille à phrase de récupération, exige que l'utilisateur se fie à lui-même.

· Portefeuille à contrat intelligent, exige que l'utilisateur fasse confiance au code.

· Portefeuille intégré (Embedded wallet), exige que l'utilisateur fasse confiance au fournisseur de service.

Et avec l'Agentic Wallet, l'utilisateur doit faire confiance à un système de contrôle constitué de permissions, de stratégies et de mécanismes de gouvernance.

L'objectif de ce système n'est pas de laisser le logiciel prendre le contrôle des fonds, mais de lui permettre d'agir avec une autorisation limitée, tout en laissant à l'homme le contrôle final. C'est aussi pourquoi le cœur de l'Agentic Wallet n'est pas seulement « permettre à l'Agent d'utiliser un portefeuille », mais « permettre à l'Agent de gérer les fonds appartenant à des utilisateurs humains dans des conditions contraignables, auditablees et interventionnables ».

II. Les limites du portefeuille, le point de départ de l'Agent

Les portefeuilles existants fonctionnent toujours bien dans le scénario pour lequel ils ont été conçus à l'origine, mais le problème est que de plus en plus de cas d'utilisation pilotés par l'Agent dépassent les limites de conception des portefeuilles existants.

Scénario 1 : L'Agent de trading doit agir rapidement, mais « avoir la capacité d'exécuter » n'égale pas « être autorisé à exécuter »

Un Agent de portefeuille d'investissement surveille la liquidité cross-chain 24h/24 et 7j/7. Lorsqu'une opportunité se présente, il doit effectuer la transaction en quelques secondes. La logique de contrôle du portefeuille traditionnel est : l'utilisateur ouvre l'application - vérifie la transaction - clique pour confirmer. Le temps que ce processus soit terminé, la fenêtre d'opportunité est souvent déjà fermée.

D'un point de vue technique, l'Agent a déjà la capacité d'appeler la fonction swap, de générer le calldata, de bridge les fonds. Le problème est que la capacité n'égale pas la permission. Qu'un Agent puisse initier une transaction ne signifie pas qu'il devrait être autorisé à支配 librement les fonds.

Le rôle de l'Agentic Wallet est précisément de séparer les deux : L'Agent peut agir instantanément, mais seulement dans le cadre de règles prédéfinies, par exemple limité aux actifs approuvés, soumis à un budget journalier, contraint par des limites de slippage, et se mettant automatiquement en pause lorsque les conditions de marché sont anormales. Le Skill définit ce que l'Agent « peut faire », tandis que le portefeuille est responsable de contraindre ce que l'Agent « est autorisé à faire ».

Scénario 2 : L'Agent de paiement a besoin de dépenser, mais ne devrait pas avoir le contrôle total des fonds

Un Agent de paiement est responsable du règlement automatique des factures d'API, des abonnements SaaS et des paiements aux fournisseurs. Dans le système de portefeuille actuel, il n'a généralement que deux choix : soit attendre une approbation manuelle pour chaque paiement, soit détenir directement une clé privée avec un droit de signature illimité. Le premier n'est pas scalable, le second est trop risqué.

L'Agentic Wallet fournit une autorisation limitée : Il ne peut payer que des commerçants en liste blanche, n'utiliser que des actifs spécifiés, n'exécuter des paiements que dans la limite du budget quotidien, et toutes les dépenses sont intégralement enregistrées.

Scénario 3 : Plusieurs Agents ont besoin d'avoir des permissions isolées les unes des autres sous un budget partagé

Une entité peut exécuter simultanément plusieurs Agents : un responsable des transactions, un responsable des paiements, un responsable de l'examen. Le portefeuille actuel peut bien sûr créer plusieurs sous-comptes, mais orchestrer uniformément les permissions de ces comptes, définir des limites budgétaires globales, appliquer des contraintes de stratégie cross-Agent et former un circuit d'audit unifié n'est pas une capacité native des portefeuilles existants.

Dans le modèle Agentic Wallet, cela serait traité comme un problème de conception prioritaire : Chaque Agent dispose de permissions indépendantes et clairement définies ; dans le même temps, une couche de stratégie unifiée est responsable du contrôle de l'exposition globale au risque, des limites de fréquence cross-Agent et du budget partagé, et génère des enregistrements d'audit cohérents.

Ces scénarios pointent vers la même conclusion : La gestion des clés privées reste la base de la sécurité du portefeuille, laisser un Agent entrer en contact direct avec une clé privée est une source de risque inacceptable dans tous les scénarios. Mais simplement bien gérer les clés privées ne suffit plus.

Lorsque l'opérateur passe de l'homme à l'Agent, le portefeuille doit également répondre à une deuxième question : Qui est autorisé, dans quelles conditions, avec quel montant, sur quels actifs, et envers quelles cibles à agir. La gestion des clés privées est la première ligne de défense, la gestion des limites de permission pour les opérateurs non humains est le deuxième pare-feu ajouté à l'ère de l'Agent.

III. Autonomie bornée : La philosophie de conception de l'Agentic Wallet

L'industrie en est encore à un stade d'exploration précoce concernant l'Agentic Wallet, et il n'existe pas encore de solution Agentic Wallet véritablement mature. Cependant, comme mentionné en introduction, cet article considère que l'Agentic Wallet est un système de contrôle des fonds connectant la gouvernance humaine et l'exécution de l'Agent : l'homme est responsable de définir les limites, l'Agent est responsable d'agir à l'intérieur de ces limites, et le portefeuille est responsable de s'assurer que cette relation de contrainte reste toujours exécutable, auditable et interventionnable.

Selon le degré d'autorisation accordé à l'Agent, l'Agentic Wallet servira probablement aussi les 4 cas suivants :

Type Contrôle humain : L'Agent fournit des recommandations et une assistance, chaque opération nécessite encore une confirmation humaine. Améliore l'efficacité de l'interaction, la logique de contrôle des fonds ne change pas.

Type Hybride : L'Agent traite les opérations routinières, comme la récupération, les devis, les rappels ou l'exécution à faible risque ; l'intervention humaine diminue en fréquence, mais les cas limites nécessitent encore une approbation humaine, comme les transferts de fonds, les appels de contrat ou les branches异常.

Type Autonomie bornée : L'Agent agit de manière autonome dans le cadre de règles, de limites et de chemins de veto clairs. L'homme passe de l'approbateur opération par opération au définisseur de règles. L'Agentic Wallet discuté dans cet article pointe principalement vers cette catégorie.

Type Autonomie complète : L'Agent possède une souveraineté économique quasi complète, peut调度 indépendamment les fonds et en assumer les résultats sans limites prédéfinies. Ce modèle est théoriquement valable, mais il est encore loin d'être mature en termes de sécurité, gouvernance, attribution des responsabilités et conformité, et reste essentiellement au stade expérimental.

À titre de référence, Stripe, dans sa lettre annuelle 2025, a divisé l'agentic commerce en cinq niveaux : L1 pour le remplissage automatique de formulaires (Eliminating web forms), L2 pour la recherche descriptive (Descriptive search), L3 pour la mémoire persistante (Persistence), L4 pour la délégation d'autorisation (Delegation), L5 pour l'achat anticipatif (Anticipation) ; tout en jugeant clairement que l'industrie dans son ensemble « erre encore à la lisière du L1 et du L2 ».

Sous cet angle, la plus grande demande du marché provient probablement des scénarios de type Contrôle humain et Hybride, et l'autonomie bornée est la véritable frontière actuelle, et aussi la première forme au niveau production où l'Agent commence vraiment à gérer des fonds.

Réaliser cette conception nécessite une architecture à quatre couches :

· Couche Compte : Établir un conteneur économique indépendant et isolé pour chaque Agent, par exemple via EOA, compte à contrat intelligent, portefeuille serveur ou environnement TEE. Le système doit appliquer des règles différenciées à différents Agents.

· Couche Permission : Définir les limites de comportement de l'Agent, comme le montant utilisable, les actifs actionnables, les contrats interactifs, la fenêtre temporelle d'exécution, la logique d'action en cas de limite atteinte. C'est la couche centrale de toute l'architecture.

· Couche Exécution : Interface orientée Agent et non clic humain. L'envoi, le paiement, le Swap, le bridge, le rééquilibrage, la liquidation, le règlement, doivent tous être抽象és en primitives可以直接 appelées par un programme.

· Couche Gouvernance : Doit fournir des journaux, de la simulation, une traçabilité d'audit, des alertes, un interrupteur de pause, un droit de veto humain, des mécanismes de récupération, etc. Cette couche détermine si l'Agentic Wallet peut vraiment entrer en environnement de production.

Au-dessus de l'architecture à quatre couches, quatre capacités核心 sont nécessaires pour soutenir le système :

Skills : Fournir des modules d'opération on-chain standardisés. L'Agent peut effectuer des actions comme des transactions, des paiements, des bridges comme s'il appelait des fonctions, sans avoir à assembler lui-même le calldata sous-jacent. Le Skill résout le problème de l'abstraction de la capacité « ce qui peut être fait ».

Policies + KYA / KYT : Le moteur Policies est responsable de vérifier les règles pour chaque opération, transformant les limites définies par l'homme en conditions de contrainte exécutables par la machine ; le mécanisme KYA / KYT est utilisé pour identifier la provenance, l'identité, le contexte de risque et l'historique d'exécution de l'Agent. Le premier contraint le comportement, le second identifie l'opérateur, ensemble ils assurent que toutes les actions sur les fonds restent within预设 limites.

Session Key : Fournit un mécanisme de délégation sécurisée limitée dans le temps, le montant et la portée. L'Agent obtient une autorisation temporaire et limitée, et non une clé privée complète. L'autorisation expire automatiquement, sans révocation manuelle, « permettre à l'Agent d'obtenir des qualifications d'exécution sans toucher à la clé complète ».

Audit et Notification : Fournit des journaux d'opération traçables en全程 et un système d'alerte en temps réel. Chaque opération peut être retracée, chaque异常 peut être alerté, chaque Agent peut être suspendu à tout moment.

Actuellement, nous contrôlons généralement la logique comportementale de l'Agent par des instructions, mais l'orchestration des tâches n'égale pas la contrainte des fonds.

L'Agent peut encore mal juger, dévier, ou subir des attaques et une污染 des entrées externes. La signification de la couche portefeuille réside précisément dans le fait de固化为 règles système des questions impliquant les permissions de fonds telles que « peut-il动用 les fonds, combien peut-il动用, quels actifs peut-il操作, avec quelles entités peut-il interagir, et comment arrêter en cas异常 ». Même si l'Agent s'écarte, les actions réelles sur les fonds qui peuvent se produire restent limitées aux limites prédéfinies.

IV. État actuel de l'Agentic Wallet : Quatre approches et quatre lacunes

Concernant les solutions Agentic Wallet existantes, nous avons identifié 4 cas typiques qui ont essentiellement résolu le problème « comment faire entrer l'Agent dans le système de fonds », mais n'ont pas encore répondu à « comment faire en sorte que l'Agent utilise les fonds en toute sécurité dans des environnements cross-chain et现实 complexes ».

Coinbase, Safe, Privy et Polygon ont déjà apporté各自 des réponses viables respectivement au niveau de l'infrastructure, de la gouvernance, des permissions et de l'identité, ce qui reste à faire est d'intégrer davantage ces capacités partielles en un système de contrôle unifié qui peut fonctionner cross-chain, migrer跨环境, et tenir dans des scénarios对抗 complexes. Les goulots d'étranglement communs de l'Agentic Wallet à ce stade, se concentrent principalement sur les quatre lacunes suivantes :

Premièrement, l'identité et la réputation ne sont pas encore移植ables.

Un système d'identité et de réputation d'Agent on-chain peut être établi, mais un système de crédit universel跨链,跨钱包,跨环境 d'exécution n'existe toujours pas. L'historique et la réputation accumulés par un Agent dans un écosystème donné ne peuvent pas migrer naturellement vers un autre écosystème.

Deuxièmement, la couche stratégie manque de standards unifiés.

Coinbase utilise spending limits, Safe utilise des modules on-chain, Privy utilise policy engine, Polygon utilise session-scoped wallet. L'industrie a普遍意识到 que la couche permission est核心, mais n'a pas encore formé de standard de stratégie unifié移植able,组合able et跨产品 réutilisable.

Troisièmement, la sécurité对抗 reste高度空白.

L'injection de prompt, l'empoisonnement d'outils, les Skills malveillants, les entrées externes polluées, ces problèmes ne seront pas automatiquement résolus par un audit traditionnel de contrat. Le problème vraiment nouveau à l'ère de l'Agent est : lorsque le processus de décision du modèle est扭曲 par des entrées malveillantes, comment le portefeuille identifie-t-il, intervient-il et bloque-t-il le risque.

Quatrièmement, la couverture全链 est loin d'être réalisée.

La plupart des solutions existantes sont attachées à une seule chaîne ou à une多链 limitée, mais les activités économiques de l'Agent ne resteront pas longtemps confinées à un seul écosystème. Un Agentic Wallet véritablement mature doit faire face aux problèmes de多链, de多环境 d'exécution et de cohérence des permissions跨域.

V. Sous la surface : La prochaine décennie de l'Agentic Wallet

Actuellement, l'accent de la conception de l'Agentic Wallet est de permettre aux humains d'exercer un contrôle fin sur l'Agent. Dans la plupart des implémentations, le rôle du portefeuille se rapproche plus d'un signataire passif : L'Agent appelle un Skill, le Skill génère une transaction, le portefeuille signe en backend, l'exécution on-chain a lieu随之.

Mais si l'Agent commence vraiment à gérer des fonds, signer seulement à la dernière étape n'est clairement pas suffisant. Une approche plus raisonnable est de faire en sorte que le jugement de permission ait lieu avant l'exécution : après que l'Agent a appelé un Skill, la requête entre d'abord dans le Policy Plane interne du portefeuille, et l'exécution n'est autorisée que si elle passe la validation des stratégies.

Le所谓 Wallet Policy Plane, emprunte l'idée des plans de contrôle (Control Plane) et de données (Data Plane) de l'architecture système. Il se situe entre le comportement de l'Agent et l'exécution on-chain, et intègre le moteur Policies, la validation KYT/KYA, la vérification Session Key, le scoring risque et le traitement des异常 en un seul plan de décision unifié.

Cette idée n'est pas étrangère, l'architecture de paiement de Stripe suit une logique similaire : les développeurs appellent une API简洁, mais avant que les fonds ne bougent réellement, Stripe a déjà effectué en arrière-plan l'identification des risques, la vérification des règles et le traitement de la conformité. L'Agentic Wallet doit faire essentiellement la même chose, offrir une interface d'exécution propre aux développeurs en surface, et utiliser un moteur de stratégie préalable pour effectuer l'arbitrage des permissions en sous-sol.

L'urgence est que la surface d'attaque apportée par l'injection de prompt, l'empoisonnement d'outils, les Skills malveillants se développe rapidement, et les infrastructures de sécurité côté portefeuille n'ont pas du tout suivi. Le Wallet Policy Plane standardisé n'est pas encore aujourd'hui une primitive de base通用 de l'industrie.

Cependant, le Policy Plane lui-même ne sera pas non plus l'état final. Au fur et à mesure que le système d'identité et de réputation de l'Agent mûrit, la logique d'autorisation passera d'une驱动 par règles statiques à une驱动 par confiance dynamique. Aujourd'hui, cela repose sur des limites prédéfinies, des restrictions de montant, des listes blanches et des chemins de veto humain ; à l'avenir, les historiques de transactions on-chain, les轨迹 comportementales et les données de crédit跨生态 constitueront progressivement une base de crédit vérifiable pour l'Agent, et davantage de décisions d'autorisation seront prises sur la base de l'identité, de l'historique et des performances réelles.

Lorsque les Agents commenceront à interagir économiquement entre eux à la vitesse de la machine, les mécanismes de contrôle doivent être intégrés dès la création du système. Le rôle du portefeuille changera également随之 : Au début, il est le gardien, responsable d'empêcher les comportements transgression ; à maturité, il se rapproche davantage de l'infrastructure, responsable de permettre à des entités dignes de confiance de se connecter avec moins de friction aux comptes, aux permissions et aux systèmes de règlement.

Ces dix dernières années, le champ de bataille du portefeuille était cette entrée sur l'écran. Les dix prochaines années, le champ de bataille est dans cette couche de contrôle que l'utilisateur ne voit pas.