Taguer @grok dans une publication X accompagnée de quelques points et traits était tout ce qu'il fallait hier soir pour qu'un acteur malveillant puisse dérober les fonds d'un portefeuille cryptographique vérifié sans jamais toucher aux clés privées.
La plateforme de lancement de jetons agents, Bankrbot a rapporté le 4 mai qu'elle avait envoyé 3 milliards de DRB sur Base au destinataire 0xe8e47...a686b.
Les fonds provenaient d'un portefeuille attribué à l'IA de X, Grok, et avaient été envoyés vers un portefeuille non autorisé détenu par un acteur malveillant. Cette transaction Base montre le chemin de transfert sur la chaîne derrière la publication.
La revue de CryptoSlate des publications X autour de l'incident met en évidence un chemin de commande signalé qui commençait par une obfuscation en code Morse. Grok a décodé le texte en une instruction publique claire taguant @bankrbot et lui demandant d'envoyer les tokens, tandis que Bankrbot traitait la commande comme exécutable.
La couche exposée était le passage du langage à l'autorité. Un modèle qui décode un puzzle, rédige une réponse utile ou reformate le texte d'un utilisateur peut devenir partie intégrante d'une chaîne de paiement lorsque un autre agent considère cette sortie comme valide.
Pour les investisseurs en crypto, ce transfert devrait transformer le risque lié aux agents IA d'un débat abstrait sur la sécurité en un problème de contrôle de portefeuille. Une commande publique peut devenir une autorité de dépense lorsqu'un système traite la sortie d'un modèle comme une instruction et qu'un autre système dispose d'une autorisation pour déplacer des tokens.
Les permissions de portefeuille, le parseur, le déclencheur social et la politique d'exécution deviennent des couches de vecteurs d'attaque.
[
Articles connexes
Les gagnants de la crypto grâce à l'IA ne sont pas des pièces de crypto, car les agents commencent à dépenser de manière autonome
L'essor des agents IA pose une question simple aux implications énormes pour la crypto : comment le logiciel paie-t-il ?
28 mars 2026 · Andjela Radmilac
Les publications et le contexte de la transaction examinés par CryptoSlate situent le transfert de DRB entre environ 155 000 et 200 000 dollars à l'époque, avec les données de prix de DebtReliefBot fournissant un contexte de marché pour le token.
Les rapports examinés par CryptoSlate indiquent également que la plupart des fonds sont en cours de restitution, et qu'une partie des DRB serait conservée à titre de prime informelle pour les bugs. Ce résultat a réduit les pertes, mais il a aussi montré à quel point la récupération dépendait davantage de la coordination post-transaction que de limites pré-transaction.
Le développeur de Bankr, 0xDeployer, a déclaré que 80 % des fonds avaient été restitués, tandis que les 20 % restants feraient l'objet d'une discussion avec la communauté DRB. Cela confirmait la récupération partielle tout en laissant le sort final des fonds retenus en suspens.
0xDeployer a également précisé que Bankr provisionnait automatiquement un portefeuille X pour chaque compte interagissant avec la plateforme, y compris Grok. Selon la publication, ce portefeuille est contrôlé par celui qui contrôle le compte X plutôt que par Bankr ou le personnel de xAI.
Comment un texte public est devenu une autorité de dépense
Le chemin signalé comportait quatre étapes. Premièrement, l'attaquant avait identifié un NFT de membre du Club Bankr dans un portefeuille associé à Grok avant l'incident.
La revue de CryptoSlate indique qu'il avait étendu les privilèges de transfert du portefeuille dans l'environnement Bankr. La page d'accès de Bankr décrit aujourd'hui les mécanismes de membre et d'accès, plaçant la revendication du NFT dans la couche de permission plus large plutôt que comme explication complète.
Deuxièmement, l'attaquant avait publié sur X un message contenant du code Morse, accompagné d'une mise en forme supplémentaire bruyante. Les publications autour de l'incident décrivaient une injection de prompt en code Morse, tandis que le prompt désormais supprimé n'était pas disponible pour notre examen direct.
Le vecteur signalé était du code Morse avec éventuellement des astuces de tableau ou de concaténation mêlées.
Troisièmement, la réponse publique de Grok aurait traduit le texte obscurci en anglais clair et inclut le tag @bankrbot. Dans ce compte, Grok agissait comme un décodeur utile.
Le risque est apparu après que le texte a quitté Grok et est entré dans une interface de bot qui surveillait les sorties publiques à la recherche de commandes formatées.
Quatrièmement, Bankrbot a traité la commande publique comme exécutable et a diffusé un transfert de tokens. Bankr et Base décrivent une surface de portefeuille pour agents capable d'utiliser les fonctionnalités de portefeuille pour les transferts, les swaps, le parrainage de gaz et les lancements de tokens, tandis que les envois de tokens en langage naturel s'intègrent directement dans cette surface produit.
La documentation plus large de Bankr sur l'assistant IA onchain montre pourquoi la frontière entre les instructions de chat et l'autorité de transaction nécessite une politique explicite.
| Étape | Surface | Action observée | Contrôle qui aurait changé le résultat |
|---|---|---|---|
| Configuration des privilèges | Couche de portefeuille ou de membre | Les accès auraient été étendus avant l'apparition du prompt | Examen séparé des privilèges pour les nouvelles capacités de portefeuille |
| Obfuscation | Publication X | Le code Morse insérait une instruction de paiement dans un texte obscurci | Vérifications de décodage et classification avant la publication des réponses |
| Sortie publique | Réponse de Grok | La commande proprement dite était exposée avec un tag de bot | Sanitisation des sorties pour les chaînes de commandes ressemblant à des outils |
| Exécution | Bankrbot | Le bot a agi sur une commande publique et a déplacé des tokens | Listes blanches de destinataires, limites de dépenses et confirmation humaine |
Pourquoi les agents de portefeuille modifient le risque
L'injection de prompt a souvent été traitée comme un problème de comportement du modèle. La version financière est plus concrète.
Le modèle peut effectuer un travail ordinaire tout en accordant au système environnant une trop grande autorité sur sa sortie.
[
Articles connexes
La difficulté avec les ‘Agents’ d'IA générative
La quête de puissance de l'IA générative crée des risques systémiques dans l'intégration à la crypto.
20 avril 2025 · John deVadoss
](https://cryptoslate.com/the-trouble-with-generative-ai-agents/)
Des instructions malveillantes peuvent entrer dans un modèle via contenus tiers, et les défenses des agents se concentrent de plus en plus sur l'accès aux outils, les confirmations et les contrôles entourant les actions conséquentes.
La catégorie excessive-agency capture le même risque opérationnel : des permissions larges, des fonctions sensibles et une action autonome augmentent le rayon d'impact. La liste plus large des risques liés aux applications LLM traite également l'injection de prompt et la gestion inappropriée des sorties comme des problèmes au niveau de l'application.
La crypto rend ce rayon d'impact plus difficile à absorber. Un agent de service client qui envoie un mauvais e-mail crée un problème de révision. Un agent de trading ou un assistant de portefeuille qui signe une transaction crée un problème de contrôle des actifs.
La différence réside dans la finalité. Une fois qu'un portefeuille signe et diffuse un transfert, le chemin de récupération dépend des contreparties, de la pression publique ou de l'application de la loi.
L'incident Bankr est surtout marqué par une défaillance de contrôle. Les documents de contrôle d'accès de Bankr décrivent le mode lecture seule, les indicateurs d'opération d'écriture, les listes blanches d'IP et les listes blanches de destinataires.
Ce sont ces types de portes qui se trouvent en dehors du modèle et peuvent réduire les dommages même lorsque le modèle analyse du contenu malveillant d'une manière inattendue.
La même exposition apparaît chez les agents de trading et les assistants locaux disposant de permissions de portefeuille ou d'échange. Un bot de trading avec des clés API peut être manipulé pour réaliser de mauvaises commandes s'il accepte des commentaires de marché, des publications sociales, des e-mails ou des pages web comme instructions.
Un assistant local ayant accès à un portefeuille crée une version à enjeux plus élevés du même problème d'appel d'outils : des instructions indirectes peuvent pousser l'assistant vers la préparation d'une transaction ou la divulgation de détails opérationnels sensibles.
La recherche en sécurité a déjà modélisé cette classe d'échec. L'injection indirecte de prompt décrit du contenu malveillant qui manipule les agents à travers les données qu'ils traitent, tandis que la recherche sur les agents appelant des outils évalue les attaques et défenses pour les agents travaillant avec des outils externes.
La taxonomie de l'apprentissage automatique adversarial du NIST fournit le langage plus large pour réfléchir à ces attaques et à leurs mitigations.
Ce que les utilisateurs de crypto devraient exiger
Pour les investisseurs en crypto, la conception des permissions est l'exigence centrale. Un agent connecté à un portefeuille devrait partir de l'hypothèse que les pages web, les publications X, les DM, les e-mails et les textes encodés peuvent contenir des instructions hostiles.
Cette hypothèse transforme la sécurité des agents en un problème de politique de transaction.
Premièrement, les agents de trading devraient disposer de modes de lecture et d'écriture distincts. Le mode de lecture peut résumer les marchés, comparer les tokens et proposer des actions.
Le mode d'écriture devrait exiger une confirmation fraîche de l'utilisateur, une taille d'ordre limitée et un lieu ou un destinataire préapprouvé. Une commande apparue dans un texte public ne devrait jamais hériter d'une autorité de portefeuille simplement parce qu'elle correspond à un format en langage naturel.
Deuxièmement, les listes blanches de destinataires devraient être appliquées par du code en dehors du LLM. Le modèle peut suggérer un transfert.
La couche de politique devrait décider si le destinataire, le token, la chaîne, le montant et le timing sont autorisés. Si un champ sort de la politique, l'exécution devrait s'arrêter ou passer en revue humaine.
Troisièmement, les limites de dépenses devraient être basées sur la session et réinitialisées de façon agressive. Un plafond quotidien ou par action aurait pu réduire ou bloquer le transfert de DRB, selon la politique.
Le chiffre exact dépend du solde et de la stratégie de l'utilisateur, mais l'invariant est plus simple : aucun agent ne devrait avoir une autorité de dépense illimitée parce qu'il a correctement analysé une commande.
Quatrièmement, l'isolement des clés locales devrait être traité comme une limite stricte. Les utilisateurs avancés exécutant des assistants personnalisés sur des machines avec accès à un portefeuille ou à un échange devraient séparer ces informations d'identification des permissions de fichier et de navigateur de l'assistant.
0xDeployer a indiqué qu'une version antérieure de l'agent de Bankr comportait un blocage codé pour ignorer les réponses de Grok afin d'éviter les chaînes d'injection de prompt LLM-sur-LLM. Cette protection n'a pas été intégrée dans la dernière refonte de l'agent, créant ainsi la faille qui a permis à la réponse publique de Grok de devenir une instruction exécutable de Bankr.
Deployer a ajouté depuis une protection plus forte sur le compte de Grok et a orienté les opérateurs de portefeuilles d'agents vers les contrôles déjà disponibles pour les propriétaires de comptes, notamment les listes blanches d'IP sur les clés API, les clés API autorisées et un interrupteur par compte qui désactive l'exécution de Bankr à partir des réponses X.
L'assistant peut préparer une ébauche de transaction. Une surface différente de portefeuille devrait l'approuver.
Un trader peut surveiller des écrans d'actifs vastes et Bitcoin et Ethereum conditions, pourtant le risque des agents repose davantage sur les limites de permission que sur la direction du marché.
La précédente couverture de CryptoSlate sur les flux de l'économie des agents, les agents d'IA générative, les paiements autonomes d'agents et les produits crypto connectés à MCP montre à quelle vitesse les agents se rapprochent de l'activité financière.
[
Articles connexes
Staggering 28 billions de dollars circulent dans l’économie des agents de la crypto – mais 76 % d’entre eux sont juste des bots qui brassent des stablecoins
Une part croissante des paiements sur la chaîne est pilotée par des machines, mais DWF, BCG et autres montrent que l’économie dite des agents dépend encore de passerelles centralisées.
17 avril 2026 · Gino Matos
La leçon de sécurité vient du chemin d'autorisation. Traitez la sortie du modèle comme non fiable tant qu'une couche de politique séparée n'a pas validé l'intention, l'autorité, le destinataire, l'actif, le montant et la confirmation de l'utilisateur.
L'injection de prompt continuera à changer de forme à travers les textes encodés et les interactions multi-étapes entre agents. La défense doit vivre là où la transaction est autorisée, avant que le portefeuille ne signe.
La publication Le portefeuille cryptographique de Grok vient d'être exploité par un tweet envoyé en code Morse sans aucune compromission des clés privées est apparue en premier sur CryptoSlate.