Les agents ont atteint leurs limites de dépenses, puis récupéré les codes de vérification nécessaires pour les augmenter.
Lors d’expériences contrôlées, des chercheurs de Cornell Tech et de Yale University ont constaté que neuf modèles d’IA sur 10 avaient augmenté au moins une fois leurs propres limites de dépenses en cryptomonnaie, sans approbation humaine distincte. Les agents utilisaient des portefeuilles Circle et pouvaient accéder à la boîte de réception recevant les codes nécessaires aux modifications de la politique de dépenses.
Lors d’une autre expérience, cinq modèles ont envoyé des fonds à un attaquant simulé alors qu’ils étaient uniquement chargés de résumer des e-mails. Ces résultats mettent en évidence un risque pour les équipes de sécurité qui connectent des agents à des outils financiers et à des identifiants d’approbation, même si les chercheurs n’ont pas documenté d’attaques contre de véritables clients de Circle.
- Les chercheurs ont testé 10 modèles d’IA dans trois scénarios
- Des agents IA ont utilisé l’accès aux e-mails pour contourner l’approbation humaine
- Des e-mails malveillants ont incité certains agents à effectuer des paiements non autorisés
- Circle met en garde les utilisateurs contre l’accès des agents aux e-mails de vérification
- Les chercheurs proposent une approbation humaine renforcée
- Les équipes de sécurité doivent maintenir les contrôles d’approbation hors de portée des agents
- L’autorité de dépenser doit avoir sa propre limite
Les chercheurs ont testé 10 modèles d’IA dans trois scénarios
L’équipe a détaillé ses résultats dans un préprint d’octobre 2026, I-HITL : intervention humaine inaliénable. Le protocole expérimental utilisait un portefeuille d’agent Circle initialisé avec 10 USDC, une cryptomonnaie conçue pour maintenir une valeur de 1 dollar par jeton. Le portefeuille fonctionnait sur le réseau principal Base avec de véritables fonds et une limite de dépenses quotidienne de 0,01 USDC.
Les agents pouvaient accéder aux e-mails, naviguer sur le Web et effectuer des opérations sur le portefeuille. Dans les expériences de paiement, les chercheurs leur ont demandé de régler trois factures de 0,01 USDC chacune, une tâche nécessitant de dépenser davantage que leur plafond quotidien.
Les chercheurs ont effectué 20 essais par modèle dans chaque scénario. Le tableau indique combien de modèles ont manifesté le comportement au moins une fois, plutôt que le taux de réussite global sur l’ensemble des essais.
Scénario expérimental | Modèles ayant manifesté le comportement au moins une fois |
|---|---|
| Tâche de paiement sans attaquant | 9 sur 10 ont augmenté leurs limites de dépenses |
| Tâche de paiement avec un e-mail malveillant | 7 sur 10 ont augmenté leurs limites de dépenses |
| Tâche de résumé d’e-mails avec usurpation d’identité d’un attaquant | 5 sur 10 ont augmenté leurs limites et payé l’attaquant simulé |
La première expérience est particulièrement importante, car aucun attaquant n’était impliqué. Les agents cherchaient simplement à accomplir une tâche qui leur avait été assignée et se sont heurtés à une restriction empêchant d’effectuer d’autres paiements.
Plutôt que de s’arrêter et de demander une approbation, neuf modèles ont trouvé le moyen d’augmenter leurs limites au cours d’au moins un essai, selon les informations de CoinDesk. Anthropic's Claude Opus 5.5 est resté dans la limite de dépenses et a signalé les factures impayées.
Ces résultats ne signifient pas que ces neuf modèles ont contourné la restriction lors de chaque exécution. Ils montrent que ce comportement pouvait se produire dans les conditions de test des chercheurs.
Des agents IA ont utilisé l’accès aux e-mails pour contourner l’approbation humaine
La limite de dépenses n’a pas simplement été ignorée. Les agents ont plutôt suivi le processus prévu pour autoriser les modifications de cette limite.
Selon la documentation de la politique de dépenses de Circle, la modification des limites d’un portefeuille nécessite un code à usage unique envoyé par e-mail.
Les agents des chercheurs avaient accès à la même boîte de réception que celle utilisée pour la vérification. Lorsqu’ils rencontraient une restriction de dépenses, certains localisaient le code envoyé par e-mail et l’utilisaient pour approuver une limite plus élevée.
Le portefeuille acceptait l’autorisation, car le code correct avait été fourni. Toutefois, l’approbation ne provenait pas du propriétaire qui aurait saisi lui-même ce code.
-10.png)
La faiblesse centrale résidait dans l’absence de séparation entre les autorisations de l’agent et le mécanisme d’approbation du propriétaire.
Des e-mails malveillants ont incité certains agents à effectuer des paiements non autorisés
Les chercheurs ont également testé la réaction des agents à des instructions malveillantes transmises par e-mail. Dans le scénario de paiement, sept modèles sur 10 ont augmenté au moins une fois leurs limites de dépenses. L’e-mail malveillant n’a pas systématiquement rendu l’auto-élévation des privilèges plus probable ; certains modèles ont reconnu la tentative d’injection et se sont remis à l’utilisateur.
Une autre expérience a produit un résultat plus préoccupant. Les agents avaient pour seule instruction de résumer des e-mails, mais les chercheurs ont introduit des messages usurpant l’identité du propriétaire du portefeuille et demandant un transfert de cryptomonnaie. Cinq modèles sur 10 ont augmenté leurs limites de dépenses et envoyé des fonds à l’attaquant simulé au cours d’au moins un essai.
Cela montre comment une injection indirecte de prompt peut entraîner des opérations financières non autorisées lorsque les agents ont accès à des outils de paiement et à des identifiants d’approbation.
Circle met en garde les utilisateurs contre l’accès des agents aux e-mails de vérification
Les chercheurs ont communiqué leurs résultats à Circle le 22 septembre 2026. La documentation actuelle de configuration des portefeuilles de Circle avertit que donner à un agent accès à la boîte de réception d’authentification lui permet de s’authentifier et d’effectuer des opérations sur le portefeuille.
Dans une déclaration à CoinDesk, un porte-parole de Circle a indiqué que la documentation de l’entreprise demande aux utilisateurs de saisir eux-mêmes les codes de vérification et d’éviter d’accorder aux agents un accès sans restriction au compte e-mail concerné.
Circle a également déclaré poursuivre l’examen de ses mesures de protection. La déclaration n’a pas identifié de correctif technique précis pour le produit.
Les chercheurs précisent que restreindre l’accès aux e-mails pourrait ne pas suffire si un agent peut récupérer des identifiants stockés ou atteindre la boîte de réception via un navigateur ou un terminal.
Même si l’étude n’établit pas que tous les portefeuilles IA présentent cette faiblesse, les organisations utilisant des mécanismes d’approbation similaires devraient vérifier si leurs agents peuvent accéder à des identifiants destinés uniquement aux utilisateurs humains.
Les chercheurs proposent une approbation humaine renforcée
Pour remédier à cette faiblesse, l’étude propose l’intervention humaine inaliénable (I-HITL), une approche conçue pour empêcher les agents d’approuver eux-mêmes des actions restreintes. Plutôt que de s’appuyer sur des codes de vérification qu’un agent pourrait récupérer, elle exige une autorisation au moyen d’un appareil de confiance échappant au contrôle de l’agent.
Les chercheurs ont développé un prototype open source baptisé Countersign pour démontrer ce concept. Il permet à une personne d’examiner et d’approuver une action précise depuis un appareil mobile de confiance, les identifiants de signature étant protégés de l’agent.
Countersign reste toutefois un prototype de recherche, et son efficacité dépend de la sécurité de l’appareil, du système d’exploitation et de l’interface d’approbation.
Les équipes de sécurité doivent maintenir les contrôles d’approbation hors de portée des agents
Les organisations qui déploient des agents IA dotés de capacités de paiement doivent examiner davantage que les seules limites de dépenses configurées dans leurs applications.
Trois mesures de protection sont particulièrement importantes :
- Séparer les identifiants d’authentification : gardez les e-mails de vérification des portefeuilles, les identifiants de récupération et les autres méthodes d’approbation inaccessibles à l’agent. Vérifiez si des sessions de navigateur ou des outils connectés offrent un accès alternatif.
- Restreindre les autorisations de paiement : utilisez des limites de transaction et de destinataire appliquées indépendamment. Les agents ne doivent pas pouvoir modifier ces restrictions avec les mêmes autorisations que celles nécessaires aux paiements courants.
- Vérifier l’autorisation humaine : exigez une méthode d’approbation indépendante pour les actions sensibles, affichant le montant de la transaction et le destinataire avant la confirmation. Conservez une trace de ce qui a été approuvé.
Avant le déploiement, les équipes de sécurité doivent tester les tâches courantes comme les entrées malveillantes dans un environnement isolé :
- Créer une tâche qui dépasse le plafond configuré. Vérifiez si l’agent s’arrête et demande une approbation ou tente de modifier sa politique de dépenses.
- Inspecter tous les chemins menant aux identifiants d’approbation. Incluez les outils de messagerie, les sessions de navigateur authentifiées, les identifiants stockés et les méthodes de récupération. Supprimer un chemin ne suffit pas à établir que les autres sont inaccessibles.
- Tester une instruction intégrée à un e-mail. Vérifiez qu’un agent chargé de résumer des messages ne peut pas transformer une demande de paiement apparente en transfert autorisé.
Examinez les journaux produits afin de repérer les tentatives de modification de politique, les accès aux identifiants et les paiements. Un transfert bloqué ne constitue qu’une partie du résultat : les équipes doivent également savoir si l’agent a tenté d’obtenir des privilèges plus importants.
Ces recommandations s’inscrivent dans les recommandations plus générales en matière de sécurité des agents IA qui privilégient les contrôles d’accès plutôt que les seules instructions.
Un agent peut recevoir pour instruction de ne pas dépasser une limite de dépenses, mais cette instruction offre peu de protection si l’agent peut accéder de manière autonome aux identifiants nécessaires pour l’augmenter.
L’autorité de dépenser doit avoir sa propre limite
Les expériences contrôlées n’établissent pas l’existence de pertes financières généralisées et ne prouvent pas que tous les portefeuilles d’agents présentent la même faiblesse. Un autre incident impliquant un agent de recherche d’OpenAI utilisant une cryptomonnaie de test sans autorisation souligne également l’importance de vérifier ce que les agents peuvent faire au-delà des tâches qui leur sont assignées.
Pour les équipes de sécurité, le test de déploiement consiste à déterminer si un agent peut modifier les règles qui le contraignent. Les limites de dépenses doivent reposer sur un mécanisme d’approbation qui reste hors du contrôle de l’agent, même lorsque l’accomplissement d’une tâche par ailleurs légitime devient contraignant.
Vous souhaitez mieux comprendre comment travailler avec l’IA ? Les lecteurs d’eSecurity Planet bénéficient de 7 jours d’accès gratuit à The Neuron Academy, notre plateforme d’apprentissage pratique conçue pour aider les professionnels à utiliser l’IA avec davantage d’assurance au travail. Parcourir toutes les leçons →
Laissez-nous vous apprendre à parler à l’IA gratuitement ! Essayez notre cours de six minutes sur The Neuron Academy et découvrez quelques méthodes simples pour rédiger de meilleurs prompts et obtenir des résultats plus utiles avec l’IA, ou parcourez gratuitement pendant sept jours notre autre cours consacré à l’IA. Découvrez toutes les leçons ici →