Le Pouvoir de l'Agence : Le Portefeuille Agentique et la Prochaine Décennie des Portefeuilles

Titre Original : "L'Utilité des Humains : Portefeuille Agentique et la Prochaine Décennie des Portefeuilles"

Source Originale : Portefeuille Bitget

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

Ce n'est pas une métaphore. Des entreprises comme Google, Amazon, NVIDIA, Visa, Microsoft et Alibaba, qui ont dépensé des milliards de dollars à perfectionner les interfaces graphiques, contournent proactivement les GUI et se tournent vers les interfaces CLI, API et natives aux Agents. La logique est simple : une croissance dépendante des humains de 0 à 1, mais la prochaine base d'utilisateurs multipliée par dix ne regardera plus les écrans.

Mais ce que tout le monde évite, c'est : lorsque les utilisateurs de logiciels passent de l'humain à l'Agent, l'humain doit-il encore être présent ?

Dès 1950, le fondateur de la cybernétique, Wiener (Norbert Wiener), a émis un avertissement : une fois que les humains perdent la capacité d'observer et d'intervenir, la boucle de rétroaction se brisera et le système spirale hors de contrôle. Ce qu'OpenAI souligne aujourd'hui comme "Ingénierie de l'Exploitation" est fondamentalement une continuation de cette idée.

Plus de soixante-dix ans plus tard, le Portefeuille Agentique est confronté à la version cryptée de ce problème. Des fenêtres contextuelles de confirmation, des demandes de signature, des processus d'approbation, des sauvegardes de phrases mnémotechniques, une authentification multi-facteurs... Les mécanismes de sécurité construits par le portefeuille crypto au cours de la dernière décennie visent tous à répondre à une question : « Cette transaction est-elle vraiment autorisée par vous ? » L'Agent provoque l'échec progressif de ce mécanisme d'interaction humaine : en continuant à exiger une confirmation manuelle pour chaque transaction, l'Agent ne peut pas atteindre une exécution continue, en temps réel et automatisée ; donner directement le contrôle de la clé privée illimitée à l'Agent entraînerait des risques inacceptables pour les humains.

La réponse ne se trouve pas dans 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 pertinent.

Nous croyons que le Portefeuille Agentique doit simultanément servir deux types d'entités : d'une part, fournir des capacités de définition de règles, de contrôle des risques et d'intervention de gouvernance pour les humains ; d'autre part, fournir des permissions d'exécution contraintes pour l'Agent, lui permettant d'effectuer de manière autonome des opérations sur la chaîne dans des limites claires. En d'autres termes, le portefeuille doit évoluer d'un conteneur d'actifs et d'un outil de signature utilisé par les humains vers un système qui permet aux humains de définir des limites et permet aux Agents d'agir dans ces limites.

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

1. Au-delà du Portefeuille Épais, une autre guerre des portefeuilles

Delphi Digital a une fois fait une déclaration puissante dans la Thèse du Portefeuille Épais : À mesure que les protocoles et la couche d'application deviennent de plus en plus homogénéisés, la valeur se stabilisera dans la couche de portefeuille. Les portefeuilles sont les plus proches de l'utilisateur, contrôlant le canal de distribution et le flux de commandes. Les utilisateurs resteront dans un portefeuille à long terme en raison d'interfaces familières, de l'adhérence des actifs et de la friction de migration.

Cependant, l'Agent ne suit pas la même logique. En tant qu'exécuteur « impitoyable », l'Agent ne restera pas dans un portefeuille particulier comme le ferait un humain en raison de la familiarité de l'interface, de la préférence de marque ou des habitudes d'utilisation. Il continuera à rechercher la combinaison d'infrastructure avec le coût le plus bas, la latence minimale et l'exécution la plus stable. À mesure que des normes comme l'ERC-8004 deviennent progressivement répandues, la couche d'identité et de réputation de l'Agent a également le potentiel de migrer à travers différents systèmes. Cela signifie que l'effet de verrouillage du portefeuille sur l'Agent est intrinsèquement plus faible que son effet de verrouillage sur les humains.

Néanmoins, cela ne signifie pas que la valeur du portefeuille disparaît, mais plutôt que la position de règlement de la valeur changera. Dans un cas d'utilisation individuel simple, l'Agent affaiblira la protection du portefeuille en fonction de l'interface, des habitudes et des points d'entrée. Dans un scénario de déploiement organisationnel relativement complexe, une fois qu'une entreprise configure des règles de politique, des processus d'approbation, des paramètres de risque et des systèmes d'audit autour d'une "flotte d'Agents", les coûts de migration ne proviendront plus de l'expérience frontend mais de la reconstruction de l'ensemble des permissions, de la gouvernance et des configurations opérationnelles.

Par conséquent, le Portefeuille Agentique aborde une autre proposition au-delà du Portefeuille Épais : Alors que le Portefeuille Épais rivalise pour les points d'entrée des utilisateurs, le Portefeuille Agentique rivalise pour le contrôle lorsque le logiciel gouverne directement les fonds.

En regardant l'évolution des portefeuilles, on constate que chaque changement de forme de produit correspond fondamentalement à un changement dans l'objet de confiance de l'utilisateur :

· Les Portefeuilles de Phrase Mnémonique nécessitent que les utilisateurs se fassent confiance.

· Les Portefeuilles de Contrat Intelligent nécessitent que les utilisateurs fassent confiance au code.

· Les Portefeuilles Intégrés nécessitent que les utilisateurs fassent confiance au fournisseur de services.

Et avec le Portefeuille Agentique, ce que les utilisateurs doivent faire confiance est un système de contrôle composé de permissions, de politiques 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 sous une autorisation limitée tout en permettant aux humains de conserver le contrôle ultime. C'est pour cette raison que le cœur du Portefeuille Agentique n'est pas seulement de "permettre aux Agents d'utiliser un portefeuille", mais de "permettre aux Agents de gérer des fonds appartenant à des utilisateurs humains dans des conditions qui sont contraignables, auditables et intervenables."

II. Limites du Portefeuille, Point de Départ de l'Agent

Les portefeuilles existants fonctionnent toujours bien dans leurs scénarios initialement conçus, mais le problème est que de plus en plus de cas d'utilisation pilotés par des Agents dépassent les limites de conception du portefeuille actuel.

Scénario 1 : Un Agent de transaction doit agir rapidement, mais "avoir la capacité d'exécuter" n'est pas égal à "être autorisé à exécuter"

Un Agent de portefeuille surveille la liquidité inter-chaînes 24 heures sur 24. Lorsqu'une opportunité se présente, il doit compléter une transaction en quelques secondes. La logique de contrôle des portefeuilles traditionnels est que l'utilisateur ouvre l'application - vérifie la transaction - clique sur confirmer. Au moment où ce processus est terminé, la fenêtre d'opportunité est souvent fermée.

Techniquement, l'Agent a déjà la capacité d'appeler la fonction d'échange, de générer des données d'appel et de transférer des fonds. Cependant, la capacité ne signifie pas permission. Le fait qu'un Agent puisse initier une transaction ne signifie pas qu'il devrait être autorisé à disposer librement des fonds.

Le rôle du Portefeuille Agentique est de séparer les deux : L'Agent peut agir instantanément mais uniquement dans le cadre de règles prédéfinies, telles que limité aux actifs approuvés, soumis à des contraintes budgétaires quotidiennes, contraint par des limites de glissement, et automatiquement mis en pause en cas de conditions de marché anormales. La Compétence 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 : Un Agent de paiement doit dépenser de l'argent mais ne devrait pas avoir le contrôle total sur tous les fonds

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

Le Portefeuille Agentique fournit une autorisation restreinte : Il ne peut effectuer des paiements qu'à des commerçants sur liste blanche, utiliser des actifs spécifiés, exécuter des paiements dans le budget quotidien, et toutes les dépenses sont entièrement enregistrées.

Scénario 3 : Plusieurs Agents ont besoin de permissions isolées sous un budget partagé

Une entité peut faire fonctionner plusieurs Agents simultanément : un pour les transactions, un pour les paiements, un pour les revues. Le portefeuille actuel peut certainement créer plusieurs sous-comptes, mais ce n'est pas une capacité native du portefeuille existant de disposer uniformément des permissions pour ces comptes, de définir un plafond budgétaire global, d'appliquer des contraintes de politique inter-Agent, et de former une piste d'audit unifiée.

Cependant, dans le modèle de Portefeuille Agentique, cela serait traité comme un problème de conception prioritaire : chaque Agent a des permissions indépendantes et clairement définies ; en même temps, une couche de politique unifiée est responsable du contrôle de l'exposition globale au risque, des limites de fréquence inter-Agent et du budget partagé, et de la génération de dossiers d'audit cohérents.

Ces scénarios pointent vers la même conclusion : la gestion des clés privées est toujours la base de la sécurité du portefeuille, permettant aux Agents un accès direct aux clés privées est un risque inacceptable dans n'importe quel scénario. Mais se contenter de gérer des clés privées n'est pas suffisant.

Lorsque les opérateurs passent des humains aux Agents, les portefeuilles doivent également répondre à la deuxième question : qui est autorisé à agir dans quelles conditions, dans quelle mesure, sur quels actifs, envers quelles entités. La gestion des clés privées est la première ligne de défense, et la gestion des permissions des opérateurs non humains est le deuxième pare-feu ajouté à l'ère des Agents.

III. Autonomie Boudée : Philosophie de Conception de Portefeuille Agentique

L'industrie est encore au stade précoce d'exploration des Portefeuilles Agentiques, et il n'existe pas encore de solution de Portefeuille Agentique mature. Cependant, comme mentionné dans la préface, le Portefeuille Agentique envisagé dans cet article est un système de contrôle de fonds qui relie la gouvernance humaine à l'exécution par les Agents : les humains sont responsables de la définition des limites, les Agents sont responsables des actions dans ces limites, et le portefeuille est responsable de garantir que cet ensemble de relations de contraintes est toujours exécutable, auditable et intervenable.

En même temps, selon le niveau d'autorisation accordé aux Agents, un Portefeuille Agentique peut également répondre aux 4 scénarios suivants :

Contrôlé par l'Humain : L'Agent fournit des suggestions et de l'assistance, chaque opération nécessitant toujours une confirmation humaine. L'amélioration réside dans l'efficacité de l'interaction, tandis que la logique de contrôle des fonds reste inchangée.

Hybride : L'Agent gère des opérations de routine telles que la récupération, les devis, les rappels ou l'exécution à faible risque ; la fréquence d'intervention humaine est réduite, mais les cas particuliers nécessitent toujours une approbation humaine, comme les transferts de fonds, les appels de contrats ou les branches anormales.

Autonomie Boudée : L'Agent agit de manière autonome dans des règles explicites, des limites et des voies de veto. Les humains passent de validateurs par transaction à créateurs de règles. Le Portefeuille Agentique discuté dans cet article fait principalement référence à ce type.

Autonomie Totale : L'Agent a une souveraineté économique quasi complète, capable de planifier des fonds de manière autonome et de prendre des décisions sans limites prédéfinies. Ce modèle est théoriquement solide, mais il est encore immature en termes de sécurité, de gouvernance, de responsabilité et de conformité, et se trouve actuellement principalement dans la phase expérimentale.

Pour référence, dans sa lettre annuelle de 2025, Stripe a classé le commerce agentique en cinq niveaux : L1 comme Remplissage de Formulaire (Élimination des formulaires web), L2 comme Recherche Descriptive, L3 comme Persistance, L4 comme Délégation, L5 comme Anticipation ; tout en affirmant sans équivoque que l'industrie dans son ensemble "flotte à la limite de L1 et L2."

Dans cette perspective, la demande actuelle la plus importante sur le marché pourrait provenir de scénarios contrôlés par des humains et hybrides, avec une autonomie limitée étant la véritable frontière et la première forme de production dans laquelle les Agents commencent réellement à gérer des fonds.

La mise en œuvre de ce concept nécessite une architecture en quatre couches :

· Couche de Compte : Établir des conteneurs économiques indépendants et isolés pour chaque Agent, par exemple via EOA, comptes de contrats intelligents, portefeuilles serveur ou environnements TEE. Le système doit appliquer des règles différenciées pour différents Agents.

· Couche de Permission : Définir les limites du comportement des Agents, telles que les limites jetables, les actifs opérables, les contrats interactifs, les fenêtres temporelles exécutables et la logique d'action post-limite. C'est la couche centrale de l'ensemble de l'architecture.

· Couche d'Exécution : Orientée vers les interfaces des Agents plutôt que vers les clics humains. Envoyer, payer, échanger, relier, rééquilibrer, liquider et régler doivent tous être abstraits en tant que primitives pouvant être directement invoquées par des programmes.

· Couche de Gouvernance : Doit fournir des journaux, des simulations, des pistes d'audit, des alertes, un interrupteur de pause, un contournement humain, un mécanisme de récupération, et plus encore. Cette couche détermine si le Portefeuille Agentique peut réellement entrer en production.

Au-dessus de l'Architecture en Quatre Couches, quatre capacités essentielles sont également nécessaires pour soutenir le fonctionnement du système :

Compétences : Fournit des modules d'opération standardisés sur la chaîne. Un Agent peut effectuer des transactions, des paiements, des ponts et d'autres actions comme appeler des fonctions sans avoir à assembler manuellement les données sous-jacentes. Les compétences traitent de la question de l'abstraction des capacités de "ce qui peut être fait".

Politiques + KYA / KYT: Le moteur des Politiques est responsable de la validation des règles pour chaque opération, traduisant les limites définies par l'homme en contraintes exécutables par la machine ; le mécanisme KYA / KYT est utilisé pour identifier l'origine, l'identité, le contexte de risque et l'historique opérationnel de l'Agent. Le premier contraint le comportement, le second identifie l'opérateur, garantissant que toutes les actions de fonds restent toujours dans des limites prédéfinies.

Clé de session: Fournit un mécanisme de délégation sécurisé, limité dans le temps, le montant et le champ d'application. L'Agent reçoit une autorisation temporaire et limitée, pas une clé privée complète. L'autorisation expire automatiquement et l'invalidation ne nécessite pas de révocation manuelle, permettant à l'Agent d'obtenir l'éligibilité à l'exécution sans accéder à la clé complète.

Audit et Notification: Fournit un journal d'opérations entièrement traçable et un système d'alerte en temps réel. Chaque opération est traçable, chaque anomalie est signalable, et chaque Agent peut être mis en pause à tout moment.

Actuellement, nous contrôlons généralement la logique de comportement de l'Agent par des instructions, mais l'orchestration des tâches n'est pas la même que la contrainte des fonds.

Un Agent peut encore mal juger, dévier ou être sujet à des attaques et à une pollution d'entrée malveillante. L'importance de la couche de portefeuille est de prédéfinir les règles du système liées aux permissions de fonds telles que "si les fonds peuvent être utilisés, combien peuvent être utilisés, quels actifs peuvent être opérés, quelles entités peuvent être interagies, et comment avorter dans des circonstances exceptionnelles." Même si un Agent dévie, les actions réelles de fonds qui peuvent se produire restent toujours confinées dans des limites prédéfinies.

IV. Statut du portefeuille Agentique : Quatre chemins et quatre lacunes

Autour des solutions de portefeuille Agentique existantes, nous avons identifié 4 cas typiques qui ont essentiellement abordé "comment intégrer un Agent dans le système financier," mais n'ont pas encore répondu à "comment permettre à un Agent d'utiliser des fonds de manière sécurisée à travers des chaînes et dans un environnement réel complexe."

Coinbase, Safe, Privy et Polygon ont chacun fourni leurs réponses réalisables aux niveaux d'infrastructure, de gouvernance, de permission et d'identité, respectivement. Ce qui reste à faire est d'intégrer davantage ces capacités localisées dans un système de contrôle unifié qui peut fonctionner à travers les chaînes, migrer entre les environnements et rester viable dans des scénarios adverses complexes. Le goulot d'étranglement actuel du portefeuille Agentic réside principalement dans les quatre lacunes suivantes :

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

Un système d'identité et de réputation d'Agent sur la chaîne peut être établi, mais un système de crédit universel interopérable entre les chaînes, les portefeuilles et les environnements opérationnels fait encore défaut. L'historique et la réputation accumulés par un Agent dans un écosystème ne peuvent pas naturellement migrer vers un autre.

Deuxièmement, la couche politique manque de normes unifiées.

Coinbase utilise des limites de dépenses, Safe utilise des modules sur la chaîne, Privy utilise un moteur de politique, et Polygon utilise un portefeuille à portée de session. L'industrie a généralement reconnu que la couche de permission est essentielle, mais une norme de politique unifiée, portable, composable et réutilisable entre produits n'a pas encore été établie.

Troisièmement, la sécurité adversaire est encore très peu développée.

L'injection de prompt, le poison d'outil, les compétences malveillantes, les entrées externes contaminées—ces problèmes ne seront pas automatiquement résolus par des audits de contrat traditionnels. Le véritable nouveau problème introduit à l'ère des Agents est : lorsque le processus de prise de décision d'un modèle est déformé par des entrées malveillantes, comment le portefeuille identifie-t-il, intervient-il et bloque-t-il le risque.

Quatrièmement, la couverture complète de la chaîne est loin d'être atteinte.

Les solutions existantes reposent principalement sur une seule chaîne ou un champ multi-chaînes limité, mais l'activité économique d'un Agent ne restera pas longtemps dans un seul écosystème. Un portefeuille Agentic véritablement mature doit relever les défis des environnements multi-chaînes, multi-exécution et de la cohérence des permissions inter-domaines.

Chapitre Cinq : Sous la Surface - Portefeuille Agentic dans la Prochaine Décennie

Actuellement, l'accent de conception du portefeuille Agentic est de permettre aux humains d'exercer un contrôle précis sur un Agent. Dans la plupart des mises en œuvre, le rôle du portefeuille est plus proche de celui d'un signataire passif : L'Agent appelle une compétence, la compétence génère une transaction, le portefeuille signe en arrière-plan, et l'exécution sur la chaîne suit.

Cependant, si l'Agent commence réellement à gérer des fonds, il est évident que signer à la dernière étape est insuffisant. Une approche plus raisonnable consiste à effectuer des vérifications de permission avant l'exécution : après que l'Agent appelle une Compétence, la demande entre dans le Plan de Politique interne du portefeuille, où l'exécution n'est approuvée qu'après avoir passé la validation des politiques.

Le soi-disant Plan de Politique du Portefeuille s'inspire du concept de Plan de Contrôle et de Plan de Données dans l'architecture des systèmes. Il se situe entre le comportement de l'Agent et l'exécution sur la chaîne, intégrant des moteurs de Politique, des vérifications KYT/KYA, la validation de la Clé de Session, l'évaluation des risques et la gestion des exceptions dans une surface de décision unifiée.

Ce concept n'est pas étranger ; l'architecture de paiement de Stripe suit une logique similaire : les développeurs interagissent avec une API simple, mais avant que les fonds ne soient réellement transférés, Stripe a déjà effectué l'identification des risques, les vérifications des règles et le traitement de la conformité en arrière-plan. L'essence de ce que le Portefeuille Agentique doit faire est similaire : fournir aux développeurs une interface d'exécution claire au niveau supérieur, tout en utilisant un moteur de politique orienté vers l'extérieur au niveau inférieur pour l'adjudication des permissions.

L'urgence réside dans la surface d'attaque en expansion rapide en raison de l'Injection de Prompt, du Poisonnement d'Outils et des Compétences malveillantes, tandis que l'infrastructure de sécurité du côté du portefeuille a pris beaucoup de retard. Un Plan de Politique de Portefeuille standardisé n'est pas encore devenu un primitif fondamental à l'échelle de l'industrie aujourd'hui.

Cependant, le Plan de Politique lui-même ne sera pas l'état final. À mesure que les identités des Agents et les systèmes de réputation mûrissent progressivement, la logique d'autorisation passera d'une approche statique basée sur des règles à une approche dynamique basée sur la confiance. Aujourd'hui, cela repose sur des limites prédéfinies, des contraintes de limites, des listes blanches et des chemins de contournement manuels ; à l'avenir, les enregistrements de transactions sur la chaîne, les trajectoires comportementales et les données de crédit inter-écosystèmes formeront progressivement une base de crédit vérifiable pour les Agents, et davantage de décisions d'autorisation seront basées sur l'identité, l'historique et la performance réelle.

Lorsque les Agents commenceront à interagir économiquement à la vitesse des machines avec d'autres Agents, le mécanisme de contrôle doit être intégré dans le système dès le départ. Le rôle du portefeuille évoluera également : dans les premières étapes, il est un gardien, responsable de la prévention des comportements non autorisés ; à l'étape mature, il devient plus proche de l'infrastructure, responsable de permettre aux entités de confiance de se connecter en continu aux comptes, aux permissions et aux systèmes de règlement avec moins de friction.

Au cours de la dernière décennie, le champ de bataille du portefeuille a été ce point d'entrée sur l'écran. Dans la prochaine décennie, le champ de bataille sera dans la couche de contrôle invisible pour l'utilisateur.

Cet article est un contenu contribué et ne représente pas les vues de BlockBeats.