Les outils d’intelligence artificielle commencent à modifier un élément très concret du fonctionnement des Security Operations Centers : la signification même d’un comportement suspect.
Un agent de développement peut ouvrir un shell, télécharger des composants, consulter un magasin de secrets, lancer PowerShell ou établir un tunnel réseau. Pris séparément, plusieurs de ces comportements ressemblent fortement aux étapes d’une intrusion. Pourtant, ils peuvent parfaitement correspondre à l’exécution normale d’une tâche confiée à un agent IA.
Une étude publiée par Intezer (When the Whole Company Adopts AI: What It Does to Your SOC) en août 2026 donne une première mesure de ce phénomène. Sur environ 16,9 millions d’alertes de sécurité analysées, près de 73 000 étaient liées à des outils ou agents d’intelligence artificielle. Elles ne représentaient encore que 0,43 % du volume total, mais leur nombre a progressé de 685 % entre février et juin 2026.
Le volume reste donc marginal, le problème qu’il révèle l’est beaucoup moins.
Car avec les agents IA, un SOC ne doit plus seulement déterminer si une action est dangereuse. Il doit aussi comprendre qui — ou quoi — l’a exécutée, avec quelles permissions et dans quel contexte.
Des alertes encore marginales, mais presque toujours trompeuses
Les chiffres publiés par Intezer doivent être interprétés avec prudence. Ils proviennent des environnements analysés par l’éditeur et ne constituent pas une mesure universelle de l’ensemble des SOC. Ils sont néanmoins particulièrement révélateurs de la composition des alertes observées.
Intezer classe les événements liés à l’IA en trois catégories :
- 94,1 % correspondent à du bruit, c’est-à-dire à une activité légitime ayant déclenché une détection ;
- 5,8 % constituent un risque de sécurité réel sans compromission confirmée ;
- 0,02 % correspondent à de véritables attaques.
Le premier constat est donc presque contre-intuitif. L’adoption des agents IA n’a pas provoqué, dans cet échantillon, une vague d’attaques menées par des agents autonomes. Elle a surtout provoqué une vague de comportements légitimes qui ressemblent à des attaques.
En production, 79,8 % des alertes liées à l’IA ont reçu un verdict bénin et 81,7 % ont été automatiquement supprimées. Seules 5,4 % ont finalement été transmises à un analyste humain.
Pour les SOC, le premier risque pourrait donc être beaucoup plus classique que les scénarios d’attaque autonome souvent associés à l’intelligence artificielle : l’augmentation du bruit opérationnel.
Quand un développeur ressemble à un attaquant
Le problème apparaît particulièrement avec les agents de développement. Pour accomplir les tâches qui leur sont confiées, ces outils peuvent interagir directement avec le poste de travail et son environnement : créer des processus, lancer des commandes, installer des packages, accéder à des fichiers ou utiliser des credentials. Or les mécanismes de détection ont été construits à une époque où ce type d’enchaînement possédait souvent une signification différente.
Un processus inattendu qui lance PowerShell, récupère des informations sensibles puis établit une connexion vers Internet mérite normalement l’attention, mais que se passe-t-il lorsque cette séquence est produite par un agent auquel un développeur vient simplement de demander de préparer son environnement ?
Intezer cite notamment une détection critique déclenchée par l’utilisation de Expand.exe. À elle seule, cette règle représentait 55 % des alertes liées à l’IA ayant reçu un verdict critique dans l’environnement concerné. L’analyse a finalement montré qu’un agent de développement préparait normalement un environnement shell.
La règle n’était pas nécessairement mauvaise, le contexte avait changé.
C’est probablement l’un des principaux défis que les agents IA vont imposer aux systèmes de détection existants. Un comportement qui constituait auparavant un signal suffisamment inhabituel pour justifier une alerte peut devenir une activité quotidienne parfaitement légitime.
Un agent peut être dangereux sans être malveillant
Ce constat ne signifie toutefois pas que les alertes doivent simplement être supprimées, c’est précisément là que l’analyse devient intéressante. Entre le faux positif et l’attaque existe une troisième catégorie : l’action légitime qui crée néanmoins une exposition de sécurité réelle.
Intezer rapporte plusieurs exemples.
Dans certains environnements, des agents étaient exécutés avec des options désactivant leurs mécanismes de demande de permission. Dans un autre cas, un outil de développement a lancé ngrok et ouvert un tunnel vers Internet en utilisant le token de l’utilisateur.
Un agent macOS souhaitant récupérer un secret particulier a, quant à lui, exporté l’intégralité du trousseau dans un fichier temporaire. L’objectif pouvait être parfaitement légitime ; la méthode exposait inutilement beaucoup plus de secrets que nécessaire.
Le même problème apparaît avec les autorisations OAuth et les services d’IA générative. L’étude a observé des consentements accordés à ChatGPT ainsi que des transferts de données vers des services externes. Là encore, il ne s’agit pas nécessairement d’incidents, mais une donnée d’entreprise quitte potentiellement le périmètre habituel de contrôle et un service tiers reçoit de nouvelles autorisations.
Le changement est important : un agent n’a pas besoin d’être compromis pour introduire un risque. Il lui suffit parfois d’accomplir correctement sa mission avec des permissions trop larges ou une méthode inadaptée. Le problème devient alors moins celui de l’intention que celui de la latitude accordée à l’agent.
Les véritables attaques restent, pour l’instant, ailleurs
L’étude apporte aussi un utile contrepoids aux scénarios les plus alarmistes. Parmi les attaques réellement confirmées, Intezer n’a identifié aucune compromission directement provoquée par l’agent interne d’une organisation. Les attaques observées exploitaient plutôt l’adoption de l’IA comme prétexte.
Des campagnes de phishing usurpaient ainsi les marques OpenAI, Anthropic ou Gemini pour présenter de fausses invitations, demandes de paiement ou procédures d’inscription. Plus les utilisateurs s’habituent à utiliser ces services dans leur travail, plus leurs marques deviennent crédibles dans une tentative d’hameçonnage.
Un autre cas impliquant Cursor est plus ambigu et probablement plus révélateur de la difficulté future. L’IDE a exécuté une chaîne comprenant PowerShell puis rundll32.exe, associée à une technique permettant d’accéder aux credentials présents en mémoire. L’action pouvait être liée à une tâche de développement ou de dépannage, mais elle créait malgré tout un risque sérieux d’exposition de secrets.
Une fois encore, la frontière entre incident, comportement légitime et mauvaise pratique devient beaucoup moins évidente.
Les règles de détection ont été écrites pour un autre monde
Jusqu’à présent, de nombreuses détections reposaient implicitement sur une hypothèse assez raisonnable : si une action sensible est exécutée sur le poste d’un utilisateur sans que celui-ci semble l’avoir déclenchée, il faut envisager une compromission.
L’agent IA fragilise cette hypothèse.Il agit au nom de l’utilisateur, avec ses droits et souvent depuis sa propre machine, mais peut prendre une série de décisions intermédiaires que l’utilisateur n’a jamais explicitement demandées ni même observées.
L’utilisateur a peut-être demandé : « Configure cet environnement pour mon projet. » L’agent a ensuite décidé seul quels outils lancer, quels fichiers consulter et quelles commandes exécuter. Du point de vue du SOC, les traces correspondent toujours au compte et à la machine de l’utilisateur. L’utilisateur n’est plus nécessairement l’auteur opérationnel de chacune des actions observées.
La question devient donc nouvelle : Le compte a-t-il été compromis, l’utilisateur a-t-il exécuté cette commande ou son agent l’a-t-il exécutée pour lui ?
Ces trois situations peuvent produire des traces techniques proches tout en exigeant des réponses totalement différentes.
Le contexte devient aussi important que le comportement
Cette évolution ne rend pas les mécanismes de détection traditionnels inutiles, elle oblige plutôt à leur ajouter davantage de contexte. Un SOC devra progressivement connaître :
- quels agents IA sont autorisés ;
- quels utilisateurs peuvent les employer ;
- quelles ressources ils sont supposés atteindre ;
- quelles permissions leur sont accordées ;
- quels outils ou commandes font partie de leur fonctionnement normal ;
- et quelles actions doivent rester suffisamment inhabituelles pour déclencher une investigation.
Autrement dit, reconnaître une technique ne suffira plus toujours, il faudra aussi déterminer si cette technique est normale pour cet agent, dans ce contexte précis.
C’est un déplacement important pour l’ingénierie de détection. Un réglage trop strict conduira à submerger les analystes d’alertes produites par le travail quotidien des agents. Un réglage trop permissif risque, à l’inverse, de considérer comme normales des actions réellement dangereuses simplement parce qu’elles proviennent d’un outil IA autorisé.
Le problème n’est donc pas de placer les agents dans une liste blanche, il est de définir leur comportement acceptable.
Restreindre l’agent plutôt que lui faire confiance
Les recommandations d’Intezer découlent directement de ce constat.
La première consiste à réviser les règles historiques produisant beaucoup de faux positifs sur les activités normales des agents.
Mais cette réduction du bruit doit être accompagnée d’une recherche plus ciblée des véritables expositions : agents lancés avec les garde-fous de permissions désactivés, tunnels réseau non autorisés, consentements OAuth à risque ou accès excessifs aux données et aux secrets.
L’éditeur recommande également d’exécuter les agents dans des environnements isolés, par exemple des conteneurs ou des machines virtuelles, afin de réduire leur accès aux credentials et aux informations sensibles et de mieux distinguer leur activité de celle de l’utilisateur.
Le principe est finalement assez classique en cybersécurité : ne pas accorder davantage de privilèges que nécessaire simplement parce que l’outil est légitime.
L’arrivée de l’IA ne rend pas obsolètes le moindre privilège, la segmentation ou l’isolation. Elle les rend au contraire particulièrement importants.
Le SOC doit maintenant identifier l’acteur derrière l’action
Les agents IA ne représentent encore qu’une fraction du volume d’alertes observé par Intezer, mais leur progression rapide laisse entrevoir une difficulté qui pourrait devenir beaucoup plus importante à mesure que leur usage se généralise.
Le défi n’est pas, pour l’instant, une armée d’agents autonomes attaquant les systèmes d’information Il est beaucoup plus quotidien, des outils légitimes commencent à exécuter, avec les droits de leurs utilisateurs, des actions que les équipes de sécurité ont appris pendant des années à considérer comme suspectes.
Le SOC doit donc adapter sa lecture, il ne pourra plus toujours s’arrêter à :
Que s’est-il passé ? Il devra également demander : Qui — ou quoi — l’a fait, avec quelles autorisations et pourquoi ?
C’est probablement l’une des évolutions les plus concrètes introduites par les agents IA dans les opérations de sécurité. Ils ne changent pas seulement la manière de développer, d’administrer ou d’utiliser un système d’information. Ils commencent aussi à changer la définition de ce que le SOC considère comme normal.
