WAIaaS apporte 684 tests à l'infrastructure de portefeuille IA auto-hébergée

Le projet WAIaaS a publié une infrastructure Wallet-as-a-Service (portefeuille en tant que service) open-source et auto-hébergée, conçue spécifiquement pour les agents IA et soutenue par une suite de plus de 684 fichiers de test. Publiée le 28 septembre 2026, cette infrastructure permet aux développeurs d'exécuter les opérations de portefeuille localement via Docker, garantissant que les clés privées ne quittent jamais leur propre matériel. La version met l'accent sur l'application stricte des politiques et des tests exhaustifs pour atténuer les risques financiers associés aux transactions automatisées par agent.

Ce qui s'est passé

WAIaaS est un monorepo de 15 packages qui fournit une infrastructure de portefeuille complète pour les agents IA sans dépendre de la garde par des tiers. Le cœur du système est un démon qui s'exécute dans un seul conteneur Docker, se liant par défaut à localhost pour empêcher toute exposition externe. Cette configuration inclut la prise en charge de l'approvisionnement automatique, de Docker Secrets pour la gestion sécurisée des identifiants et des mises à jour automatiques via Watchtower. Le projet vise à éliminer les frictions généralement associées à l'auto-hébergement d'infrastructures crypto en offrant un processus de démarrage rapide nécessitant seulement trois commandes pour cloner le dépôt et lancer le service.

L'architecture logicielle sépare les préoccupations grâce à un pipeline de transaction en sept étapes : validate, auth, policy, wait, execute et confirm. Chaque étape est couverte par la vaste suite de tests du projet, qui s'étend aux packages pour les actions, les adaptateurs, les interfaces d'administration, les outils en ligne de commande et les kits de développement logiciel (SDK). Le démon expose 39 modules de routes API REST qui gèrent la création de portefeuilles, la gestion des sessions, les actions de finance décentralisée (DeFi) et les transferts de jetons non fongibles (NFT). En exécutant cette pile localement, les utilisateurs conservent un contrôle total sur leurs clés et évitent les limites de débit ou l'opacité des services hébergés.

La sécurité est appliquée via un modèle d'authentification à trois couches et un moteur de politique robuste. Le système utilise l'authentification maître pour les opérations de haut niveau, l'authentification propriétaire pour l'approbation humaine et l'authentification de session pour l'agent IA lui-même. Cette séparation garantit qu'une session d'agent compromise ne peut pas modifier les politiques fondamentales ni créer de nouveaux portefeuilles. Le moteur de politique prend en charge 21 types de politiques différents répartis sur quatre niveaux de sécurité, permettant aux utilisateurs de définir des limites de dépenses strictes, des seuils de délai et des exigences d'approbation pour divers types de transactions.

Détails clés

• Le projet comprend plus de 684 fichiers de test répartis sur 15 packages pour garantir la fiabilité des opérations financières.
• Le démon s'exécute en tant qu'utilisateur non-root avec l'UID 1001 et se lie par défaut à 127.0.0.1:3100.
• Les transactions passent par un pipeline en sept étapes incluant la validation, les vérifications de politique et la confirmation d'exécution.
• Trois méthodes d'authentification sont prises en charge : masterAuth pour les opérations système, ownerAuth pour l'approbation humaine et sessionAuth pour les agents.
• Le moteur de politique présente 21 types de politiques avec des niveaux de sécurité instant, notify, delay et approval.
• L'intégration avec les agents IA est facilitée via des serveurs Model Context Protocol et des SDK TypeScript ou Python.

Contexte

L'auto-hébergement d'une infrastructure de portefeuille a historiquement été complexe, nécessitant souvent une charge opérationnelle significative similaire à celle de la gestion d'un serveur de messagerie privé. La plupart des développeurs dépendaient auparavant de services hébergés pour des raisons de commodité, acceptant les risques liés à la garde et au verrouillage potentiel par le fournisseur. WAIaaS répond à ce problème en conteneurisant l'ensemble du service de portefeuille, le rendant accessible aux équipes ayant des connaissances de base en Docker. L'utilisation de Docker Secrets et de l'approvisionnement automatique simplifie davantage le déploiement sécurisé sur des serveurs privés virtuels (VPS) ou des environnements homelab.

Le Model Context Protocol (MCP) est une norme qui permet aux assistants IA de se connecter à des données et des outils locaux. En fournissant un serveur MCP, WAIaaS permet aux agents IA comme Claude Desktop d'interagir directement avec le démon de portefeuille local. Cela signifie que l'agent peut interroger les soldes ou proposer des transactions sans envoyer de données sensibles à des API externes. La fonctionnalité dry-run (simulation) permet aux utilisateurs de simuler des transactions contre le moteur de politique local avant de les exécuter sur la blockchain, offrant ainsi un filet de sécurité pour les actions automatisées.

Pourquoi c'est important

Pour les équipes qui déploient des agents IA gérant des actifs financiers, le risque de bugs n'est pas simplement théorique mais directement lié à des pertes monétaires. Une erreur d'indexage (off-by-one) dans une limite de dépenses ou une condition de concurrence (race condition) dans l'exécution des transactions peut entraîner un drainage irréversible des fonds. Les plus de 684 fichiers de test de WAIaaS servent de signal d'auditabilité, permettant aux ingénieurs de vérifier que le code se comporte comme prévu avant son déploiement. Ce niveau de transparence est crucial pour les organisations qui exigent une certitude quant à la manière dont leur logiciel gère les clés privées et les approbations de transactions.

La posture « default-deny » (refus par défaut) du moteur de politique garantit que les transactions sont bloquées sauf si elles sont explicitement autorisées par des règles configurées. Cette approche fail-closed (échec sécurisé) est essentielle pour les agents autonomes qui pourraient autrement exécuter des actions involontaires. En définissant des limites spécifiques pour le levier des contrats à perpétuité, les positions de prêt ou les transferts de jetons, les équipes peuvent contraindre le comportement de leur agent dans des limites sûres. La capacité de simuler ces politiques localement avant l'exécution en direct ajoute une couche de confiance souvent absente des solutions hébergées.

De plus, la séparation des couches d'authentification protège le système contre les compromissions partielles. Si le jeton de session d'un agent IA est exposé, l'attaquant ne peut pas modifier les politiques à l'échelle du système ni créer de nouveaux portefeuilles, car ces actions nécessitent une authentification maître. De même, le propriétaire peut intervenir via une approbation basée sur signature même si d'autres identifiants sont compromis. Cette stratégie de défense en profondeur est vitale pour maintenir la souveraineté sur les actifs numériques dans un environnement automatisé.

Ce que vous pouvez faire

• Clonez le dépôt WAIaaS et démarrez le démon en utilisant Docker Compose pour évaluer la configuration locale.
• Configurez des politiques de limites de dépenses avec les niveaux instant, notify et delay pour contrôler la taille des transactions de l'agent.
• Utilisez le dry-run pour simuler des transactions contre le moteur de politique local avant de les exécuter sur la blockchain.
• Intégrez le serveur MCP avec votre framework d'agent IA pour permettre des interactions locales sécurisées.
• Revoyez les fichiers de test pour comprendre comment les différentes couches de sécurité sont validées.