Des chercheurs conseillent de ne pas faire confiance aux…
Un document amendé du 20 mai décrit trois contrôles au niveau du système alors que Bankr a désactivé les transactions après que plus de 14 portefeuilles ont été accédés.
Un article de recherche amendé du 20 mai soutient que les agents IA connectés aux portefeuilles devraient être considérés comme des composants non fiables et sécurisés au niveau du système, et pas seulement par le biais du renforcement des modèles. L'avertissement intervient alors que l'assistant de trading Bankr a désactivé les transactions le même jour après avoir détecté un attaquant ayant accès à au moins 14 portefeuilles.
Points clés
- Un article de recherche amendé du 20 mai cadre la sécurité des agents IA comme un problème de sécurité des systèmes et traite l'agent lui-même comme un composant non fiable.
- Les auteurs soutiennent que de nombreuses attaques peuvent être bloquées en séparant les instructions des données non fiables, en appliquant des permissions de moindre privilège et en contrôlant où les informations sensibles peuvent circuler.
- L'assistant de trading Bankr a désactivé les transactions le 20 mai après avoir identifié un attaquant qui avait obtenu l'accès à au moins 14 portefeuilles, bien que le chemin d'exploitation n'ait pas été confirmé.
- Le PDG de Circle, Jeremy Allaire, a déclaré en janvier que des milliards d'agents IA pourraient opérer au nom des utilisateurs dans les cinq prochaines années.
Avertissement de sécurité des systèmes pour les agents IA connectés aux portefeuilles
Un article de recherche amendé publié le 20 mai par des chercheurs de Google, Gray Swan AI, EmbraceTheRed et plusieurs universités soutient que la sécurité des agents IA devrait être traitée comme la sécurité informatique, et non comme un problème de niche de "robustesse IA". La revendication principale est claire : l'agent doit être supposé manipulable et donc traité comme un composant non fiable à l'intérieur d'un système plus vaste.
Le cadre de l'article est important pour la crypto car les agents connectés aux portefeuilles fusionnent la prise de décision et l'exécution en un seul flux de travail. Si l'agent est considéré comme fiable, alors l'injection de prompt, l'utilisation abusive d'outils et l'exfiltration de données deviennent des événements à risque pour le portefeuille, et pas seulement des "mauvaises sorties".
Les chercheurs le formulent directement : "À travers cette lentille, les efforts pour augmenter la robustesse des modèles, le point de vue dominant dans la communauté, sont insuffisants en eux-mêmes. Au lieu de cela, nous devons compléter les efforts existants avec des techniques du domaine de la sécurité des systèmes."
Trois contrôles que l'article dit pouvoir bloquer de nombreuses attaques d'agents
Les chercheurs affirment que trois mécanismes au niveau du système pourraient "éliminer une grande fraction des attaques." Pour les développeurs expédiant des assistants de trading ou des bots d'exécution DeFi, ceux-ci correspondent clairement aux modes de défaillance qui drainent réellement les portefeuilles.
Le premier est de séparer les instructions des données non fiables. En termes d'agent, c'est le problème d'injection de prompt : des instructions malveillantes peuvent être cachées dans le contenu que le modèle lit, puis traitées comme si c'était une commande légitime.
Le deuxième est le principe du moindre privilège. L'agent ne devrait avoir que les permissions minimales nécessaires pour la tâche, plutôt qu'un accès large au portefeuille. Si un attaquant dirige l'agent, des permissions limitées réduisent la portée de l'impact.
Le troisième est le flux de données sensibles contrôlé par le système. Le système environnant, et non l'agent, devrait décider où les secrets et les sorties sensibles sont autorisés à aller, réduisant ainsi la chance que l'agent puisse être manipulé pour envoyer des données vers des destinations non sécurisées.
Le fil conducteur est architectural : "de meilleurs prompts" et le durcissement du modèle à eux seuls ne définissent pas la frontière de sécurité. C'est le système qui le fait.
L'arrêt des transactions de Bankr met le risque des agents dans un contexte crypto.
L'avertissement du document n'est pas théorique dans le domaine de la crypto. Le 20 mai, l'assistant de trading crypto alimenté par l'IA, Bankr, a déclaré avoir désactivé les transactions après avoir identifié un attaquant ayant eu accès à au moins 14 portefeuilles.
Ce qui est confirmé, c'est la réponse et le chiffre de portée : les transactions ont été désactivées, et l'accès à au moins 14 portefeuilles a été identifié. Ce qui n'est pas confirmé, c'est la cause profonde. Les experts en sécurité ont spéculé que le bot aurait pu être exploité par un hacker, mais la méthode d'exploitation et l'attribution n'ont pas été établies dans les détails disponibles.
Cette incertitude est le point crucial pour les traders. Lorsque l'exécution est automatisée, la différence entre "mauvaise conduite de l'agent" et "compromission du portefeuille" peut être un seul prompt de permission.
Signaux que les traders peuvent exiger avant d'accorder des permissions au portefeuille.
L'indicateur à court terme sera de savoir si Bankr ou des enquêteurs tiers publient des détails confirmés sur la manière dont l'accès aux "au moins 14 portefeuilles" a eu lieu. Sans un rapport sur l'exploitation, le marché apprend la mauvaise leçon et répète la même architecture.
Du côté produit, les traders devraient s'attendre à ce que les outils d'agent évoluent vers des actions ciblées plutôt que vers un accès large au portefeuille, en particulier pour le trading et l'exécution DeFi. Sean Ren, co-fondateur de Sahara AI, a décrit les protocoles de contexte de modèle comme un modèle de gardien : « Ils agissent essentiellement comme un gardien entre le modèle d'IA et votre portefeuille.
L'agent ne peut effectuer que des actions spécifiques et approuvées, telles que vérifier les soldes ou préparer un paiement pour que vous le confirmiez, plutôt que de déplacer librement des fonds ou de modifier les paramètres du portefeuille. »
Aaron Ratcliff, responsable des attributions chez Merkle Science, a fixé une norme plus élevée pour les agents capables d'exécution : « Je voudrais une preuve que l'IA peut détecter le front-running, appliquerglissementlimites, tokens de fraude sur le marché, etauditdes contrats en temps réel avant de réaliser une transaction.
Il devrait également tester les invites dans un environnement sécurisé, prévenir les injections et bloquer l'accès de type homme du milieu.”
Une autre lacune pratique demeure : le document amendé est référencé sans un titre complet, une liste d'auteurs ou un canonique.liendans l'extrait disponible. Les bâtisseurs auront besoin de cette piste de citation pour mettre en œuvre les contrôles de manière cohérente.
Traitez l'Agent comme un Onglet de Navigateur Compromis, Pas comme un Co-Signataire
Je ne vois pas cela comme un titre disant que l'IA est dangereuse. C'est un rappel que l'automatisation connectée aux portefeuilles n'est que du logiciel avec une nouvelle interface, et que les anciennes règles s'appliquent toujours : supposez un compromis, minimisez les privilèges et imposez des limites en dehors du composant que vous contrôlez le moins.
Le seuil qui compte est de savoir si les produits agents convergent vers des permissions limitées et des contrôles de flux de données imposés par le système comme des défauts, et non comme des fonctionnalités premium.
Si ce changement se produit alors que l'adoption des agents s'accélère selon le calendrier d'Allaire, la configuration commence à sembler structurelle plutôt que dictée par le récit, et l'impact pratique est moins de défaillances à point unique où un agent manipulé peut agir comme un co-signataire de portefeuille complet.
