L’IA d’entreprise inonde les SOC d’alertes bénignes et dissimule les risques réels

Les alertes liées à l’IA ont augmenté de 685 % en quatre mois

L’adoption de l’IA générative en entreprise fait émerger un nouveau problème pour les opérations de sécurité : les outils légitimes se comportent de plus en plus comme les logiciels que les règles de détection des SOC sont conçues pour repérer.

Une récente analyse d’environ 16,9 millions d’alertes SOC a recensé près de 73 000 alertes liées à des activités d’IA, soit 0,43 % du total. Cette proportion reste faible, mais le volume sous-jacent a augmenté chaque mois au cours de la période étudiée.

Pendant la période de référence stable, de février à juin 2026, les alertes liées à l’IA ont progressé de 685 %. L’accélération a été particulièrement marquée en mai 2026, ce qui laisse penser que les 0,43 % constituent un point de départ plutôt qu’une part durable de la charge de travail des SOC.

Les alertes se répartissaient en trois catégories très inégales :

• 94,1 % correspondaient à du bruit de détection, généralement des actions légitimes d’agents d’IA mal classées par les contrôles de sécurité existants.
• 5,8 % représentaient un risque réel pour la sécurité, notamment des configurations dangereuses ou une automatisation potentiellement risquée, sans preuve de compromission.
• 0,02 % étaient des attaques confirmées, principalement des campagnes d’hameçonnage et de fraude exploitant l’intérêt pour les produits d’IA.

Le problème immédiat n’est donc pas une épidémie d’attaquants compromettant les agents de programmation des entreprises. Il réside dans le télescopage entre des logiciels autonomes et une logique de détection conçue pour un monde où chaque commande sensible était lancée par un humain, un script ou un processus malveillant.

Ce télescopage mobilise les capacités d’investigation. Il peut également masquer le groupe, plus restreint, d’événements impliquant des identifiants exposés, une exécution sans restriction, des autorisations OAuth risquées ou de véritables opérations d’ingénierie sociale.

Les agents de programmation ressemblent étonnamment aux intrus

Les agents de programmation modernes ne se contentent pas de générer du texte. Selon leur configuration et la tâche qui leur est confiée, ils peuvent ouvrir des shells de commande, installer des paquets, rechercher des identifiants, exécuter des utilitaires de sécurité, manipuler des fichiers et exposer des services de développement sur des réseaux externes.

Chacune de ces actions peut être légitime. Prises dans leur ensemble, elles peuvent toutefois ressembler aux phases de découverte, d’accès aux identifiants et de commande et contrôle d’une intrusion.

Un client a été confronté à ce problème avec le binaire Windows Expand.exe. Une détection de transfert latéral d’outils impliquant cet exécutable représentait 55 % de toutes les alertes classées comme « critiques » dans la population examinée. L’enquête a établi que l’agent de programmation d’un développeur mettait en place un environnement shell, et ne transférait pas des outils d’attaque.

Les applications des fournisseurs d’IA elles-mêmes ont également déclenché des détections critiques. Un programme d’installation authentique et correctement signé d’Anthropic Claude Desktop a activé, dans plusieurs organisations, des règles EDR intitulées « Opérations de ransomware détectées » et « Téléchargement et exécution de PowerShell encodé ».

Aucune version des produits Claude Desktop, Cursor ou des autres applications d’IA observées n’a été communiquée. Les résultats ne doivent donc pas être interprétés comme révélant une vulnérabilité limitée à une version donnée. Ils concernent le comportement des applications, la configuration des utilisateurs et les contrôles de sécurité encadrant l’exécution de l’IA.

La gravité constituait un indicateur peu fiable de l’intention. Une classification critique peut signaler une commande techniquement dangereuse, mais elle ne permet pas d’établir qui l’a demandée, pourquoi elle a été exécutée ou si un attaquant était présent.

Les analystes des SOC ont désormais besoin d’un contexte d’exécution que les détections classiques sur les terminaux ne fournissent souvent pas. Il s’agit notamment du processus parent de l’agent, de la tâche de l’utilisateur, du dépôt concerné, de l’historique des commandes, du mode d’autorisation et de tout contenu non fiable traité avant le début de l’activité.

L’automatisation non sécurisée crée une exposition sans compromission

Le groupe des 5,8 % classés comme présentant un risque réel est probablement le plus important sur le plan opérationnel. Ces événements ne correspondaient pas à des compromissions confirmées, mais ils créaient des conditions susceptibles d’exposer des systèmes ou des identifiants.

La principale source de risque était constituée d’agents de programmation lancés avec les mécanismes de protection liés aux autorisations désactivés. Dans ce mode, l’agent peut exécuter des commandes sans demander à l’utilisateur d’approuver chaque action sensible.

Toutes les invocations examinées qui utilisaient ce contournement des autorisations étaient associées à des activités de développement légitimes. Cela ne rend pas la configuration sûre pour autant. Cela signifie que les organisations suppriment régulièrement un contrôle qui pourrait autrement interrompre des commandes destructrices ou destinées à dérober des identifiants.

Un agent fonctionnant sans demander de confirmation peut rester inoffensif lorsqu’il travaille sur du code de confiance. Le risque change lorsqu’il traite un dépôt malveillant, des instructions piégées, de la documentation contrôlée par un attaquant ou toute autre donnée d’entrée non fiable. Un incident de chaîne d’approvisionnement documenté publiquement avait déjà montré comment du code malveillant pouvait s’exécuter sans restriction dans de telles conditions.

Lorsque l’exécution sans surveillance est nécessaire, les organisations devraient ajouter des garde-fous programmatiques — souvent appelés harnais — qui appliquent la politique indépendamment du modèle. Ces contrôles peuvent bloquer l’extraction d’identifiants, restreindre les tunnels sortants, limiter les chemins accessibles en écriture et exiger une approbation pour les commandes à haut risque.

Plusieurs comportements observés montrent pourquoi ces mesures sont importantes.

Dans un environnement, un éditeur de code doté d’IA a lancé PowerShell, qui a lui-même lancé ngrok et créé un tunnel inverse nommé à l’aide du jeton d’authentification du développeur. L’intention apparente était bénigne, mais le résultat fournissait une connectivité accessible depuis l’extérieur vers un système de développement.

Dans un autre cas, un agent a tenté de récupérer son propre jeton ainsi que les identifiants cloud en exécutant :

security dump-keychain > /tmp/

Au lieu d’extraire un seul secret nécessaire, la commande a écrit le contenu du trousseau macOS dans un emplacement temporaire. Une tâche d’authentification ciblée s’est ainsi transformée en exposition généralisée d’identifiants.

Cursor a également été observé à l’origine d’une chaîne de processus plus préoccupante :

Cursor.exe → powershell.exe → rundll32.exe

La séquence utilisait la fonctionnalité MiniDump de comsvcs.dll, des scripts PowerShell temporaires et des commandes d’extraction de mémoire. Elle a peut-être été générée dans le cadre d’un débogage, mais cette technique peut exposer des identifiants et d’autres secrets stockés dans la mémoire des processus.

Ces cas ne peuvent pas être écartés sans précaution comme de simples faux positifs. Il s’agit d’activités légitimes aux conséquences comparables à celles d’une attaque.

L’exposition des données est moins visible que l’exécution sur les terminaux

Tous les risques liés à l’IA en entreprise ne produisent pas une arborescence de processus suspecte. Les employés connectent également des applications d’IA tierces via OAuth, s’authentifient avec des identités professionnelles et téléversent des informations de l’entreprise vers des services d’IA générative.

L’activité examinée comprenait des consentements OAuth accordés à ChatGPT dans plusieurs environnements, ainsi que des événements « Première connexion à une nouvelle application : OpenAI ». Un client a également généré un nombre important d’alertes de protection des données liées à des téléversements vers des plateformes d’IA générative.

La plupart des événements étaient bénins, mais l’autorisation n’élimine pas le risque d’exposition. Les autorisations OAuth peuvent permettre à un fournisseur externe de lire des données de l’entreprise, tandis qu’un compte d’IA compromis ou un scénario d’injection de prompt pourrait exploiter les permissions existantes.

Les téléversements posent un autre problème de visibilité. Une plateforme EDR peut observer un agent de programmation lancer rundll32.exe, sans pour autant détecter le texte sensible copié dans un service d’IA accessible depuis un navigateur. Les organisations ont donc besoin de données de télémétrie sur les identités, les services SaaS et la protection des données, en complément de la surveillance des terminaux.

Les équipes SOC devraient examiner l’étendue des autorisations OAuth liées à l’IA, identifier les événements de première utilisation et déterminer si l’employé avait une raison professionnelle d’autoriser l’application. Les politiques de gouvernance des données devraient également définir quelles informations peuvent être transmises à des modèles externes et comment détecter les violations.

Les véritables attaques ont utilisé l’IA comme appât, pas comme vecteur d’exploitation

Les activités malveillantes confirmées représentaient environ 0,02 % des alertes liées à l’IA. Aucune des compromissions détectées n’a été attribuée à l’agent d’IA d’une organisation.

Les alertes qui semblaient initialement montrer un agent exécutant Mimikatz, ouvrant un shell inverse ou dérobant des identifiants ont finalement été associées à des activités de développement légitimes ou à des activités bénignes mal classées par les règles de détection.

Les véritables attaquants ont plutôt exploité la crédibilité de marques d’IA connues.

Un e-mail de fraude au paiement utilisait l’objet « RE: Anthropic Engagement approval & payment » pour donner du poids à un faux scénario de contrat ou de facture. Anthropic servait de prétexte, mais n’était ni l’expéditeur ni l’origine de l’attaque.

Une autre campagne imitait une invitation à un espace de travail Google/Gemini Ads. Son infrastructure d’envoi et de réponse n’avait aucun lien avec Google, et le message dirigeait les destinataires vers le domaine suspect :

gemini-advertisers[.]com

La marque OpenAI apparaissait dans une fausse invitation au « OpenAI Partner Summit 2026 », envoyée depuis [email protected]. L’infrastructure légitime de Zoom contribuait à donner de la crédibilité au processus d’inscription. La marque OpenAI a également été utilisée dans un scénario d’hameçonnage par code d’appareil.

Ces incidents exigent une distinction analytique claire. Une alerte mentionnant un produit d’IA peut décrire l’exécution d’un agent, une automatisation dangereuse, une application externe recevant des données ou un attaquant sans rapport avec ces activités qui emprunte une marque reconnaissable.

Les SOC ont besoin d’une réduction du bruit fondée sur le contexte, pas d’exceptions générales

L’automatisation traitait déjà la majeure partie du volume observé. La plateforme de triage a attribué un verdict bénin à 79,8 % des alertes liées à l’IA et en a supprimé automatiquement 81,7 %. Seules 5,4 % sont parvenues à un analyste humain, tandis que les autres ont été conservées pour un suivi ultérieur.

Ces chiffres montrent que le triage automatisé est indispensable, mais qu’une mise sur liste blanche trop large serait dangereuse. Le même shell, tunnel ou commande d’accès aux identifiants peut correspondre à un développement courant, à un comportement dangereux d’agent ou à une compromission en cours.

Les équipes de sécurité devraient plutôt ajuster les contrôles en fonction de contextes précis :

1. Établir une référence des outils d’IA approuvés et des arborescences de processus attendues. Les programmes d’installation signés et les workflows d’agents connus peuvent être classés comme moins prioritaires sans exempter tous leurs processus enfants.
2. Détecter l’exécution avec contournement des autorisations. Les sessions d’agents sans restriction doivent être inventoriées, limitées et surveillées séparément.
3. Préserver la visibilité sur les commandes à haut risque. Les extractions de mémoire, exports de trousseaux, tunnels inverses et accès aux magasins d’identifiants doivent continuer à faire l’objet d’un examen, même lorsqu’ils sont lancés par un agent d’IA.
4. Corréler les données de télémétrie des terminaux et des identités. Les consentements OAuth, les nouvelles connexions à des applications d’IA et les téléversements inhabituels de données peuvent révéler des risques invisibles pour un EDR.
5. Former les employés à la fraude utilisant le thème de l’IA. Les demandes de paiement, invitations à des espaces de travail, inscriptions à des conférences et demandes de codes d’appareil doivent être vérifiées par un autre canal que le message reçu.
6. Mesurer la croissance plutôt que la part actuelle. Une catégorie qui a progressé de 685 % entre février et juin 2026 ne peut pas être dotée en personnel selon son volume antérieur.

L’objectif central n’est pas de détecter si l’IA est intervenue. Les SOC doivent déterminer si l’activité était attendue, dangereusement surdotée en autorisations ou malveillante — et le faire avant que l’automatisation bénigne n’ensevelisse le signal.