La nouvelle méthode utilisée par les pirates pour tromper les assistants financiers basés sur l'IA
par
Dernière mise à jour : Temps de lecture : 7 min
Points clés à retenir
- Les pirates informatiques déploient activement des charges utiles d'injection indirecte de commandes dans des documents courants afin de détourner des assistants financiers basés sur l'IA.
- Contrairement à la fraude traditionnelle qui vise à tromper les êtres humains, cette attaque cible les systèmes d'IA automatisés qui exécutent les commandes instantanément, sans se douter de rien.
- Les agents IA capables d'effectuer des transferts d'argent, de déclencher des flux de travail ou d'accéder à des données clients soumises à une réglementation constituent les cibles les plus prisées par les cyberattaquants.
- Les alertes système ne suffisent pas à elles seules à garantir la sécurité d'un agent ; il est donc indispensable d'appliquer rigoureusement le principe du « privilège minimal » et d'imposer des validations humaines obligatoires.
- L'e-mail étant le principal vecteur de diffusion de ces charges utiles, une application stricte du protocole DMARC est nécessaire pour authentifier les messages avant qu'une IA ne les traite.
Des chercheurs en sécurité qui analysaient du contenu circulant sur le web ont récemment mis au jour un élément alarmant. Ils ont découvert des instructions cachées, destinées non pas à un être humain, mais à tout agent d’IA susceptible de lire le texte. L’une d’entre elles consistait en une charge utile pleinement exploitée, spécialement conçue pour amener un assistant IA capable d’effectuer des paiements à exécuter une transaction d’un montant fixe de 5 000 dollars. Il ne s’agissait pas d’une démonstration contrôlée en laboratoire, mais bien d’une véritable charge utile détectée dans la nature.
Au cours des dix dernières années, les établissements financiers ont consacré d'énormes ressources à former leurs employés à ne pas donner suite à des e-mails trompeurs. Aujourd’hui, bon nombre de ces mêmes établissements ont intégré des assistants basés sur l’IA à ces mêmes boîtes de réception. Ces assistants lisent tout, ne remettent rien en question et opèrent souvent avec les autorisations accordées par les membres du personnel qui les utilisent.
Cette technique est appelée « injection indirecte par invite ». Elle marque un changement radical dans le mode opératoire de la fraude financière. Vous trouverez ci-dessous une analyse détaillée du fonctionnement de cette attaque, des véritables points faibles des banques, des conclusions auxquelles les chercheurs sont parvenus en 2026, ainsi que des contrôles architecturaux nécessaires pour y mettre un terme.
Qu'est-ce que l'injection rapide ?
L'injection de prompt se produit lorsqu'un pirate manipule un système d'IA pour lui faire exécuter des commandes non prévues. L'injection directe se produit lorsqu'un utilisateur saisit directement des instructions malveillantes dans la fenêtre de discussion. L'injection indirecte de prompt est bien plus dangereuse. Elle se produit lorsque des instructions sont dissimulées dans du contenu externe que l'assistant lit automatiquement, comme un e-mail entrant, une facture jointe ou une page Web.
La raison principale pour laquelle cela fonctionne est simple : les systèmes d'IA actuels ne parviennent pas à distinguer de manière fiable les instructions des données. Chaque document traité par un assistant est considéré comme une entrée potentielle, ce qui signifie que n'importe quel fichier externe peut servir de vecteur d'attaque.
Pourquoi les assistants financiers basés sur l'IA constituent une cible de grande valeur
Mayur Sewani, chercheur senior en sécurité chez Forcepoint, résume parfaitement le problème: l’impact est proportionnel au niveau de privilèges. Un assistant IA qui se contente de résumer les comptes rendus de réunion présente un risque faible. En revanche, un assistant capable d’envoyer des e-mails, de déclencher un workflow ou d’effectuer des virements bancaires constitue une cible critique à fort impact.
Les assistants actuellement déployés dans le secteur financier relèvent de plus en plus souvent de cette deuxième catégorie. Ils extraient les dossiers clients, analysent les documents de conformité, lancent des workflows internes et, dans certains cas, interviennent directement sur les systèmes de paiement.
Dans le secteur de la vente au détail, une instruction injectée peut simplement entraîner la fuite d'un document. Dans une banque, cette même instruction injectée peut permettre de transférer des fonds, d'exposer des données clients soumises à une réglementation stricte ou de fausser une décision relative à la conformité « Know Your Customer » (KYC).
Dans quels cas un établissement financier est-il réellement exposé ?
Le modèle de menace change radicalement dès lors qu'un agent d'IA se voit accorder l'accès aux systèmes bancaires. Le tableau ci-dessous détaille les domaines opérationnels spécifiques dans lesquels les établissements sont aujourd'hui exposés.
| Zone d'intervention | Vecteur d'attaque | Impact potentiel sur l'activité |
|---|---|---|
| Opérations de paiement | Un assistant disposant de droits de validation ou de lancement lit un document d'instruction entrant contenant du texte masqué. | L'agent est amené, par la ruse, à transférer des fonds vers le compte d'un pirate en utilisant les autorisations de l'opérateur humain. |
| Intégration des clients et KYC | Un assistant chargé de résumer les documents transmis reçoit un texte caché lui ordonnant de supprimer ou de modifier une conclusion critique relative aux risques. | Un client à haut risque contourne les contrôles de conformité. Des charges utiles conçues pour la suppression de contenu ont déjà été recensées dans la nature. |
| Service client | Une instruction injectée nous parvient via un ticket d'assistance ou un message de chat envoyé par un client. | Cette invite malveillante exécute des commandes en utilisant les privilèges élevés du service d'assistance accordés à l'assistant IA. |
| Recherche interne de connaissances | Des agents ayant accès à des documents relatifs à des transactions, à des dossiers de crédit ou à des documents destinés au conseil d'administration cliquent sur un lien malveillant ou ouvrent un document malveillant. | L'IA extrait les informations confidentielles auxquelles elle a accès et les transmet à un serveur contrôlé par un pirate. |
| Correspondance avec les fournisseurs | Des charges utiles cachées sont intégrées dans les e-mails entrants provenant de tiers compromis. | Les pirates exploitent le canal entrant bénéficiant du plus haut niveau de confiance pour transmettre directement des instructions aux agents programmés pour traiter les factures des fournisseurs. |
Ce que les chercheurs ont réellement démontré en 2026
Cette menace n'est plus seulement théorique. Des chercheurs en sécurité ont minutieusement documenté l'exploitation de ces vulnérabilités dans des environnements d'entreprise réels en 2026.
Les dix charges utiles de Forcepoint en circulation (avril 2026)
Le 23 avril 2026, les chercheurs de Forcepoint ont publié les résultats de leurs analyses concernant dix charges utiles d’injection indirecte par invite repérées dans la nature. Ces charges utiles couvraient la suppression de contenu, le détournement d’attribution, l’exécution de commandes Unix ciblant des outils de développement et le vol de clés API. Plus critique encore pour les banques, cette étude décrivait en détail une charge utile de fraude aux paiements visant des agents d’IA dotés de capacités de paiement intégrées. La charge utile contenait des instructions intégrées visant à déclencher une transaction PayPal d’un montant fixe de 5 000 dollars. M. Sewani a qualifié cette charge utile d’« arme » destinée à une exécution immédiate, et non de simple sonde de recherche inoffensive.
L'attaque « Reprompt » contre Microsoft Copilot (janvier 2026)
Le 15 janvier 2026, Varonis a détaillé l’attaque « Reprompt ». Il s’agissait d’une chaîne d’exfiltration de données en un seul clic ciblant Microsoft Copilot. L’attaque utilisait un paramètre d’URL pour injecter des instructions. L’assistant recevait l’ordre de répéter des actions afin de contourner les mesures de sécurité, établissant ainsi un échange continu avec un serveur contrôlé par l’attaquant pour exfiltrer des données. L’attaque était déclenchée par un lien Copilot d’apparence légitime envoyé par e-mail, ne nécessitant qu’un simple clic de la part de la victime. Microsoft a rapidement corrigé cette vulnérabilité, et la version entreprise de Microsoft 365 Copilot n’aurait pas été affectée ; toutefois, ce mécanisme a démontré qu’un agent n’hésiterait pas à divulguer tout contexte interne auquel il a accès s’il est induit en erreur.
La tendance générale
Ce problème ne concerne pas un seul fournisseur. Des attaques par injection ont été menées avec succès contre des outils de codage basés sur des agents via des commentaires dans le code source, et les contournements des mécanismes de protection sont bien documentés pour plusieurs modèles majeurs.
Il s'agit d'une attaque de type « Business Email Compromise », mais visant une cible différente
Le schéma d'une attaque par injection indirecte est, sur le plan fonctionnel, identique à celui du « Business Email Compromise » (BEC). Une instruction frauduleuse arrive en donnant l'impression d'être tout à fait légitime, et quelqu'un y donne suite. La différence essentielle réside dans le fait que ce « quelqu'un » est désormais un logiciel. L'IA n'a aucune hésitation, aucun pressentiment que quelque chose ne va pas, et aucun instinct qui la pousserait à décrocher le téléphone pour vérifier une demande inhabituelle auprès du directeur financier.
Heureusement, les contrôles déjà mis en place par les institutions pour les virements BEC s’appliquent directement à ce nouveau problème. La vérification hors bande, l’approbation par plusieurs personnes pour les paiements ou les changements de bénéficiaire, ainsi que les plafonds stricts imposés à toute action automatisée isolée restent vos meilleures défenses. Un agent IA doit fonctionner dans le cadre de ces contrôles existants, et en aucun cas en dehors de ceux-ci.
Commandes : réduire le rayon d'explosion d'un agent IA
Les architectes en sécurité et les équipes chargées de la gestion des risques doivent mettre en place des contrôles structurels autour des agents d'IA. On ne peut pas se contenter des seules alertes du système pour sécuriser une plateforme financière.
| Principe de régulation | Mise en œuvre pratique | Objectif de sécurité |
|---|---|---|
| Principe du moindre privilège | Limiter strictement les pouvoirs en matière de paiement, d'envoi et d'approbation. | Veillez à ce que la plupart des assistants ne disposent que d'un accès en lecture, afin de limiter les dégâts qu'ils pourraient causer en cas de compromission. |
| Intervention humaine | Exiger une validation humaine pour les actions ayant des conséquences importantes. | Veillez à ce que la mesure de sécurité porte sur l'action elle-même. Tout paiement doit toujours nécessiter qu'une personne clique sur « Valider ». |
| « Zero Trust » pour le contenu | Considérez tous les documents importés (PDF, e-mails, documents) comme des données utilisateur non fiables. | Empêcher l'agent d'exécuter du texte brut extrait de fichiers externes sans validation préalable. |
| Journalisation des API et des outils | Conserver des pistes d'audit rigoureuses indiquant précisément ce que l'agent a lu et ce qu'il a exécuté. | Garantir une visibilité rapide sur les éléments de preuve lors d'une enquête menée dans le cadre d'une intervention en cas d'incident. |
| Filtrage strict des sorties | Bloquez les connexions sortantes vers des adresses IP inconnues ou non fiables. | Bloquez les attaques telles que la chaîne « Reprompt », qui reposent sur l'accès à un serveur contrôlé par l'attaquant pour exfiltrer des données. |
| Flux de travail unifiés | Intégrez des agents IA dans vos systèmes actuels de contrôle des paiements. | Éviter la mise en place de processus d’approbation parallèles et non testés qui contourneraient les contrôles de sécurité existants. |
Soyez réalistes en matière de détection. Le filtrage des documents entrants à la recherche d’expressions connues déclenchant l’injection de commandes n’est qu’un simple obstacle mineur. Les attaquants se contenteront de reformuler leurs charges utiles.
Vous ne pouvez pas vous en sortir en donnant des indications
Tant qu’un agent d’IA peut être influencé par du texte, les seuls contrôles durables sont d’ordre structurel. Il faut limiter physiquement ce que l’agent est autorisé à faire, les systèmes auxquels il peut accéder et les actions qui nécessitent impérativement l’intervention d’un humain. De meilleures consignes système et des garde-fous mis en place par les fournisseurs augmentent certes le coût d’une attaque, mais ils n’éliminent pas cette catégorie de vulnérabilité. Pour un établissement financier soumis à une réglementation, cette distinction représente la différence entre un contrôle que vous pouvez prouver à un auditeur et un autre dont vous ne pouvez que supposer qu’il fonctionne.
Ce que laissent entendre les superviseurs
Les autorités de régulation suivent cette évolution de très près. Les recommandations de la FINRA de 2026 sur les thèmes clés de l’intelligence artificielle et les rapports de surveillance ont spécifiquement identifié l’IA agentique comme une catégorie distincte de risque en matière de supervision. Étant donné que ces systèmes mènent des actions autonomes plutôt que de se contenter de générer du texte, les entreprises doivent conserver des pistes d’audit complètes et mettre en place des contrôles humains avant toute exécution. La FINRA a également souligné les risques liés à l’IA fantôme et la nécessité de traiter les plateformes d’IA tierces comme des fournisseurs à haut risque (comme détaillé dans un article complémentaire de Smarsh).
L'OCC a également laissé entendre que des recommandations exhaustives sur la gouvernance des modèles d'IA à l'intention des banques étaient en préparation. Par ailleurs, le FS-ISAC a publié une série de livres blancs sur les risques liés à l'IA dans le secteur financier, traitant notamment de la taxonomie de l'IA adversaire et de l'évaluation des fournisseurs. Il convient de noter que ces documents ont été publiés en février 2024 et sont antérieurs à la vague des IA « agentiques », mais qu'ils restent utiles pour acquérir des bases solides sur le secteur.
Les responsables hiérarchiques et les architectes en sécurité réclament en substance exactement la même chose : une supervision humaine vérifiable des actions de l'IA ayant des conséquences importantes. Cet alignement réglementaire constitue l'argument interne le plus solide dont dispose un responsable de la sécurité pour obtenir les financements nécessaires à la mise en place de ces contrôles.
Le rôle de l'authentification des e-mails
Il est important de préciser clairement ce que l'authentification des e-mails ne permet pas de faire. Le protocole DMARC avec le paramètre p=reject n'empêche pas l'injection de messages ; il n'inspecte pas le contenu des messages et ne limite pas les actions autorisées à un agent IA.
Cependant, les charges utiles d’injection les plus susceptibles de réussir face à l’assistant IA d’une banque sont celles qui semblent provenir du directeur financier, d’une banque correspondante ou d’un prestataire de paiement de confiance. Le courrier électronique est le principal vecteur par lequel du contenu non fiable parvient à ces systèmes d’IA. La chaîne Reprompt divulguée a été transmise via un lien envoyé par e-mail. Lorsqu’un agent IA traite des e-mails sans aucun contrôle humain, l’authenticité de l’expéditeur devient le tout dernier signal de confiance dans le processus.
Le secteur des services financiers affiche l’un des taux d’adoption du protocole DMARC les plus élevés de tous les secteurs, mais malheureusement, c’est aussi l’un de ceux où son application est la moins rigoureuse. Si vous intégrez l’IA à une boîte de réception, la mise en place d’une authentification stricte des e-mails n’est plus une option. Pour en savoir plus sur la sécurisation de ce vecteur d’attaque, consultez nos études consacrées au phishing dans le secteur des services financiers et à l’application du protocole DMARC par les institutions financières.
Conclusion
Au cours de la dernière décennie, le maillon faible de la sécurité des e-mails financiers était le collaborateur qui cliquait sur un lien malveillant. Aujourd’hui, les institutions ont confié cette même boîte de réception à des logiciels qui lisent tout, ne remettent rien en question et disposent de véritables droits d’accès au système. Les premières charges utiles conçues spécifiquement pour exploiter ces agents automatisés sont déjà à l’œuvre dans la nature.
La solution nécessite une approche par niveaux. Vous devez limiter les actions physiques autorisées aux agents IA, veiller à ce que des êtres humains restent impliqués dans les décisions importantes, intégrer ces agents à vos contrôles de paiement existants et authentifier rigoureusement toutes les données qui leur parviennent.
Vérifiez le niveau de sécurité de votre domaine grâce à notre outil de vérification des enregistrements DMARC ou rendez-vous sur notre page dédiée aux solutions pour les services financiers pour en savoir plus sur la sécurisation de vos canaux entrants.
Foire aux questions
Qu'est-ce que l'injection immédiate, en termes simples ?
Il s'agit d'une cyberattaque dans laquelle un pirate informatique dissimule des instructions secrètes dans un document ou un e-mail. Lorsqu'un assistant IA lit ce fichier, il exécute, à son insu, les commandes cachées.
Une commande vocale peut-elle permettre à un assistant IA d'effectuer un virement bancaire ?
Oui. Si un agent IA s'est vu accorder l'accès aux systèmes de paiement et qu'il n'est soumis à aucun contrôle d'approbation impliquant une intervention humaine, une instruction cachée peut le contraindre à effectuer des virements non autorisés.
L'injection « prompt » a-t-elle déjà été utilisée dans le cadre d'attaques réelles ?
Oui. En avril 2026, des chercheurs ont recensé dix charges utiles distinctes d'injection indirecte de commandes dans un environnement réel, dont l'une était spécifiquement conçue pour effectuer une transaction PayPal d'un montant de 5 000 dollars.
En quoi l'« injection rapide » diffère-t-elle de la « compromission des e-mails d'entreprise » ?
Le mode opératoire est similaire, mais la victime est différente. Au lieu de piéger un employé humain pour qu'il effectue un virement, le pirate trompe un agent logiciel automatisé basé sur l'IA qui exécute la demande instantanément.
Quels contrôles une banque devrait-elle mettre en place pour un agent d'IA ?
Les banques doivent appliquer le principe du « droit d'accès minimal », exiger une validation humaine pour toutes les actions ayant des conséquences importantes, mettre en place un filtrage strict des sorties de réseau et consigner chaque appel d'API effectué par l'agent.
Le protocole DMARC ou l'authentification des e-mails permettent-ils d'empêcher l'injection de messages instantanés ?
Non, DMARC ne peut pas analyser le contenu d'un e-mail pour détecter d'éventuelles invites cachées. En revanche, il empêche d'emblée les e-mails usurpés d'atteindre l'IA, éliminant ainsi un vecteur de diffusion majeur de l'attaque.
Spécialiste du contenu chez PowerDMARC
Milena est une rédactrice et créatrice de contenu qualifiée qui possède plus de 7 ans d'expérience dans la création de contenu attrayant sur les technologies de l'information, la cybersécurité, les événements virtuels, etc. Elle est diplômée d'institutions prestigieuses telles que la New York University Abu Dhabi, l'UWC China et le Collège d'Europe.
Derniers messages de Milena Baghdasaryan (voir tous)
- Élaborer un plan d'intervention en cas d'incident à partir de zéro - 8 septembre 2026
- La nouvelle méthode utilisée par les pirates pour tromper les assistants financiers basés sur l'IA - 7 septembre 2026
- Meilleures pratiques en matière de sécurité DNS : une liste de contrôle complète pour le renforcement de la sécurité - 7 septembre 2026
