Rapport de sécurité SlowMist × Bitget AI : Est-il vraiment sûr de confier son argent à des agents IA tels que « Homard » ?
TechFlow SélectionTechFlow Sélection
Rapport de sécurité SlowMist × Bitget AI : Est-il vraiment sûr de confier son argent à des agents IA tels que « Homard » ?
Ce rapport dresse un état des lieux systématique des problèmes de sécurité liés aux agents IA dans plusieurs scénarios, à partir de deux angles : la recherche en sécurité et la pratique sur les plateformes d’échange.
Dédié à des analyses Web3 approfondiesRédaction : SlowMist et Bitget
I. Contexte
Avec le développement accéléré des technologies de grands modèles, les agents IA évoluent progressivement d’assistants intelligents simples vers des systèmes automatisés capables d’exécuter des tâches de manière autonome. Ce changement est particulièrement marqué dans l’écosystème Web3 : un nombre croissant d’utilisateurs commence à faire appel à des agents IA pour l’analyse des marchés, la génération de stratégies et le trading automatisé, transformant ainsi progressivement l’idée d’un « assistant de trading fonctionnant 7×24 heures » en une réalité concrète. À mesure que Binance et OKX lancent plusieurs fonctions IA (« AI Skills »), que Bitget met en place sa plateforme de ressources Skills (Agent Hub) et son outil sans installation « Homard GetClaw », les agents peuvent directement se connecter aux API des plateformes de trading, aux données sur la chaîne (on-chain) et aux outils d’analyse du marché, assumant ainsi, dans une certaine mesure, les décisions et exécutions de trading qui étaient auparavant confiées à des opérateurs humains.
Comparés aux scripts d’automatisation traditionnels, les agents IA disposent de capacités accrues de prise de décision autonome et d’interaction complexe avec les systèmes. Ils peuvent accéder aux données de marché, appeler des API de trading, gérer les actifs du compte, voire étendre leur écosystème fonctionnel via des extensions ou des « Skills ». Cette amélioration des capacités réduit considérablement le seuil d’entrée pour le trading automatisé, permettant à un plus grand nombre d’utilisateurs non spécialisés de découvrir et d’utiliser ces outils.
Toutefois, l’extension des capacités implique également une expansion de la surface d’attaque.
Dans les scénarios de trading traditionnels, les risques de sécurité sont généralement concentrés sur la fuite d’identifiants de compte, la divulgation de clés API ou les attaques de hameçonnage. Dans l’architecture des agents IA, de nouveaux risques émergent : par exemple, les attaques par injection de prompts (« Prompt Injection ») peuvent influencer la logique décisionnelle de l’agent ; des extensions ou « Skills » malveillantes peuvent constituer de nouvelles portes d’entrée pour des attaques de la chaîne d’approvisionnement ; une configuration inadéquate de l’environnement d’exécution peut aussi conduire à une utilisation abusive de données sensibles ou de droits d’accès aux API. Lorsque ces problèmes s’associent à des systèmes de trading automatisés, leurs conséquences potentielles ne se limitent pas à une simple fuite d’informations, mais peuvent entraîner directement des pertes réelles d’actifs.
Parallèlement, à mesure qu’un nombre croissant d’utilisateurs connectent leurs agents IA à leurs comptes de trading, les attaquants s’adaptent rapidement à cette évolution. De nouveaux modes de fraude ciblant les utilisateurs d’agents, la contamination d’extensions malveillantes (« plugin poisoning ») et l’usage abusif de clés API deviennent progressivement des menaces sécuritaires émergentes. Dans les environnements Web3, les opérations sur les actifs sont souvent à haute valeur et irréversibles : une fois qu’un système automatisé est détourné ou induit en erreur, les impacts des risques peuvent être encore amplifiés.
Sur la base de ce contexte, SlowMist et Bitget ont conjointement rédigé ce rapport afin d’effectuer, à partir de deux angles complémentaires — recherche en sécurité et pratique des plateformes de trading — un recensement systématique des problèmes de sécurité liés aux agents IA dans divers scénarios. Nous espérons que ce rapport fournira aux utilisateurs, développeurs et plateformes des repères utiles en matière de sécurité, contribuant ainsi à un développement plus robuste de l’écosystème des agents IA, au juste équilibre entre innovation et sécurité.
II. Menaces réelles pour la sécurité des agents IA | SlowMist
L’apparition des agents IA fait passer les systèmes logiciels d’une logique « pilotée par l’humain » à une logique où « le modèle participe activement à la prise de décision et à l’exécution ». Ce changement architectural renforce significativement les capacités d’automatisation, mais élargit aussi la surface d’attaque. Du point de vue actuel de l’architecture technique, un système typique d’agent IA comprend généralement plusieurs composants : une couche d’interaction utilisateur, une couche de logique applicative, une couche de modèle, une couche d’appel d’outils (« Tools » / « Skills »), un système de mémoire (« Memory ») et un environnement d’exécution sous-jacent. Les attaquants ne ciblent généralement pas un module isolé, mais cherchent plutôt à influencer progressivement le contrôle du comportement de l’agent via des chemins multi-niveaux.
1. Contrôle des entrées et attaques par injection de prompts
Dans l’architecture des agents IA, les entrées utilisateur et les données externes sont souvent intégrées directement dans le contexte du modèle, ce qui rend l’injection de prompts (« Prompt Injection ») une méthode d’attaque particulièrement efficace. En construisant des instructions spécifiques, les attaquants peuvent inciter l’agent à exécuter des actions qui ne devraient normalement pas être déclenchées. Par exemple, dans certains cas, il suffit d’une simple instruction textuelle dans une conversation pour pousser l’agent à générer puis exécuter des commandes système hautement dangereuses.
Des formes plus sophistiquées d’attaque consistent en une injection indirecte : l’attaquant dissimule des instructions malveillantes dans le contenu de pages web, des documents d’accompagnement ou des commentaires de code. Lorsque l’agent lit ces contenus dans le cadre de ses tâches, il peut les interpréter par erreur comme des instructions légitimes. Ainsi, l’insertion de commandes malveillantes dans la documentation d’une extension, dans un fichier README ou dans un document Markdown peut conduire l’agent à exécuter du code malveillant lors de l’initialisation de son environnement ou de l’installation de dépendances.
Cette méthode d’attaque se distingue notamment par le fait qu’elle ne repose pas nécessairement sur des vulnérabilités traditionnelles, mais exploite plutôt le mécanisme de confiance du modèle envers les informations contextuelles pour influencer sa logique comportementale.
2. Contamination de la chaîne d’approvisionnement via l’écosystème des « Skills » / extensions
Dans l’écosystème actuel des agents IA, les extensions et systèmes de compétences (« Skills » / « MCP » / « Tools ») constituent un moyen essentiel d’étendre les capacités des agents. Or cet écosystème d’extensions devient lui-même une nouvelle porte d’entrée pour les attaques de la chaîne d’approvisionnement.
Lors de la surveillance du centre officiel d’extensions OpenClaw, ClawHub, SlowMist a constaté que, avec la croissance du nombre de développeurs, certaines « Skills » malveillantes avaient commencé à s’y infiltrer. Après avoir analysé et regroupé les indicateurs de compromission (IOC) de plus de 400 « Skills » malveillantes, SlowMist a découvert que de nombreux échantillons pointaient vers un petit nombre de noms de domaine fixes ou vers plusieurs chemins aléatoires situés sous la même adresse IP, révélant un schéma net de réutilisation de ressources — caractéristique typique d’attaques coordonnées et massives.
Dans le système de « Skills » d’OpenClaw, le fichier central est généralement « SKILL.md ». Contrairement au code traditionnel, ce type de fichier Markdown remplit souvent un double rôle : guide d’installation et point d’entrée pour l’initialisation. Toutefois, dans l’écosystème des agents, ces fichiers sont souvent copiés et exécutés directement par les utilisateurs, créant ainsi une chaîne d’exécution complète. Il suffit donc à un attaquant de déguiser une commande malveillante en étape d’installation de dépendances — par exemple en utilisant une commande « curl | bash » ou en encodant la véritable instruction en Base64 — pour inciter l’utilisateur à exécuter un script malveillant.
Dans des échantillons réels, certaines « Skills » adoptent une stratégie classique de « chargement en deux étapes » : le premier script ne fait que télécharger et exécuter une charge utile (« Payload ») secondaire, réduisant ainsi le taux de détection statique. Prenons l’exemple d’une « Skill » très téléchargée, « X (Twitter) Trends » : son fichier « SKILL.md » contenait une commande codée en Base64.
Une fois décodée, on découvre qu’il s’agit fondamentalement d’un script distant à télécharger et exécuter :
Le programme de deuxième étape simule une fenêtre système pour récupérer le mot de passe de l’utilisateur, collecte ensuite des informations sur la machine locale, les documents du bureau et les fichiers présents dans le dossier de téléchargement, puis les archive et les transfère vers un serveur contrôlé par l’attaquant.
L’avantage fondamental de cette méthode réside dans le fait que l’enveloppe externe de la « Skill » peut rester relativement stable, tandis que l’attaquant n’a besoin que de modifier la charge utile distante pour mettre à jour continuellement sa logique d’attaque.
3. Risques au niveau de la prise de décision et de l’orchestration des tâches de l’agent
Au niveau de la logique applicative de l’agent IA, les tâches sont généralement décomposées par le modèle en plusieurs étapes d’exécution. Si un attaquant parvient à influencer ce processus de décomposition, cela peut conduire l’agent à produire un comportement anormal lors de l’exécution d’une tâche légitime.
Par exemple, dans des processus métier impliquant plusieurs étapes (tels que le déploiement automatisé ou les transactions sur la chaîne), un attaquant peut, en falsifiant des paramètres critiques ou en perturbant les jugements logiques, amener l’agent à remplacer l’adresse cible ou à exécuter des opérations supplémentaires au cours du flux d’exécution.
Dans un précédent audit de sécurité réalisé par SlowMist, il a été possible, en renvoyant depuis un protocole MCP un prompt malveillant afin de corrompre le contexte, d’inciter l’agent à invoquer une extension de portefeuille pour effectuer un transfert sur la chaîne.
La particularité de ce type d’attaque réside dans le fait que l’erreur ne provient pas du code généré par le modèle, mais de la corruption de la logique d’orchestration des tâches.
4. Fuites de données privées et d’informations sensibles dans les environnements IDE / CLI
Après l’adoption généralisée des agents IA pour l’assistance au développement et l’automatisation de l’exploitation informatique, un grand nombre d’agents s’exécutent désormais dans des environnements IDE, CLI ou de développement local. Ces environnements contiennent fréquemment d’importantes quantités d’informations sensibles : fichiers de configuration « .env », jetons API, identifiants de services cloud, fichiers de clés privées et diverses clés d’accès. Dès lors qu’un agent, dans le cadre de ses tâches, est autorisé à lire ces répertoires ou à indexer les fichiers projet, il peut involontairement intégrer ces données sensibles dans le contexte du modèle.
Dans certains flux de développement automatisés, l’agent peut, durant le débogage, l’analyse des journaux ou l’installation des dépendances, lire les fichiers de configuration situés dans le répertoire du projet. En l’absence de stratégie explicite d’exclusion ou de contrôle d’accès, ces informations peuvent être enregistrées dans des journaux, envoyées à une API de modèle distante, voire transmises par une extension malveillante.
En outre, certains outils de développement autorisent l’agent à analyser automatiquement le référentiel de code afin de construire une mémoire contextuelle (« Memory »), ce qui élargit encore davantage le périmètre d’exposition des données sensibles. Par exemple, les fichiers de clés privées, les sauvegardes de phrases mnémoniques, les chaînes de connexion aux bases de données ou les jetons API tiers peuvent tous être lus pendant ce processus d’indexation.
Ce problème est particulièrement aigu dans les environnements de développement Web3, car les développeurs y stockent couramment des clés privées de test, des jetons RPC ou des scripts de déploiement. Une fois ces informations obtenues par une « Skill » malveillante, une extension ou un script distant, les attaquants peuvent alors prendre le contrôle du compte du développeur ou de son environnement de déploiement.
Il est donc essentiel, dans les scénarios d’intégration des agents IA avec les environnements IDE / CLI, d’établir des stratégies explicites d’ignorance des répertoires sensibles (par exemple, des mécanismes similaires à « .agentignore » ou « .gitignore ») ainsi que des mesures d’isolement des permissions, afin de réduire efficacement le risque de fuite de données.
5. Incertitude au niveau du modèle et risques liés à l’automatisation
Les modèles IA ne sont pas des systèmes entièrement déterministes : leurs sorties présentent un certain degré d’instabilité probabiliste. Ce phénomène, connu sous le nom d’« hallucination du modèle », désigne la génération par le modèle de résultats apparemment plausibles mais en réalité erronés, lorsqu’il manque d’informations pertinentes. Dans les applications traditionnelles, de telles erreurs affectent principalement la qualité de l’information fournie ; or, dans l’architecture des agents IA, la sortie du modèle peut déclencher directement des opérations système.
Par exemple, dans certains cas, le modèle, lors du déploiement d’un projet, n’a pas consulté les paramètres réels, mais a généré un identifiant erroné et poursuivi néanmoins le processus de déploiement. Si un tel scénario se produit dans un contexte de transaction sur la chaîne ou d’opération sur des actifs, la décision erronée pourrait entraîner des pertes financières irréversibles.
6. Risques liés aux opérations à haute valeur dans les scénarios Web3
Contrairement aux systèmes logiciels traditionnels, de nombreuses opérations dans l’environnement Web3 sont irréversibles. Par exemple, les transferts sur la chaîne, les échanges de jetons (« Token Swap »), l’ajout de liquidités ou les appels de contrats intelligents, une fois signés et diffusés sur le réseau, sont généralement impossibles à annuler ou à rembobiner. Ainsi, lorsque les agents IA sont utilisés pour exécuter des opérations sur la chaîne, leurs risques de sécurité sont eux aussi fortement amplifiés.
Dans certains projets expérimentaux, les développeurs commencent déjà à faire participer directement les agents à l’exécution de stratégies de trading sur la chaîne, comme l’arbitrage automatisé, la gestion des fonds ou les opérations DeFi. Toutefois, si l’agent subit, lors de la décomposition des tâches ou de la génération des paramètres, une attaque par injection de prompts, une contamination du contexte ou une attaque via une extension, il peut, au cours de la transaction, remplacer l’adresse cible, modifier le montant ou appeler un contrat malveillant. En outre, certains frameworks d’agents autorisent les extensions à accéder directement aux API de portefeuille ou aux interfaces de signature. En l’absence de mécanismes d’isolement de la signature ou de confirmation manuelle, un attaquant pourrait même déclencher des transactions automatiques via une « Skill » malveillante.
Il est donc extrêmement risqué de lier totalement un agent IA à un système de contrôle des actifs dans les scénarios Web3. Un modèle plus sûr consiste à limiter le rôle de l’agent à la génération de recommandations de transactions ou de données de transaction non signées, tandis que la signature effective serait réalisée par un portefeuille indépendant ou confirmée manuellement. Par ailleurs, l’association de mécanismes tels que la vérification de la réputation des adresses, les systèmes de prévention du blanchiment d’argent (AML) et la simulation des transactions permettrait également de réduire, dans une certaine mesure, les risques associés au trading automatisé.
7. Risques systémiques liés à l’exécution avec des privilèges élevés
De nombreux agents IA, lors de leur déploiement réel, bénéficient de privilèges système élevés : accès au système de fichiers local, exécution de commandes Shell, voire exécution avec des droits root. Une fois le comportement de l’agent contrôlé, l’impact de l’attaque peut largement dépasser celui d’une seule application.
SlowMist a testé l’intégration d’OpenClaw avec des logiciels de messagerie instantanée tels que Telegram, permettant ainsi un contrôle à distance. Si ce canal de contrôle est pris en main par un attaquant, l’agent peut être utilisé pour exécuter des commandes système arbitraires, lire les données du navigateur, accéder aux fichiers locaux ou même contrôler d’autres applications. Combiné à l’écosystème des extensions et aux capacités d’appel d’outils, un tel agent possède, dans une certaine mesure, les caractéristiques d’un « contrôle à distance intelligent ».
Dans l’ensemble, les menaces pesant sur la sécurité des agents IA ne se limitent plus aux vulnérabilités logicielles traditionnelles, mais traversent désormais plusieurs dimensions : l’interaction avec le modèle, la chaîne d’approvisionnement des extensions, l’environnement d’exécution et la couche d’opérations sur les actifs. Les attaquants peuvent manipuler le comportement de l’agent via des prompts, injecter des portes dérobées au niveau de la chaîne d’approvisionnement via des « Skills » ou des paquets de dépendances malveillants, puis amplifier l’impact de l’attaque dans un environnement d’exécution doté de privilèges élevés. Dans les scénarios Web3, la nature irréversible des opérations sur la chaîne et leur lien direct avec des actifs réels amplifient encore davantage ces risques. Par conséquent, dans la conception et l’utilisation des agents IA, les stratégies de sécurité applicative traditionnelles ne suffisent plus à couvrir pleinement ces nouvelles surfaces d’attaque : il est indispensable de mettre en place un système de protection sécuritaire plus systématique, couvrant notamment le contrôle des permissions, la gouvernance de la chaîne d’approvisionnement et les mécanismes de sécurité des transactions.
III. Bonnes pratiques de sécurité pour le trading avec des agents IA | Bitget
À mesure que les capacités des agents IA se renforcent, ils ne se contentent plus de fournir des informations ou d’assister la prise de décision : ils participent désormais directement aux opérations système, voire aux transactions sur la chaîne. Ce changement est particulièrement marqué dans le domaine du trading cryptographique. De plus en plus d’utilisateurs tentent d’impliquer des agents IA dans l’analyse des marchés, l’exécution de stratégies et le trading automatisé. Lorsque l’agent peut directement appeler les interfaces de trading, accéder aux actifs du compte et passer des ordres automatiquement, la question de sa sécurité évolue d’un « risque de sécurité système » à un « risque sur les actifs réels ». Lorsqu’un agent IA est utilisé pour des transactions réelles, comment les utilisateurs peuvent-ils protéger la sécurité de leur compte et de leurs fonds ?
À cette fin, cette section présente, sous la responsabilité de l’équipe de sécurité de Bitget et fondée sur l’expérience pratique acquise sur la plateforme, un panorama systématique des stratégies de sécurité à privilégier lors de l’utilisation d’agents IA pour le trading automatisé, notamment en matière de sécurité des comptes, de gestion des permissions API, d’isolement des fonds et de surveillance des transactions.
1. Principaux risques de sécurité dans les scénarios de trading avec des agents IA
2. Sécurité des comptes
L’apparition des agents IA modifie les vecteurs d’attaque :
- Il n’est plus nécessaire d’accéder à votre compte — il suffit de s’emparer de votre clé API.
- Vous n’avez pas besoin de vous en rendre compte — l’agent fonctionne 7×24 heures de façon autonome, et les opérations anormales peuvent se poursuivre pendant plusieurs jours.
- Il n’est pas nécessaire de retirer des fonds — vider vos actifs directement sur la plateforme constitue déjà une cible d’attaque.
La création, la modification et la suppression des clés API doivent toutes être effectuées depuis un compte déjà authentifié — la compromission du compte implique donc celle du contrôle des clés API. Le niveau de sécurité du compte détermine directement le niveau maximal de sécurité atteignable pour les clés API.
Voici ce que vous devriez faire :
- Activer Google Authenticator comme méthode principale d’authentification à deux facteurs (2FA), plutôt que le SMS (les cartes SIM pouvant être piratées).
- Activer la connexion sans mot de passe via Passkey : basée sur la norme FIDO2/WebAuthn, elle remplace le mot de passe traditionnel par un chiffrement asymétrique (clé publique/privée), rendant structurellement inefficace toute tentative de phishing.
- Configurer un code anti-phishing.
- Vérifier régulièrement le centre de gestion des appareils et supprimer immédiatement tout appareil inconnu, puis modifier votre mot de passe.
3. Sécurité des API
Dans l’architecture du trading automatisé avec des agents IA, la clé API constitue le « certificat d’autorisation d’exécution » de l’agent. L’agent lui-même ne détient pas directement le contrôle du compte ; toutes les opérations qu’il est capable d’effectuer dépendent exclusivement de l’étendue des permissions accordées à la clé API. Ainsi, la frontière des permissions détermine à la fois ce que l’agent est autorisé à faire, et l’ampleur potentielle des pertes en cas d’incident de sécurité.
Matrice de configuration des permissions — principe du moindre privilège, pas celui de la commodité :
Sur la plupart des plateformes de trading, les clés API prennent généralement en charge plusieurs mécanismes de contrôle de sécurité. Une utilisation appropriée de ces mécanismes peut considérablement réduire le risque d’abus de la clé API. Voici les bonnes pratiques recommandées :
Erreurs fréquemment commises par les utilisateurs :
- Coller directement la clé API du compte principal dans la configuration de l’agent — exposant ainsi l’intégralité des permissions du compte principal.
- Cochez « Tout sélectionner » pour les types d’opérations afin de simplifier les choses, ce qui revient à ouvrir toutes les possibilités d’action.
- Ne pas définir de « passphrase », ou utiliser la même « passphrase » que le mot de passe du compte.
- Écrire la clé API en clair dans le code source, puis la publier sur GitHub, où elle sera détectée par des robots en moins de trois minutes.
- Autoriser une même clé à plusieurs agents et outils simultanément — une seule compromission entraîne l’exposition totale.
- Ne pas révoquer immédiatement la clé après une fuite, laissant ainsi une fenêtre d’exploitation continue aux attaquants.
Gestion du cycle de vie des clés :
- Renouveler la clé API tous les 90 jours, et supprimer immédiatement l’ancienne.
- Supprimer immédiatement la clé correspondante dès qu’un agent est désactivé, afin d’éliminer toute surface d’attaque résiduelle.
- Vérifier régulièrement les journaux d’appels API, et révoquer immédiatement la clé dès qu’un appel provenant d’une adresse IP inconnue ou à un horaire inhabituel est détecté.
4. Sécurité des fonds
L’ampleur des dommages causés par un attaquant ayant obtenu une clé API dépend de la somme que cette clé est autorisée à déplacer. Par conséquent, outre la sécurité des comptes et le contrôle des permissions API, il convient, lors de la conception de l’architecture de trading avec des agents IA, de mettre en œuvre un mécanisme d’isolement des fonds afin de fixer clairement une limite maximale de perte potentielle.
Mécanisme d’isolement via des sous-comptes :
- Créer un sous-compte dédié à l’agent, totalement séparé du compte principal.
- Transférer uniquement les fonds strictement nécessaires à l’agent depuis le compte principal — pas l’intégralité des actifs.
- Même si la clé du sous-compte est volée, le montant maximal accessible à l’attaquant correspond exactement au solde du sous-compte ; le compte principal reste intact.
- Gérer chaque stratégie d’agent via un sous-compte distinct, assurant ainsi une isolation mutuelle.
Mot de passe des fonds comme deuxième verrou :
- Le mot de passe des fonds (« Fund Password ») est entièrement séparé du mot de passe de connexion : même si le compte est connecté, aucun retrait ne peut être initié sans ce mot de passe spécifique.
- Utiliser un mot de passe des fonds différent du mot de passe de connexion.
- Activer la liste blanche des adresses de retrait : seules les adresses préalablement ajoutées sont autorisées à recevoir des retraits ; toute nouvelle adresse nécessite une période d’audit de 24 heures.
- Après modification du mot de passe des fonds, le système gèle automatiquement les retraits pendant 24 heures — il s’agit d’un mécanisme de protection conçu pour vous.
5. Sécurité des transactions
Dans les scénarios de trading automatisé avec des agents IA, les problèmes de sécurité ne se manifestent souvent pas par un comportement anormal ponctuel, mais peuvent se développer progressivement au fil du fonctionnement continu du système. Outre la sécurité des comptes et le contrôle des permissions API, il est donc indispensable de mettre en place un système continu de surveillance des transactions et de détection des anomalies, afin de pouvoir identifier rapidement tout dysfonctionnement et intervenir en amont.
Système de surveillance obligatoire :
Reconnaissance des signaux d’anomalie — arrêtez immédiatement l’agent et procédez à une vérification dès l’apparition de l’un des cas suivants :
- L’agent reste inactif pendant une longue période, mais de nouveaux ordres ou positions apparaissent sur le compte.
- Les journaux d’appels API révèlent des requêtes provenant d’adresses IP autres que celles des serveurs de l’agent.
- Vous recevez une notification de transaction sur une paire de trading que vous n’avez jamais configurée.
- Le solde du compte connaît une variation inexplicable.
- L’agent demande à plusieurs reprises « plus de permissions pour exécuter cette action » — identifiez d’abord la cause avant de décider d’accorder ou non ces permissions supplémentaires.
Gestion des sources des « Skills » et outils :
- N’installer que des « Skills » publiées officiellement et disponibles via des canaux vérifiés.
- Éviter d’installer des extensions tierces dont la source est inconnue ou non vérifiée.
- Examiner régulièrement la liste des « Skills » installées et supprimer celles qui ne sont plus utilisées.
- Se méfier des versions communautaires « améliorées » ou « traduites » de « Skills » — toute version non officielle représente un risque.
6. Sécurité des données
La prise de décision de l’agent IA repose sur une grande quantité de données (informations sur le compte, positions ouvertes, historique des transactions, données de marché, paramètres de stratégie). Si ces données sont divulguées ou altérées, un attaquant pourrait en déduire votre stratégie ou même manipuler le comportement des transactions.
Voici ce que vous devriez faire :
- Principe de moindre donnée : ne fournir à l’agent que les données strictement nécessaires à l’exécution des transactions.
- Anonymisation des données sensibles : les journaux et les informations de débogage ne doivent pas inclure les informations complètes du compte, les clés API ou d’autres données sensibles.
- Interdire le téléchargement de données complètes du compte vers des modèles IA publics (ex. : API de LLM publics).
- Si possible, séparer les données stratégiques des données du compte.
- Désactiver ou limiter la capacité de l’agent à exporter l’historique des transactions.
Erreurs fréquemment commises par les utilisateurs :
- Télécharger l’historique complet des transactions à une IA avec la demande « aide-moi à optimiser ma stratégie ».
- Imprimer la clé API / le secret dans les journaux de l’agent.
- Publier sur des forums publics des captures d’écran de transactions (incluant l’ID de commande ou les informations du compte).
- Télécharger une sauvegarde de base de données vers un outil IA pour analyse.
7. Conception de sécurité au niveau de la plateforme des agents IA
Outre les configurations de sécurité côté utilisateur, la sécurité de l’écosystème du trading avec des agents IA dépend fortement de la conception sécurisée au niveau de la plateforme. Une plateforme mature d’agents IA doit généralement mettre en œuvre des mécanismes de protection systématiques en matière d’isolement des comptes, de contrôle des permissions API, d’audit des extensions et de capacités de sécurité fondamentales, afin de réduire globalement les risques auxquels sont exposés les utilisateurs lors de leur intégration à des systèmes de trading automatisé.
Dans les architectures réelles de plateformes, les dispositifs de sécurité courants comprennent généralement les aspects suivants.
1. Système d’isolement via des sous-comptes
Dans les environnements de trading automatisé, les plateformes offrent généralement un système de sous-comptes ou de comptes dédiés aux stratégies, afin d’isoler les fonds et les permissions de différents systèmes automatisés. Grâce à ce dispositif, les utilisateurs peuvent attribuer à chaque agent ou stratégie de trading un compte et un pool de fonds indépendants, évitant ainsi les risques liés au partage d’un même compte entre plusieurs systèmes automatisés.
2. Configuration fine des permissions API
Les opérations centrales des agents IA reposent sur les interfaces API ; par conséquent, la conception des permissions API au niveau de la plateforme doit généralement supporter un contrôle granulaire, comme la segmentation des permissions de trading, la restriction des sources IP et l’ajout de mécanismes de vérification de sécurité supplémentaires. Grâce à ce modèle de permissions, les utilisateurs peuvent accorder à l’agent uniquement le minimum de droits requis pour accomplir sa tâche.
3. Mécanisme d’audit des extensions et « Skills » pour agents
Certaines plateformes instaurent des procédures d’audit pour la publication et la mise en ligne des extensions ou « Skills », par exemple des examens de code, des évaluations de permissions et des tests de sécurité, afin de réduire la probabilité qu’un composant malveillant pénètre dans l’écosystème. Du point de vue de la sécurité, ce type de mécanisme d’audit ajoute une couche de filtrage au niveau de la plateforme sur la chaîne d’approvisionnement des extensions, bien que les utilisateurs conservent néanmoins la responsabilité fondamentale de maintenir une vigilance de base concernant les composants qu’ils installent.
4. Capacités fondamentales de sécurité de la plateforme
Outre les mécanismes de sécurité propres aux agents, le système de sécurité des comptes propre à la plateforme de trading influence également fortement les utilisateurs d’agents. Par exemple :
8. Nouveaux types de fraude spécifiquement destinés aux utilisateurs d’agents
Usurpation d’assistance client
« Votre clé API présente un risque de sécurité : veuillez la reconfigurer immédiatement. » Puis vous êtes redirigé vers un lien de phishing.
→ L’assistance officielle ne vous contactera jamais en privé pour vous demander votre clé API.
Contamination de paquets « Skill »
Partage communautaire d’une « Skill » de trading « améliorée », qui envoie silencieusement votre clé API lors de son exécution.
→ Installez uniquement les « Skills » provenant de canaux officiels et soumis à un audit.
Notifications de mise à jour usurpées
« Une nouvelle autorisation est requise », cliquez dessus et vous atterrissez sur une page imitant l’interface officielle.
→ Vérifiez le code anti-phishing figurant dans vos e-mails.
Attaques par injection de prompts
Insertion d’instructions dans les données de marché, les actualités ou les annotations des graphiques en chandeliers (K-line), afin de manipuler l’agent et de le pousser à exécuter des opérations non prévues.
→ Définissez une limite maximale de fonds sur le sous-compte : même en cas d’injection, les pertes seront circonscrites à cette limite stricte.
Scripts malveillants déguisés en « outils de détection de sécurité »
Un outil prétend détecter si votre clé API a été divulguée, alors qu’il la vole en réalité.
→ Utilisez les fonctionnalités de journalisation ou d’historique des accès fournies par la plateforme officielle pour vérifier les appels API.
9. Procédure de diagnostic
Dès la détection de toute anomalie
↓
Révoquez ou désactivez immédiatement la clé API suspecte
↓
Vérifiez les ordres / positions anormaux sur le compte et annulez-les immédiatement si possible
↓
Consultez l’historique des retraits pour confirmer si des fonds ont déjà été transférés
↓
Modifiez votre mot de passe de connexion et votre mot de passe des fonds, puis déconnectez tous les appareils actuellement connectés
↓
Contactez l’assistance sécurité de la plateforme, en fournissant les périodes et les opérations anormales relevées
↓
Identifiez la source de la fuite de la clé (dépôt de code / fichiers de configuration / journaux des « Skills »)
Principe fondamental : face à tout doute, révoquez d’abord la clé, puis recherchez la cause — l’ordre ne doit jamais être inversé.
IV. Recommandations et conclusion
Dans ce rapport, SlowMist et Bitget, s’appuyant sur des cas concrets et des recherches en sécurité, analysent les problèmes de sécurité les plus typiques actuellement rencontrés par les agents IA dans les scénarios Web3 : les risques de manipulation du comportement des agents par injection de prompts, les risques liés à la chaîne d’approvisionnement dans les écosystèmes d’extensions et de « Skills », les problèmes d’abus de clés API et de permissions de compte, ainsi que les menaces potentielles liées aux erreurs d’exécution automatisée et à l’expansion des permissions. Ces problèmes ne résultent généralement pas d’une seule vulnérabilité, mais sont le fruit combiné de la conception architecturale des agents, des stratégies de contrôle des permissions et de la sécurité de l’environnement d’exécution.
Par conséquent, lors de la construction ou de l’utilisation de systèmes d’agents IA, il convient d’adopter une approche de conception sécurisée à l’échelle de l’architecture globale. Par exemple, appliquer rigoureusement le principe du moindre privilège pour attribuer aux agents des clés API et des permissions de compte, tout en évitant d’activer des fonctionnalités à haut risque inutiles ; appliquer, au niveau de l’appel d’outils, un isolement des permissions pour les extensions et les « Skills », afin d’empêcher qu’un seul composant ne possède simultanément les capacités d’acquisition de données, de génération de décisions et d’opérations sur les fonds ; définir, lors de l’exécution d’opérations critiques par l’agent, des limites comportementales explicites et des restrictions de paramètres, et introduire, dans les cas nécessaires, un mécanisme de confirmation homme-machine afin de réduire les risques irréversibles liés à l’exécution automatisée. En outre, concernant les entrées externes dont dépend l’exécution de l’agent, il convient de mettre en œuvre des mécanismes de défense contre les attaques par injection de prompts, grâce à une conception soignée des prompts et à une isolation rigoureuse des entrées, afin d’éviter que tout contenu externe ne soit directement traité comme une instruction système participant au processus d’inférence du modèle. Lors des phases réelles de déploiement et d’exécution, il faut renforcer la gestion de la sécurité des clés API et des comptes : n’activer que les permissions strictement nécessaires, configurer une liste blanche d’adresses IP, renouveler régulièrement les clés, et éviter de stocker en clair des informations sensibles dans les dépôts de code, les fichiers de configuration ou les systèmes de journaux ; dans les processus de développement et les environnements d’exécution, il convient également de mettre en œuvre des mesures telles que l’audit de sécurité des extensions, le contrôle des informations sensibles dans les journaux, ainsi que des mécanismes de surveillance et d’audit du comportement, afin de réduire les risques liés aux fuites de configuration, aux attaques de la chaîne d’approvisionnement et aux opérations anormales.
À un niveau plus macroscopique d’architecture sécuritaire, SlowMist propose, dans ses recherches connexes, une approche de gouvernance de sécurité multicouche adaptée aux scénarios des agents intelligents dans les domaines de l’IA et du Web3, visant à réduire systématiquement les risques encourus par ces agents dans des environnements à hautes permissions. Dans ce cadre, la gouvernance de sécurité de niveau L1 repose initialement sur une ligne directrice commune de sécurité pour le développement et l’utilisation, en établissant des normes de sécurité couvrant les outils de développement, les frameworks d’agents, les écosystèmes d’extensions et les environnements d’exécution, fournissant ainsi aux équipes une source unique de politiques et une référence d’audit uniforme lors de l’intégration de chaînes d’outils IA. Sur cette base, le niveau L2 permet, grâce à la convergence des frontières de permissions des agents, au contrôle granulaire minimal des appels d’outils et aux mécanismes de confirmation homme-machine pour les opérations critiques, de contraindre efficacement la portée d’exécution des opérations à haut risque. Parallèlement, le niveau L3 introduit, au niveau des points d’entrée des interactions externes, une capacité de détection en temps réel des menaces, permettant de pré-analyser les URL, les dépôts de dépendances et les sources d’extensions, afin de réduire la probabilité qu’un contenu malveillant ou une contamination de la chaîne d’approvisionnement ne pénètre dans la chaîne d’exécution. Dans les scénarios impliquant des transactions sur la chaîne ou des opérations sur les actifs, le niveau L4 assure une isolation de sécurité supplémentaire via une analyse des risques sur la chaîne et un mécanisme de signature indépendant, permettant ainsi à l’agent de construire des transactions sans jamais entrer directement en contact avec les clés privées, réduisant ainsi les risques systémiques liés aux opérations à haute valeur. Enfin, le niveau L5 met en place, grâce à des inspections continues, à des audits de journaux et à des revues de sécurité périodiques, une capacité de sécurité en boucle fermée où « chaque action peut être pré-auditée avant exécution, contrainte pendant l’exécution, et passée en revue après exécution ». Cette approche de sécurité multicouche n’est pas un produit ou un outil isolé, mais un cadre de gouvernance sécuritaire conçu spécifiquement pour les chaînes d’outils IA et les écosystèmes d’agents intelligents. Son objectif central est, sans réduire de façon notable l’efficacité du développement ni les capacités d’automatisation, d’aider les équipes à établir un système opérationnel de sécurité pour les agents qui soit durable, auditable et évolutif, grâce à des stratégies systémiques, à des audits continus et à une coordination dynamique des capacités sécuritaires, afin de mieux relever les défis de sécurité en constante évolution dans le contexte d’une fusion toujours plus profonde entre l’IA et le Web3.
Dans l’ensemble, les agents IA apportent à l’écosystème Web3 un degré accru d’automatisation et d’intelligence, mais leurs défis en matière de sécurité ne doivent pas être sous-estimés. Seule la mise en place de mécanismes de sécurité complets, à tous les niveaux — conception du système, gestion des permissions et surveillance de l’exécution — permettra de promouvoir simultanément l’innovation technologique des agents IA tout en réduisant efficacement les risques potentiels. Nous espérons que ce rapport fournira aux développeurs, aux plateformes et aux utilisateurs des éléments de réflexion utiles lors de la conception et de l’utilisation des systèmes d’agents IA, et contribuera ainsi, dans un esprit de coopération, à la formation d’un écosystème Web3 plus sûr et plus fiable.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
