Rédigé par : Lacie Zhang, Chercheuse chez Bitget Wallet
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 pour Agents. La logique est simple : la croissance de 0 à 1 dépend des humains, mais le prochain facteur dix d'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 « 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 secrètes, l'authentification multifactorielle... 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 ces mécanismes d'interaction humaine obsolètes : continuer à exiger une confirmation humaine transaction par transaction 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'homme.
La réponse ne se trouve pas dans les deux extrêmes. L'autonomie totale est le récit le plus séduisant 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 permissions d'exécution contraintes, lui permettant d'effectuer de manière autonome des opérations on-chain 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 dans 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 du portefeuille, car celui-ci est le plus proche de l'utilisateur, maîtrise les canaux de distribution et le flux d'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 liées à la 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 au coût le plus bas, à la latence la plus faible et à l'exécution la plus stable. Avec la popularisation progressive de standards comme 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 les barrières existantes du portefeuille basées sur l'interface, les habitudes et les points d'entrée ; 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 des systèmes 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 de la configuration des permissions, de la gouvernance et de l'exploitation.
Par conséquent, l'Agentic Wallet répond à une autre proposition 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 du portefeuille, on constate que chaque changement de forme de produit correspond essentiellement à un changement de l'objet de confiance de l'utilisateur :
- Le portefeuille à phrase secrète exige que l'utilisateur se fie à lui-même.
- Le portefeuille à contrat intelligent exige que l'utilisateur se fie au code.
- Le portefeuille embarqué exige que l'utilisateur se fie au fournisseur de services.
- Et avec l'Agentic Wallet, l'utilisateur doit se fier à 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 permettre au logiciel 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, auditable et pouvant faire l'objet d'interventions ».
II. Les limites du portefeuille, le point de départ de l'Agent
Les portefeuilles existants fonctionnent toujours bien dans les scénarios pour lesquels 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 « être capable d'exécuter » n'est pas égal à « ê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 que l'utilisateur ouvre l'application - vérifie la transaction - clique pour confirmer. Le temps que ce processus se déroule, 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 des calldata, de bridge des fonds, le problème est que la capacité n'est pas égale à la permission. Le fait 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 humaine 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 offre une autorisation restreinte : 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 des paiements, un de l'examen. Le portefeuille actuel peut bien sûr créer plusieurs sous-comptes, mais orchestrer de manière unifiée les permissions de ces comptes, définir des plafonds budgétaires globaux, appliquer des contraintes de stratégie inter-Agents 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 inter-Agents 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 l'Agent entrer en contact avec la 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é à agir, dans quelles conditions, avec quel montant, sur quels actifs, et vers quelles contreparties. 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 la deuxième couche pare-feu ajoutée à l'ère de l'Agent.
III. Autonomie bornée : La philosophie de conception de l'Agentic Wallet
L'industrie en est encore à un stade précoce d'exploration de l'Agentic Wallet, et il n'existe pas encore de solution Agentic Wallet véritablement mature. Cependant, comme mentionné dans l'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 par l'Agent : l'homme est responsable de définir les limites, l'Agent est responsable d'agir dans ces limites, et le portefeuille est responsable de s'assurer que cette relation de contrainte reste toujours exécutable, auditable et sujette à intervention.
Simultanément, selon le degré d'autorisation accordé à l'Agent, l'Agentic Wallet pourrait également servir les 4 cas suivants :
- Type contrôlé par l'homme : L'Agent fournit des conseils 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 n'a pas changé.
- Type hybride : L'Agent traite les opérations routinières, comme la récupération, la cotation, 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 le transfert de fonds, l'appel 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 voies de veto claires. L'homme passe d'un approbateur transaction par transaction à un définisseur de règles. L'Agentic Wallet discuté dans cet article pointe principalement vers cette catégorie.
- Type entièrement autonome : 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 est loin d'être mature en termes de sécurité, gouvernance, attribution des responsabilités et conformité, restant 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 frontière entre L1 et L2 ».
Sous cet angle, la plus grande demande du marché provient probablement des scénarios de type contrôlé par l'homme et hybride, tandis que l'autonomie bornée est la véritable frontière actuelle, et la première forme au niveau production où l'Agent commence véritablement à 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 de 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 cœur de toute l'architecture.
- Couche exécution : Orienter vers une interface Agent plutôt que des clics humains. L'envoi, le paiement, le Swap, le bridging, le rééquilibrage, la liquidation, le règlement, doivent tous être抽象és en primitives pouvant être appelées directement 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 fonctionnement du système :
- Skills : Fournir des modules d'opération on-chain standardisés. L'Agent peut effectuer des actions comme des transactions, des paiements, du bridging comme s'il appelait des fonctions, sans avoir à assembler lui-même les calldata sous-jacents. 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 chaque opération par rapport aux règles, 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 dans les limites prédéfinies.
- Session Key : Fournir 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, « permettant à l'Agent d'obtenir des qualifications d'exécution sans toucher à la clé complète ».
- Audit et notification : Fournir des journaux d'opération traçables en continu 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'est pas égale à 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 est précisément de figer à l'avance en règles système des questions impliquant les permissions de fonds comme « peut-il动用 les fonds, combien peut-il动用, quels actifs peut-il操作, avec quelles contreparties peut-il interagir, et comment arrêter en cas d'异常 ». 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
En ce qui concerne les solutions Agentic Wallet existantes, nous avons identifié 4 cas typiques qui ont essentiellement résolu le problème de « comment faire entrer l'Agent dans le système de fonds », mais n'ont pas encore répondu à « comment permettre à l'Agent d'utiliser les fonds en toute sécurité dans des environnements cross-chain et complexes réels ».
Coinbase, Safe, Privy et Polygon ont déjà apporté leurs réponses respectives et viables aux niveaux de l'infrastructure, de la gouvernance, des permissions et de l'identité, mais ce qui reste à faire est d'intégrer davantage ces capacités partielles en un système de contrôle unifié capable de fonctionner de manière cross-chain, de migrer entre environnements et de tenir dans des scénarios complexes et antagonistes. 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 on-chain pour les Agents peut être établi, mais un système de crédit universel跨链,跨portefeuille,跨environnement d'exécution n'existe pas encore. L'historique et la réputation accumulés par un Agent dans un écosystème ne peuvent pas migrer naturellement vers un autre écosystème.
Deuxièmement, la couche stratégie manque de standards unifiés.
Coinbase utilise des spending limits, Safe utilise des modules on-chain, Privy utilise un policy engine, Polygon utilise des session-scoped wallet. L'industrie a généralement pris conscience que la couche permission est核心, mais n'a pas encore formé de standard de stratégie unifié移植able, composable et réutilisable跨produit.
Troisièmement, la sécurité antagoniste est encore très lacunaire.
L'injection de prompt, l'empoisonnement d'outil, les Skills malveillants, les entrées externes polluées, ces problèmes ne seront pas résolus automatiquement 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.
Les solutions existantes sont mostly attachées à une seule chaîne ou à une多链limitée, mais l'activité économique de l'Agent ne restera pas longtemps confinée à un seul écosystème. Un Agentic Wallet véritablement mature doit faire face aux problèmes de多链, de多environnements 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 à l'homme 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é le 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, intégrant le moteur Policies, la validation KYT/KYA, la vérification de la Session Key, le scoring de 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 simple, 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é. Ce que l'Agentic Wallet doit faire est essentiellement la même chose, offrir une interface d'exécution propre en surface, et utiliser un moteur de stratégie préalable pour effectuer les arbitrages de permissions en couche inférieure.
L'urgence réside dans le fait que la surface d'attaque apportée par l'injection de prompt, l'empoisonnement d'outil, les Skills malveillants se développe rapidement, tandis que l'infrastructure de sécurité côté portefeuille n'a pas du tout suivi. Le Wallet Policy Plane standardisé n'est pas encore aujourd'hui une primitive de base universelle dans l'industrie.
Cependant, le Policy Plane lui-même ne sera pas non plus l'état final. À mesure que le système d'identité et de réputation de l'Agent mûrit, la logique d'autorisation passera d'une conduite par règles statiques à une conduite dynamique par confiance. Aujourd'hui, on repose sur des limites prédéfinies, des restrictions de montant, des listes blanches et des voies de veto humain ; à l'avenir, les historiques de transactions on-chain, les轨迹comportementales et les données de crédit跨écosystème 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 rapprochera davantage de l'infrastructure, responsable de permettre à des entités dignes de confiance de connecter les comptes, les permissions et les systèmes de règlement avec une friction plus faible de manière continue.
Au cours des dix dernières années, le champ de bataille du portefeuille était cette entrée sur l'écran. Au cours des dix prochaines années, le champ de bataille sera dans cette couche de contrôle que l'utilisateur ne voit pas.
