Les agents d’IA crypto ont besoin d’un nouveau type de calcul. Voici pourquoi Acurast compte.

 

Les agents d’IA vont au-delà de la conversation. Les agents d’IA crypto peuvent détenir des wallets, appeler des smart contracts, payer des services et exécuter des tâches on-chain sans qu’un humain approuve chaque étape.

 

Des infrastructures comme x402 permettent aux agents de payer des API en stablecoins. Les wallets agentiques leur donnent la possibilité de dépenser dans les limites fixées par leurs propriétaires.

 

Mais l’autonomie s’accompagne aussi de nouveaux enjeux de sécurité.

 

Un chatbot qui laisse fuiter l’historique de ses conversations pose un problème de confidentialité. Un agent crypto autonome qui laisse fuiter ses identifiants, ou qui exécute du code secrètement modifié par quelqu’un, peut provoquer un incident de sécurité aux conséquences on-chain bien réelles.

 

Pourtant, de nombreux agents tournent encore sur des ordinateurs portables, des instances VPS classiques ou une infrastructure cloud centralisée. Ces environnements peuvent être pratiques, mais ils soulèvent des questions importantes : qui peut accéder à l’environnement d’exécution d’un agent ? Comment vérifier quel code s’exécute réellement ? Et que se passe-t-il lorsqu’un fournisseur unique tombe en panne ou décide de couper le service ?

 

Les agents crypto ont besoin de plus que du calcul. Il leur faut une exécution confidentielle, une infrastructure vérifiable et un moyen d’accéder au calcul sans dépendre d’un fournisseur unique.

 

Acurast propose une approche différente : un réseau de calcul distribué qui s’appuie sur la sécurité matérielle des smartphones.

Cinq exigences pour un calcul natif crypto

 

Un agent autonome attend cinq propriétés essentielles de son environnement d’exécution.

Ces exigences ne sont pas propres à la crypto. Mais lorsqu’un logiciel peut contrôler un wallet ou déclencher des actions on-chain, les conséquences d’une erreur deviennent beaucoup plus lourdes.

 

Pourquoi l’infrastructure cloud classique laisse des failles

 

Les plateformes cloud centralisées offrent des outils familiers, une infrastructure fiable et un déploiement simple. Le problème n’est pas qu’elles soient intrinsèquement peu sûres. C’est que leur modèle de confiance ne correspond pas forcément aux besoins de logiciels autonomes dotés d’un wallet.

 

• Le fournisseur reste dans le périmètre de confiance. Sans protections matérielles supplémentaires, les opérateurs d’infrastructure disposant de privilèges peuvent être en mesure d’inspecter la mémoire, le stockage ou la configuration d’une charge de travail. Pour un agent, ces surfaces peuvent contenir du contexte sensible et des identifiants.
• Vérifier l’environnement d’exécution peut être difficile. Lorsqu’un agent tourne sur l’infrastructure de quelqu’un d’autre, les utilisateurs ont besoin d’un moyen d’établir dans quel environnement il s’exécute et si la charge de travail déployée correspond à ce qu’ils attendent. Une simple description du déploiement ne constitue pas une preuve indépendante de l’exécution.
• L’infrastructure peut devenir un point de défaillance unique. Une panne, une suspension de compte ou un changement de politique chez un fournisseur peut interrompre tous les agents qui en dépendent.
• Le provisionnement traditionnel suppose un opérateur humain. Les comptes cloud, la facturation et les identifiants d’accès sont conçus pour des personnes ou des organisations. Un agent autonome qui possède déjà un wallet a besoin d’un moyen plus programmatique de demander du calcul.

 

L’ensemble du secteur évolue vers des environnements de calcul dédiés aux agents. Muse de Meta et Dots d’OpenAI illustrent cette tendance.

 

Mais pour les agents natifs crypto, la question va au-delà du simple fait de donner à chaque agent son propre ordinateur.

Acurast : un calcul bâti sur le matériel des smartphones

 

Acurast transforme les smartphones en réseau de calcul distribué. Au lieu de s’appuyer sur des centres de données centralisés, Acurast coordonne un réseau de téléphones (les Processors) répartis dans le monde entier.

 

Son approche répond de différentes manières aux cinq exigences.

 

1. Une confidentialité adossée au matériel

 

Acurast exécute les déploiements dans des Trusted Execution Environments (TEEs), des environnements d’exécution de confiance adossés au matériel.

 

Un TEE fournit un environnement d’exécution isolé, conçu pour protéger les données sensibles et les calculs du reste du système. La frontière de confidentialité est ainsi plus solide que si l’on s’en remettait aux seules permissions logicielles ordinaires.

 

Les variables d’environnement d’un déploiement peuvent fournir des secrets à une charge de travail au moment de l’exécution, en les maintenant dans le périmètre d’exécution prévu.

 

Pour les agents crypto, cela concerne en particulier les identifiants d’API, le contexte privé et les autres éléments de configuration sensibles. L’objectif est de réduire la confiance que les utilisateurs doivent accorder au propriétaire du téléphone ou à l’opérateur de l’infrastructure.

 

Comme pour toute architecture de sécurité, la protection réelle dépend du matériel, de l’implémentation et de la configuration du déploiement.

 

2. L’attestation matérielle

 

La confidentialité détermine qui peut accéder à une charge de travail. L’attestation aide à établir sur quel type de matériel elle s’exécute.

 

Avant qu’une charge de travail soit attribuée, Acurast utilise l’attestation matérielle pour vérifier les téléphones éligibles. Cela permet de distinguer le matériel authentique et pris en charge des téléphones qui échouent aux contrôles du réseau.

 

Associée au processus de déploiement, l’attestation fournit une base pour vérifier l’infrastructure et les conditions préalables à l’exécution, plutôt que de s’en remettre uniquement aux assurances d’un opérateur.

 

Pour les agents autonomes, cette distinction compte : les affirmations en matière de sécurité doivent reposer, autant que possible, sur des preuves vérifiables.

 

3. Une infrastructure distribuée

 

Acurast coordonne des Processors sur un réseau de téléphones exploités par différents propriétaires.

 

Le calcul est ainsi réparti au-delà d’un seul fournisseur d’infrastructure classique. Cela peut réduire la dépendance envers les machines et les décisions opérationnelles d’une seule entreprise, même si la résilience d’un déploiement donné dépend toujours de sa configuration et de la capacité disponible sur le réseau.

 

Pour les agents qui surveillent des protocoles ou effectuent des tâches d’infrastructure récurrentes, réduire la dépendance envers un hébergeur unique est un véritable atout d’architecture.

 

4. Des charges de travail existantes, sans tout réécrire

 

Avec Cargo, les développeurs peuvent déployer toute une gamme de charges de travail Linux, notamment en Python, Go, Rust et C++, ainsi que des scripts shell et des binaires.

 

Les développeurs peuvent utiliser des outils familiers, consulter les logs via SSH et adapter des frameworks d’agents existants, plutôt que de reconstruire entièrement leurs applications autour d’un environnement d’exécution propriétaire.

 

Cargo prend en charge les charges de travail Linux sur les téléphones Android Processor Core, tandis que les Processors iOS continuent de prendre en charge les charges de travail JavaScript.

 

Acurast intéresse donc non seulement les développeurs qui créent de nouveaux agents, mais aussi les équipes qui souhaitent migrer des charges de travail existantes vers une autre architecture de calcul.

 

5. Un accès au calcul par wallet

 

Avec l’Acurast Deploy Agent, un agent peut demander du calcul via une interface HTTP et payer en USDC sur Base grâce à x402.

 

Selon la demande, il peut obtenir le déploiement d’une tâche ou demander un VPS. Une demande de VPS peut renvoyer un environnement Ubuntu public, accessible en SSH, qui tourne sur un Processor.

 

Une demande de VPS fonctionne sans compte Acurast classique, sans CLI locale et sans tokens ACU.

 

C’est une brique utile pour les systèmes agentiques : un logiciel peut demander l’infrastructure dont il a besoin, exécuter une tâche puis laisser le déploiement expirer, dans le respect de la durée configurée et des limites de dépense.

 

Il en résulte un modèle de calcul qui s’intègre naturellement aux logiciels dotés d’un wallet.

 

Trois façons de faire tourner des agents d’IA crypto sur Acurast

 

Les capacités du réseau se traduisent par trois modèles de déploiement concrets.

 

1. Faire tourner l’agent entier sur un Processor

 

Pour les charges de travail qui exigent une exécution continue et l’accès à une configuration sensible, l’agent entier peut tourner dans un TEE sur un Processor Acurast.

 

Deux exemples disposent déjà d’applications Cargo dans le dépôt des exemples d’applications Acurast :

 

Hermes : un agent autonome doté de planification, de mémoire et d’outils.

 

OpenClaw : un assistant personnel capable d’effectuer des tâches planifiées et en plusieurs étapes.

 

Les développeurs peuvent configurer l’environnement dans .env, définir la durée du déploiement dans acurast.json, puis déployer avec acurast deploy. L’URL de l’agent ainsi créé est envoyée à un endpoint de callback configuré.

 

Pour les équipes qui ont leur propre agent, les modèles Cargo offrent un point de départ pour intégrer un framework existant dans l’environnement.

 

Idéal pour : les agents planifiés, la surveillance de protocoles, la maintenance récurrente et les charges de travail qui tirent parti d’une confidentialité adossée au matériel.

 

2. Garder le raisonnement de l’agent privé

 

Un agent peut protéger ses identifiants d’exécution et exposer malgré tout du contexte sensible s’il envoie chaque prompt à l’API d’un modèle tiers.

 

Selon la charge de travail, Acurast propose deux approches pour exécuter l’inférence dans un TEE.

 

Faire tourner un modèle directement sur un Processor. Le module LLM d’Acurast prend en charge de nombreux modèles GGUF de Hugging Face. Cela peut convenir à des tâches d’inférence légères comme la classification, l’extraction et la synthèse.

 

Faire tourner une passerelle d’IA. Lors d’une première expérience impliquant Pocket Network et NodeGhost, une passerelle compatible OpenAI a tourné sous forme de déploiement Cargo et a traité en alternance des requêtes d’inférence et de recherche web pendant une heure, sans aucune requête perdue.

 

L’expérience de la passerelle reste exploratoire et ne présume pas des performances à l’échelle de la production. Elle montre néanmoins qu’il est envisageable de faire tourner un workflow d’inférence plus complet sur du calcul basé sur des smartphones.

 

Idéal pour : les agents qui traitent des documents confidentiels, de la recherche interne, des données opérationnelles privées ou des prompts que les équipes ne veulent pas envoyer systématiquement à des fournisseurs d’inférence tiers.

 

3. Laisser l’agent provisionner son propre calcul

 

Un agent n’a pas forcément besoin d’un serveur permanent ni d’un humain pour gérer chaque déploiement.

 

Avec le Deploy Agent, un agent peut envoyer une requête HTTP comprenant un paiement x402 en USDC sur Base et une spécification de tâche ou une demande de VPS.

 

Par exemple, un agent pourrait demander un environnement de calcul pour effectuer une tâche d’infrastructure planifiée, se connecter en SSH à la machine Ubuntu renvoyée, mener la tâche à bien et laisser le déploiement expirer.

 

Ce workflow ne nécessite ni compte Acurast classique ni CLI locale.

 

Associé à un wallet agentique et à une limite de dépense explicite, ce mécanisme offre une base concrète pour le provisionnement programmatique de calcul.

 

Idéal pour : les charges de travail temporaires, la maintenance automatisée, les environnements dédiés à une tâche et les agents qui doivent obtenir du calcul à la demande.

 

Cinq cas d’usage pour les agents crypto

 

Les applications les plus pertinentes sont celles où le fonctionnement continu, l’exécution confidentielle et une infrastructure vérifiable apportent une valeur concrète.

Ce sont des cas d’usage d’infrastructure, et non l’assurance que les décisions ou les résultats d’un agent seront toujours justes. La logique applicative, les sources de données, les permissions et les garde-fous opérationnels restent déterminants.

 

Plus largement, les agents peuvent être conçus pour moins dépendre de la confiance accordée à un opérateur unique. Les développeurs peuvent plutôt combiner protections adossées au matériel, attestation, infrastructure distribuée et contrôles d’accès explicites.

 

C’est le prolongement naturel des principes qui façonnent l’infrastructure crypto depuis ses débuts.

 

La prochaine couche de l’infrastructure crypto

 

La crypto a passé des années à construire des systèmes qui réduisent la dépendance envers les intermédiaires. Les agents autonomes posent un nouveau défi : un logiciel capable d’agir de façon indépendante a aussi besoin d’une infrastructure sur laquelle il peut fonctionner sans faire aveuglément confiance à l’opérateur.

 

Acurast réunit calcul sur smartphones, exécution confidentielle adossée au matériel, attestation et provisionnement par wallet dans une architecture conçue pour relever ce défi.

 

Acurast offre aux développeurs un moyen d’explorer un autre modèle d’exécution des agents : un modèle où l’environnement d’exécution peut être plus confidentiel, l’infrastructure plus distribuée et l’accès au calcul mieux adapté aux logiciels autonomes.

Pour commencer

 

Le moyen le plus rapide de découvrir Acurast est de déployer un agent existant avant de construire le vôtre.

 

Choisissez un exemple. Parcourez les exemples d’applications Acurast et commencez par Hermes ou OpenClaw.

 

Suivez le tutoriel de déploiement. Configurez l’environnement et la durée du déploiement, puis déployez l’application, comme le montre le tutoriel Hermes.

 

Construisez votre propre charge de travail. Utilisez l’Acurast Quickstart et la documentation de la CLI pour adapter votre agent existant.

 

Explorez le provisionnement autonome. Consultez la documentation du Deploy Agent si votre agent doit demander et payer du calcul de manière programmatique.

 

Quelle que soit l’infrastructure choisie, respectez trois règles de base lorsque vous déployez un agent crypto :

 

• Utilisez un wallet ou un compte dédié. N’accordez que les permissions dont l’agent a besoin et fixez des limites de dépense explicites.
• Tenez les secrets à l’écart des prompts et des logs. Fournissez les identifiants via la configuration de déploiement appropriée et évitez de les exposer dans les conversations de l’agent.
• Anticipez l’expiration du déploiement. Définissez une durée adaptée et stockez l’état essentiel dans un stockage durable, car les déploiements temporaires peuvent s’arrêter et leurs données locales peuvent être supprimées à leur expiration.

 

Ces garde-fous comptent quel que soit l’endroit où l’agent tourne. Une meilleure infrastructure de calcul complète une conception rigoureuse du wallet et une sécurité soignée au niveau de l’application ; elle ne les remplace pas.

Vous développez sur Acurast ? Si vous faites tourner des agents, des backends d’agents ou des services d’inférence sur des téléphones, le Discord d’Acurast est l’endroit où les développeurs échangent leurs expériences. Rejoignez le Discord.

Related Blogs