Tether WDK : les agents IA contrôlent les wallets USDT

Le PDG de Tether, Paolo Ardoino, a présenté le WDK, le Wallet Development Kit de la société, comme de l'argent programmable pour les humains, les machines et les agents IA lors de son lancement le 11 novembre 2024. La démonstration du 3 septembre du WDK CLI rend cette vision concrète : un portefeuille local en ligne de commande qui transmet une session déverrouillée à un daemon, qu'un autre processus exécuté sous le même utilisateur du système d'exploitation peut solliciter pour obtenir des signatures sans ressaisir la phrase de passe. Les sessions durent par défaut cinq minutes ; le verrouillage peut être prolongé, raccourci ou désactivé totalement.

Pourquoi c'est important

Le CLI est livré avec trois composants : des commandes terminal, le daemon en arrière-plan, et un serveur Model Context Protocol intégré qui permet à un client IA d'appeler des outils structurés sur le même portefeuille local. Les seeds verrouillés sont protégés par AES-256-GCM avec une clé dérivée via scrypt. Une fois déverrouillée, la socket du daemon est restreinte à l'utilisateur du système d'exploitation sous macOS et Linux, mais aucun identifiant distinct ne contrôle chaque programme. L'interface MCP exclut de son menu d'outils la création de portefeuille, l'export de seed et le déverrouillage, ce qui limite ce qu'un agent peut demander via ce chemin ; les transferts s'exécutent par défaut en dry run avec une séquence d'aperçu puis de confirmation, même si le daemon n'exige pas la preuve que ces étapes ont eu lieu avant d'exécuter une requête valide.

La propre répartition des usages de Tether situe le CLI dans les flux d'opérateur local, le SDK dans les applications et le MCP Toolkit dans les serveurs d'agents personnalisés. Une seconde route sur le serveur MCP intégré, call_method, peut invoquer des opérations d'écriture déclarées spécifiques à une chaîne sans dry run ni confirmation imposée, ce qui rend l'emplacement de toute vérification d'approbation déterminant : un prompt rigoureux ne sert à rien si le portefeuille sous-jacent accepte encore des requêtes via un autre chemin autorisé.

Impact sur le marché

Le SDK expose des politiques locales de transaction ALLOW et DENY qui peuvent bloquer les appels régulés, mais ce mécanisme est opt-in et présente des lacunes documentées, notamment les références brutes de compte et certains appels internes de module qui restent hors de son interception. La documentation précise que le SDK ne gère pas de listes de destinataires, ne récupère pas de prix, ne décode pas les données d'appel de contrat et ne persiste pas de compteurs de dépenses. Un budget quotidien illustre la conséquence : vérifier la taille d'un paiement ne permet pas de savoir combien un agent a déjà dépensé ce jour-là, donc tout plafond cumulé nécessite une comptabilité au niveau de l'application en complément des vérifications par paiement. Les outils d'écriture intégrés du MCP Toolkit, encore en beta.1, utilisent les elicitations MCP pour obtenir une approbation explicite de l'utilisateur avant diffusion, et permettent aux développeurs d'exposer des outils en lecture seule ou d'ajouter les leurs.