Agents doubles : les attaquants abusent de l’identité en armant les agents IA

Les agents IA deviennent rapidement les nouveaux utilisateurs et acheteurs d’Internet. De ChatGPT naviguant sur le web pour répondre aux questions, à Perplexity synthétisant des recherches, en passant par OpenClaw qui répond aux emails, ces agents IA sont partout, et dans certains cas, sont considérés par défaut comme dignes de confiance.

Mais cette confiance est maintenant exploitée par des fraudeurs. 

Les attaquants savent désormais qu’ils peuvent détourner ces identités de confiance, transformant ainsi les agents IA en complices de leurs attaques. En manipulant les outils IA pour visiter des URL malveillantes ou soumettre des invites conçues, les mauvais acteurs peuvent mener des reconnaissances, sonder les vulnérabilités et exécuter des attaques, tout en se cachant derrière la légitimité de services IA bien connus.

Notre équipe de recherche sur les menaces, Galileo, a identifié une tendance inquiétante : les attaquants abusent systématiquement de l’infrastructure des agents IA pour contourner les contrôles de sécurité traditionnels. Récemment, nous avons rapporté deux cas. 

Premièrement, nous avons observé des plateformes IA légitimes comme Grok de xAI se faire passer pour des navigateurs humains, tournant à travers des IP résidentielles, et lançant des récupérations distribuées agressives qui imitent le comportement des bots malveillants. Deuxièmement, nous avons documenté une augmentation de près de 600 000 requêtes en janvier 2025 qui semblaient être des références d’utilisateurs légitimes de ChatGPT, mais étaient en réalité des bots usurpant l’en-tête “Referer” pour contourner les filtres de sécurité.

De plus, Galileo a rapporté que 80% des agents IA ne se déclarent pas correctement lorsqu’ils visitent des sites web. 

Ce qui suit sont quatre autres cas réels que notre équipe a observés, révélateurs de la manière dont ce vecteur d’attaque est exploité dans la nature.

Étude de cas 1 : Perplexity utilisé pour XSS réfléchi

La cible : un grand site e-commerce d’électronique

Dans cet incident, un attaquant a utilisé l’agent de navigation de Perplexity pour tenter une attaque de Cross-Site Scripting réfléchi (XSS). Le but d’une attaque XSS est d’injecter des scripts malveillants dans des sites web de confiance.

• L’attaquant a conçu une URL contenant une charge utile JavaScript et l’a probablement fournie à Perplexity, peut-être en demandant à l’IA de “résumer ce lien”.
• La requête visait une page produit, injectant le script dans le paramètre couleur : %3Cscript%3Ealert%2812%29%3C%2Fscript%3E (qui se décode en <script>alert(12)</script>).
• Pour un filtre de sécurité standard, cette requête ressemblait à un crawler légitime de Perplexity (Perplexity-User) provenant d’une IP cloud documentée (18.97.43.83).

Étude de cas 2 : Meta-ExternalAgent (Facebook) comme scanner de vulnérabilités

La cible : un site web de tourisme

Les bots des réseaux sociaux récupèrent constamment des aperçus de liens partagés par les utilisateurs. Les attaquants le savent et l’utilisent pour tromper des plateformes comme Meta afin de sonder des sites web pour des vulnérabilités en leur nom.

• L’attaquant a déclenché le crawler de Meta pour visiter une URL spécifique et armée sur le site de la victime.
• La sonde a enterré une charge utile javascript:alert(xss) profondément dans une structure d’URL imbriquée. La requête visait un script de soumission de livre d’or : /submit/?title=Guestbook…&url=…javascript%3Aalert%28xss%29….
• La requête provenait d’une IP Meta (57.141.0.78) et s’est correctement identifiée comme un Meta-ExternalAgent. Cependant, la charge utile était une sonde XSS classique.

Étude de cas 3 : OpenAI et injections SQL

La cible : un portail d’actualités financières

Peut-être l’exemple le plus intéressant implique l’IA la plus célèbre du monde, ChatGPT, qui semble avoir été utilisée pour effectuer une attaque par injection SQL (SQLi).

• L’attaquant a utilisé l’infrastructure d’OpenAI pour envoyer une injection SQL aveugle basée sur le temps classique. Ce type d’attaque demande à la base de données de “dormir” pendant un temps défini (par exemple, 15 secondes) pour confirmer si la base de données est vulnérable.
• Nous voyons une tentative claire d’injecter des commandes dans une base de données PostgreSQL : …OR 726=(SELECT 726 FROM PG_SLEEP(15))–.
• La requête provenait d’une adresse IP documentée d’OpenAI (74.7.242.34) et s’est identifiée comme GPTBot.

Étude de cas 4 : Comet Browser utilisé pour la création de faux comptes

La cible : un portail de connexion de services financiers

• Cela ciblait le point de terminaison de création de compte (/signup) plutôt que les pages de contenu public. Le but était probablement d’automatiser l’enregistrement de faux comptes pour un futur usage abusif.
• Contrairement aux scrapers à haute vitesse, ce bot était programmé pour être furtif. Il exécutait des requêtes à un rythme régulier, “humain” d’environ une requête toutes les 6 à 8 secondes pour échapper aux limitations de taux simples.
• Malgré le timing furtif, il s’agit de la même session. Un navigateur IA légitime ne clique pas de manière répétée sur un bouton “Inscription” pendant plusieurs minutes avec le même ID de session.

Les implications de l’utilisation des agents IA pour la fraude

La détection traditionnelle des bots repose fortement sur le scoring de réputation. Les acteurs connus et fiables sont mis sur liste blanche, les schémas suspects sont signalés. Mais que se passe-t-il lorsque l’acteur “connu et fiable” livre une charge utile malveillante ? Les équipes de sécurité sont confrontées à un choix inconfortable : bloquer les agents IA légitimes et casser la fonctionnalité pour les vrais utilisateurs, ou les laisser passer et accepter le risque.

Cela crée un angle mort dangereux. Les attaquants savent que les requêtes provenant d’une infrastructure IA vérifiée sont plus susceptibles de contourner les WAF, les limiteurs de taux, et certains systèmes de gestion des bots. Ils exploitent les mécanismes de confiance que nous avons intégrés dans l’architecture de sécurité moderne.

Le problème du proxy

Ces attaques représentent une nouvelle forme d’abus de proxy. Contrairement aux VPN traditionnels ou aux proxies résidentiels, l’infrastructure des agents IA offre :

• légitimité : adresses IP réelles détenues par des entreprises de confiance ;
• documentation : plages d’IP et chaînes d’agent utilisateur vérifiées publiquement ;
• dénégation plausible : les requêtes semblent être un comportement normal d’agent IA ;
• échelle : accès à une infrastructure de niveau entreprise sans la maintenir.

Les attaquants ne forcent pas l’entrée, ils sont invités, déguisés en outils sur lesquels nous avons tous appris à compter.

Risques à l’échelle de l’écosystème

À mesure que les agents IA deviennent plus capables et autonomes, ce problème ne fera que s’intensifier. Nous voyons déjà :

• exploitation automatisée : agents IA capables de découvrir et de sonder indépendamment les vulnérabilités ;
• attaques à grande échelle : attaques distribuées sur plusieurs plateformes IA simultanément ;
• évolution de l’évasion : les attaquants affinent les invites pour mieux déguiser l’intention malveillante.

Les quatre cas documentés ici représentent probablement juste la pointe visible d’un paysage de menaces beaucoup plus vaste. À mesure que le commerce agentique gagne en popularité, ces attaques sont susceptibles de devenir plus sophistiquées, y compris des types de fraude de paiement. 

Ce que vous pouvez faire pour protéger votre entreprise

Les attaquants ont réalisé que le moyen le plus rapide de passer par la porte d’entrée n’est pas de crocheter la serrure ; c’est d’arriver dans un véhicule de confiance. 

Les exemples ci-dessus sont la preuve d’une exploitation systématique de l’écart de confiance entre les capacités de l’IA et la détection de sécurité. À mesure que les agents IA deviennent plus intégrés dans notre façon de naviguer, de rechercher et d’interagir en ligne, ce vecteur d’attaque ne fera que devenir plus attrayant pour les acteurs malveillants.

Les équipes de sécurité et de lutte contre la fraude doivent s’adapter. Faire confiance à l’identité seule n’est plus suffisant. Nous avons besoin de défenses qui peuvent :

• distinguer le comportement légitime des agents IA de l’abus malveillant ;
• détecter les schémas anormaux même lorsqu’ils proviennent d’une infrastructure de confiance ;
• valider le contexte et l’intention derrière les requêtes, pas seulement leur source ;
• répondre de manière dynamique sans casser la fonctionnalité légitime de l’IA.

La bonne nouvelle ? Ces attaques sont détectables, mais seulement si vous les cherchez avec la bonne approche. Chez DataDome, nous suivons de près ce vecteur de menace et développons des capacités de détection qui comprennent non seulement qui fait une requête, mais ce qu’ils essaient d’accomplir.

Votre site est-il vulnérable aux abus des agents IA ? Demandez un scan de vulnérabilité gratuit pour voir comment les attaquants pourraient exploiter l’infrastructure IA pour cibler vos applications — ou téléchargez notre guide du commerce agentique pour apprendre comment protéger votre entreprise à l’ère des agents IA.