Agents IA sur Solana : autonomie sécurisée avec Arc 14
Un agent IA capable de déplacer des jetons ressemble à un superpouvoir… jusqu’à ce qu’il les déplace par erreur. Plutôt que de laisser un modèle de langage signer n’importe quoi, Arc 14 a instauré une limite : le modèle décide de l’action, mais le code détermine ce qu’il est autorisé à faire. Sur sept jours, l’équipe a doté un agent d’outils en lecture seule, puis d’un portefeuille devnet, d’un serveur MCP, d’un moteur de politiques et d’un flux de travail autonome—tout en conservant les clés privées dans l’application, jamais dans le contexte du modèle.
De la lecture seule à la lecture-écriture
La première étape consistait à minimiser les risques. L’agent utilisait une boucle légère avec Claude et des outils Solana devnet, capables de répondre à des questions en anglais simple : solde d’un portefeuille, propriétaire d’un compte, exécution d’un compte, quantité de données stockées. Le modèle ne dialoguait pas directement avec Solana ; il sélectionnait parmi une liste d’outils prédéfinis par l’application. Quand l’utilisateur demandait « Combien de SOL ? », l’agent choisissait l’outil de solde, l’application appelait l’endpoint RPC, le résultat revenait, et le modèle expliquait—le tout dans une boucle contrôlée : objectif utilisateur, choix de l’outil par le modèle, validation et exécution par l’application, explication par le modèle.
Les définitions d’outils comme garde-fous
Chaque outil comportait quatre éléments : une description guidant le modèle, un schéma d’entrée limitant ses demandes, une implémentation appliquant les frontières, et une sortie exploitable par le modèle. Une description floue pouvait orienter le modèle vers le mauvais outil ; un schéma trop permissif laissait passer des requêtes malformées ; une implémentation laxiste transformait une erreur du modèle en problème système. Même pour les outils en lecture seule, les limites comptaient : un outil de solde devait accepter uniquement des adresses Solana valides, un outil d’inspection de compte devait retourner des métadonnées structurées, et les erreurs devaient révéler des détails utiles sans masquer leur cause initiale.
Un portefeuille sous contrôle
Au 93e jour, l’agent a reçu son propre portefeuille devnet et deux nouvelles capacités—vérifier un solde et envoyer des SOL—passant d’un assistant en lecture seule à un système capable de modifier l’état on-chain. Le portefeuille résidait dans le processus de l’application ; sa clé privée ne pénétrait jamais le contexte du modèle, ni dans les requêtes, ni dans les résultats des outils. Le modèle n’avait besoin que d’un outil acceptant un destinataire et un montant, laissant à l’application le soin de signer la transaction en toute sécurité.
Pourquoi c’est important
Il ne s’agit pas seulement d’une démonstration technique ; cela montre une méthode reproductible pour offrir aux agents IA une autonomie utile sur les chaînes publiques sans renoncer à la garde des actifs. Les enjeux sont réels : une transaction mal signée peut vider un portefeuille, et une fois que le code confie une clé à un modèle, révoquer la confiance devient difficile. Le modèle d’Arc 14—le modèle prend les décisions, le code impose les limites—offre un modèle pour une automatisation on-chain plus sûre, applicable aux portefeuilles, aux DAO et aux protocoles DeFi.
Source : DEV Community. Synthèse éditoriale assistée par IA — TechnoExpress.