Fonctionnement des agents IA en crypto : outils et exécution

Les agents IA dans la crypto fonctionnent en exécutant une boucle d'agent qui transforme les invites en requêtes de données structurées onchain, puis achemine toute action proposée à travers des règles de portefeuille programmables avant qu'une transaction puisse être exécutée. La partie utile n'est pas "le bot échange", c'est la frontière de permission entre l'intelligence en lecture seule et l'exécution onchain.

Points clés

• Les agents crypto deviennent utilisables lorsque "l'intelligence" est séparée de "l'exécution" : appels d'outils d'analyse structurée d'un côté, autorisation de compte intelligent de l'autre.
• Le serveur MCP de Dune expose 12 outils via un point de terminaison afin qu'un agent puisse découvrir des tables, générer du DuneSQL, exécuter des requêtes et retourner des résultats consommables par machine sur plus de 100 blockchains.
• Les comptes intelligents sécurisés remplacent les EOAs à clé unique avec des propriétaires plus un seuil, et peuvent être étendus avec des modules et des gardes critiques pour la sécurité qui peuvent également échouer de manière désagréable.
• Le support des chaînes n'est pas uniforme, donc une pile d'agents qui suppose un module ou une fonctionnalité Safe spécifique peut fonctionner sur un réseau et être indisponible sur un autre.

Comment les agents IA s'intègrent dans la crypto

Sur un écran, "les agents dans la crypto" ressemblent généralement à une boîte de discussion qui peut afficher un graphique, résumer des flux et parfois mettre en file d'attente une transaction.

Sous le capot, le modèle mental clair est un pipeline à deux clés : un cerveau en lecture seule qui peut appeler des outils d'analyse structurée, et un ensemble de "mains" qui ne peuvent bouger que lorsque les règles d'un compte intelligent le permettent. Ce cadre répond à la question de ce que sont les agents IA dans la crypto sans prétendre que l'agent est un portefeuille magique avec des opinions.

Le mécanisme sur lequel la plupart des équipes convergent est la boucle agent percevoir décider agir, car il s'aligne parfaitement sur la séparation entre données et exécution dans la crypto. La perception n'est pas "regarder la chaîne" au sens humain. Ce sont des appels d'outils qui retournent des sorties structurées. La décision est l'étape d'inférence du modèle sur ces sorties plus toute politique que vous encodez.

L'action est soit une proposition de transaction, soit une exécution onchain réelle, selon la manière dont la frontière d'autorisation est conçue.

Cette frontière est là où la crypto diffère de l'automatisation générique. Un agent SaaS normal peut se voir donner un clé API et limites de taux. Un agent AI crypto qui peut signer est à un mauvais prompt de devenir un événement de perte.

Donc, l'architecture qui tient est : (1) donner à l'agent des lectures fiables et appelables par machine, et (2) lui donner une exécution contrainte à travers un compte intelligent qui force des approbations explicites, des limites, ou les deux.

C'est aussi là que le « flux de travail agentique » cesse d'être un mot à la mode. Le flux de travail est une chaîne reproductible d'appels d'outils, de résultats et d'intentions de transaction, avec un point clair où un seuil de sécurité ou un garde peut dire « non ».

Accès des outils aux données onchain

Le serveur MCP de Dune est un exemple concret de la façon dont les agents AI fonctionnent lorsqu'ils ne grattent pas des tableaux de bord. Il expose 12 outils à travers un seul point de terminaison afin qu'un agent compatible MCP puisse découvrir des tables, écrire du DuneSQL, exécuter des requêtes, récupérer des résultats et générer des visualisations contre l'entrepôt de Dune à travers plus de 100 blockchains indexées.

Cela compte parce que l'agent ne devine plus les noms de table ni ne s'appuie sur des captures d'écran. Il appelle des fonctions qui renvoient des résultats structurés.

La séquence est simple, et c'est la partie que la plupart des explications « les agents lisent des données et échangent » omettent :

1. L'agent recherche dans le catalogue de Dune des ensembles de données pertinents et des tables de contrats décodées. 2. Il génère du DuneSQL à partir du prompt, puis exécute la requête via l'interface de l'outil. 3. Il récupère les résultats dans un format consommable par machine et peut rendre une visualisation si nécessaire.

La CLI de Dune pousse la même idée dans l'automatisation native du terminal. La CLI est conçue pour les flux de travail des agents et couvre la découverte d'ensembles de données, l'écriture et l'exécution de DuneSQL, la gestion des requêtes, la recherche de documents et le suivi de l'utilisation.

Chaque commande produit du JSON pour la consommation par machine, et elle est livrée avec un fichier Skills.md qui suit une norme de compétences des agents afin qu'un agent puisse apprendre des capacités et la gestion des erreurs sans intégration sur mesure.

C'est la réalité de l'« architecture d'agent AI crypto » : le cadre de l'agent n'est aussi bon que les outils qu'il peut appeler. Si la couche d'outils renvoie des sorties SQL et JSON reproductibles, l'agent peut être audité et relancé. Si la couche d'outils est un tableau de bord et une ambiance, l'agent improvise simplement.

Comptes intelligents comme couche d'exécution des agents

L'exécution est l'endroit où les agents crypto deviennent soit suffisamment sûrs à utiliser, soit suffisamment dangereux à éviter. L'erreur courante est de donner une EOA à l'automatisation. Les EOA sont contrôlées par un seulclé privée, et si quelqu'un obtient cette clé, il obtient un contrôle total.

C'est un modèle de sécurité clair pour un humain avec unportefeuille matérielC'est un modèle fragile pour des logiciels qui fonctionnent sans surveillance.

Les Comptes Intelligents changent le modèle d'autorisation. Ils peuvent recevoir des fonds et effectuer des transactions comme des EOA, mais ils ne peuvent pas les initier. Leur logique de vérification et d'exécution est définie parcontrat intelligentcode plutôt qu'une seule clé privée. Ce détail est la raison pour laquelle les comptes intelligents sont la couche naturelle de "portefeuille d'agent". Le compte lui-même devient un moteur de politique.

Le Safe Smart Account est la mise en œuvre la plus connue de cette idée. C'est un Smart Account avec une multisignature au cœur : un ensemble de propriétaires et un seuil de confirmations requis avant l'exécution. Les propriétaires peuvent être des EOAs, d'autres comptes de contrats intelligents, ou même une clé d'accès.

Pour un agent, cela signifie que la posture par défaut peut être « l'agent prépare, un humain co-signe », et le système utilise toujours le même onchain.adresse et comptabilité.

L'architecture de Safe est également importante pour le déploiement et les opérations. Les Safe Smart Accounts sont déployés en utilisant un modèle de proxy où un Safe Proxy délègue les appels à un contrat Safe singleton, ce qui réduit le coût de déploiement. La Safe Proxy Factory peut créer un proxy et exécuter la configuration en une seule transaction. Rien de tout cela n'est de l'« IA », mais c'est la plomberie qui rend l'automatisation contrôlée réalisable.

Contrôles programmables pour une automatisation plus sûre

Les surfaces de contrôle qui font réellement fonctionner l'automatisation se trouvent à l'intérieur de Safe, pas à l'intérieur du modèle. Le seuil multi-sig de Safe est l'instrument brut. Les modules et les gardes sont les scalpels, et Safe les marque comme critiques pour la sécurité pour une raison.

Les modules étendent ce qu'un Safe peut faire en permettant des modèles d'accès alternatifs et des permissions granulaires. La documentation de Safe cite des exemples comme les limites de dépenses et les flux de récupération, et il est explicite qu'un Safe de base ne nécessite aucun module.

Ajouter ou supprimer un module nécessite une confirmation par le seuil du propriétaire, et les modules doivent être aussi sécurisés que le reste des contrats Safe car ils peuvent étendre ce qui est exécutable.

Les gardes sont un levier différent. Un garde peut accepter ou rejeter des transactions en fonction de la logique de garde. Safe avertit également que les gardes sont critiques pour la sécurité et qu'un garde malveillant pourrait empêcher l'exécution des transactions et bloquer l'accès aux fonds stockés dans le Safe. C'est le mode de défaillance que les gens oublient lorsqu'ils traitent les gardes comme une « sécurité supplémentaire ». Un garde est un contrat de gardien.

Safe prend également en charge les transactions sponsorisées et le paiement basé sur des tokens gas via un service de relais qui accepte les tokens ERC20 pris en charge et soumet des transactions tout en payant le gas en ETH. Le même chemin de relais peut être utilisé pour des flux sans éther où un tiers paie les frais au nom d'un Safe. Pour les systèmes d'agents, il s'agit moins de commodité et plus de conception opérationnelle.

Si l'agent est censé soumettre des transactions, les hypothèses de gaz et de relais font partie de la frontière de permission.

C'est ici que le « crypto boucle agent » devient concret : la perception et l'inférence peuvent être rapides et bon marché, mais l'action est une transaction qui doit passer des vérifications de seuil, des permissions de module et une logique de garde avant d'atteindre la chaîne.

Considérations de déploiement et de support réseau

Beaucoup de conceptions d'agents échouent pour une raison ennuyeuse : la pile est supposée être uniforme à travers les chaînes. Safe publie une liste de réseaux pris en charge qui montre les versions de Smart Account et la disponibilité des fonctionnalités ou des modules par chaîne, y compris des modules comme Safe 4337, Safe Passkey et Safe Recovery.

La page est effectivement une matrice de compatibilité, et cela compte parce que « nous allons juste utiliser le module X » n'est pas un plan si la chaîne cible ne le prend pas en charge.

Même au sein de l'écosystème Safe, les versions diffèrent selon le réseau. La liste des réseaux pris en charge montre plusieurs versions de Smart Account (par exemple v1.5.0, v1.4.1, v1.3.0 et plus anciennes) et indique ensuite quels services et modules sont disponibles sur chaque chaîne. C'est le genre de détail qui décide si un flux de travail agentique peut être déployé tel que conçu ou nécessite une posture d'exécution différente.

C'est aussi là que les deux moitiés du pipeline doivent être vérifiées séparément. Le post MCP de Dune décrit l'accès à plus de 100 blockchains, tandis que le post CLI natif agent de Dune décrit l'accès à plus de 130 chaînes. Cette discordance n'est pas un problème en soi, mais c'est un rappel de traiter la « couverture de chaîne » comme un élément à vérifier, pas comme un texte marketing.

Une liste de contrôle opérationnelle minimale émerge :

1. Confirmer que la couche de données couvre la chaîne cible et les tables de protocole spécifiques nécessaires pour l'étape de perception de l'agent. 2. Confirmer que la couche d'exécution prend en charge la version Safe et les modules ou fonctionnalités spécifiques dont dépend la politique. 3. Ce n'est qu'alors qu'il faut concevoir le pont entre eux, car le pont est l'endroit où résident les permissions et les modes de défaillance.

Limites et risques ouverts à surveiller

Les sources décrivent des blocs de construction puissants, mais elles ne fournissent pas une seule architecture de référence de bout en bout pour un agent autonome qui analyse et exécute. Cet écart est important car l'autonomie n'est pas un interrupteur. C'est un spectre, et le point sûr sur ce spectre dépend de l'autorité que la couche d'exécution accorde.

Deux limites apparaissent immédiatement. Premièrement, l'accès aux outils n'est aussi bon que sa structure. Le MCP et le CLI de Dune sont conçus pour renvoyer des résultats consommables par machine, ce qui est la bonne direction, mais les sources ne quantifient pas la fiabilité, les taux d'erreur, ou la fréquence à laquelle les agents génèrent des requêtes incorrectes qui renvoient tout de même des résultats plausibles.

Deuxièmement, les points d'extension de Safe sont explicitement critiques pour la sécurité. Les modules peuvent élargir les permissions d'exécution, et les gardes peuvent bloquer complètement l'exécution. Ce ne sont pas des risques abstraits. Ce sont des contraintes de conception.

Il existe également une limite de gouvernance et d'opérations qui est ignorée dans les cycles de hype. Si un agent dépend d'un module, d'un garde ou d'un chemin de relais particulier, alors les changements de politique, les mises à niveau ou les lacunes de support spécifiques à la chaîne deviennent partie intégrante de la surface de risque de l'agent.

La matrice des réseaux pris en charge par Safe existe parce que la disponibilité des fonctionnalités n'est pas uniforme.

Enfin, la conversation sur le "TEE" a tendance à être brandie comme une panacée. Un tee peut aider à isoler des secrets et à attester l'exécution de code, mais il ne remplace pas le besoin d'une frontière de permission pour un compte intelligent. Même avec une garde des clés plus forte, l'erreur coûteuse reste de donner à un logiciel un point de défaillance unique et une autorité illimitée.

Les agents crypto deviennent réels parce que la plomberie devient réelle. La partie difficile reste la même : séparer l'intelligence de l'exécution, puis contraindre le pont afin que le système puisse être digne de confiance avec du capital.

La prise

J'ai vu des équipes s'obséder sur le choix des modèles et ignorer la partie qui décide réellement si un agent est utilisable : la frontière d'autorisation. Au moment où un agent peut proposer et exécuter à partir d'un EOA à clé unique, tout le système hérite du pire modèle de sécurité possible pour l'automatisation. Une clé divulguée, un hôte compromis, une mauvaise intégration, et c'est fini.

Ce que j'ai vu tenir, c'est de traiter les outils structurés de style Dune comme le cerveau en lecture seule, puis de forcer l'exécution à travers un seuil Safe jusqu'à ce que le flux de travail prouve sa valeur. Les modules et les gardes sont là où l'automatisation devient réelle, et Safe est explicite sur le fait qu'ils sont critiques pour la sécurité.

C'est la posture qui empêche les "agents en crypto" de se transformer en une interface sophistiquée pour signer des erreurs.

Sources

• Dune
• Dune
• Documents Sécurisés
• Documents Sécurisés