Les alertes AI SOC d’Intezer ont explosé, mais presque toutes n’étaient que du bruit

Les alertes AI SOC d’Intezer ont augmenté de 685 % entre février et juin 2026, tout en ne représentant que 0,43 % des alertes de sécurité de son étude. Le conflit est déjà évident. L’IA en entreprise n’a pas déclenché la vague de compromissions pilotées par des agents que redoutaient de nombreuses équipes de sécurité. Elle a produit un flux en forte croissance d’activités légitimes qui ressemblent souvent à une intrusion.

Intezer a examiné environ 16,9 millions d’alertes dans plusieurs environnements d’entreprise. Environ 73 000 impliquaient des outils ou agents d’IA. Ses chercheurs ont classé 94,1 % comme du bruit, 5,8 % comme de véritables risques de sécurité et seulement 0,02 % comme de réelles attaques.

Ce déséquilibre oppose une logique de détection établie au travail normal assisté par l’IA. Claude, Codex, Cursor, ChatGPT et des outils similaires peuvent lancer des processus, manipuler des fichiers, appeler des shells et se connecter à des services. Ces actions ressemblent à des comportements d’attaquant lorsqu’elles sont observées sans connaître l’intention de l’utilisateur.

Le résultat ne se limite pas à une charge de travail accrue pour un centre d’opérations de sécurité, ou SOC. C’est un problème de contexte. Les équipes doivent distinguer l’activité légitime des agents de leurs comportements dangereux avant que les fausses alertes n’enfouissent les expositions importantes.

Les alertes AI SOC d’Intezer ont augmenté plus vite que leur part ne le laisse penser

Le chiffre important n’est pas la part actuelle de l’IA dans le volume d’alertes. C’est la vitesse et la composition de cette croissance.

Selon l’étude d’Intezer sur les alertes IA, l’activité liée à l’IA a généré environ 73 000 des 16,9 millions d’alertes examinées. Cette catégorie reste modeste face aux alertes liées aux terminaux, aux identités, aux e-mails, au cloud et au réseau qui parviennent déjà aux SOC des entreprises.

Toutefois, le volume mensuel lié à l’IA a augmenté durant toute la période de reporting stable. Intezer a mesuré une croissance de 685 % entre février et juin 2026. L’entreprise a décrit cette évolution comme monotone, ce qui signifie que chaque mois complet dépassait le précédent.

Cette trajectoire compte, car l’adoption en entreprise ne nécessite pas de déploiement formel à l’échelle de toute l’organisation. Les employés peuvent connecter un chatbot grand public via OAuth, ce qui permet à une application d’accéder à des ressources de compte approuvées. Les développeurs peuvent installer des agents de codage qui commencent immédiatement à interagir avec les systèmes locaux.

Chaque action ajoute une nouvelle source de télémétrie. Elle peut également activer des règles créées des années avant que des agents généralistes ne commencent à fonctionner sur les ordinateurs des employés.

Intezer a réparti les alertes qui en résultent en trois catégories. Le bruit couvrait une activité légitime ayant déclenché une détection existante. Le risque de sécurité couvrait un comportement dangereux ou une exposition sans compromission confirmée. Les attaques réelles exigeaient des preuves d’une opération effective menée par un attaquant.

Le bruit dominait avec 94,1 %. Les risques de sécurité représentaient 5,8 %, tandis que les attaques confirmées comptaient pour environ 0,02 %. Ces classifications proviennent de la plateforme et de la méthodologie d’Intezer ; des études indépendantes pourraient donc produire des ratios différents.

Les données internes de traitement ont révélé une autre facette du même schéma. Intezer a indiqué que 79,8 % des alertes liées à l’IA avaient reçu un verdict bénin. Son système automatisé en a supprimé 81,7 %, les clôturant sans les présenter à un analyste humain.

Seules 5,4 % ont été transmises à un analyste. Les alertes restantes ont été signalées pour suivi plutôt que traitées immédiatement comme des incidents.

Ces résultats soutiennent le tri automatisé, mais ils révèlent aussi une dépendance. L’automatisation doit comprendre la relation entre un agent, son utilisateur et la tâche exécutée. Un nom de processus ou une commande isolée fournit rarement ce contexte.

Un client a généré 55 % de toutes les alertes liées à l’IA étiquetées comme critiques dans l’ensemble de données, via une seule détection. Cette règle identifiait le binaire Windows Expand.exe comme un possible outil de transfert latéral.

Une inspection plus poussée a révélé qu’un agent de codage préparait un environnement shell. L’activité était normale pour ce flux de travail, même si ses signaux techniques individuels ressemblaient à un comportement d’attaquant.

Une étiquette de gravité traditionnelle aurait placé ces alertes en tête de la file d’attente d’un analyste. Le contexte les a orientées vers une clôture automatique. Cette différence devient coûteuse lorsque le même schéma se répète sur des milliers de terminaux.

L’étude ne montre pas que toutes les alertes IA de haute gravité sont inoffensives. Elle montre que la gravité perd son sens lorsque la logique de détection ne peut pas reconnaître le comportement normal des agents.

C’est le premier changement opérationnel pour les responsables SOC. L’activité IA a besoin de sa propre base de référence, incluant les outils approuvés, les processus parents attendus, les destinations habituelles et les actions autorisées. Sans cette base, la croissance de l’adoption devient une croissance de la fausse urgence.

L’adoption de l’IA à l’échelle de l’entreprise modifie la forme du flux d’alertes

L’IA en entreprise crée simultanément deux flux de sécurité : une exécution bruyante des agents et un déplacement discret des données de l’entreprise.

Le flux bruyant provient surtout des utilisateurs techniques. Les agents de codage peuvent créer des scripts, démarrer des interpréteurs, installer des packages, inspecter des dépôts, ouvrir des ports ou exécuter des outils de développement. Chaque action peut ressembler à une étape d’une intrusion.

Un développeur peut demander à un agent de lancer un serveur de test local. L’agent pourrait démarrer PowerShell, trouver un port inutilisé, exécuter Python et rediriger la sortie vers les journaux du projet. Un produit de protection des terminaux voit une chaîne de processus inhabituelle avant de voir un objectif de développement bénin.

Intezer a constaté qu’un binaire sandbox OpenAI Codex signé produisait ce schéma. PowerShell lançait ensuite cmd.exe, python.exe et conhost.exe pendant la préparation d’un environnement de projet local.

Une règle conventionnelle a interprété cette séquence comme un possible reverse shell. Le texte de la commande révélait plutôt une orchestration locale sur 127.0.0.1, l’adresse de bouclage utilisée pour atteindre le même ordinateur.

Les installateurs créent des collisions similaires. Intezer a signalé que l’installateur légitime de Claude Desktop activait des détections associées à des comportements de ransomware et à l’exécution de PowerShell encodé. Sa signature de code confirmait l’identité du package, mais les règles comportementales traitaient encore la séquence d’installation comme suspecte.

Cela ne rend pas la détection comportementale obsolète. Un logiciel signé peut devenir malveillant, et des applications de confiance peuvent être détournées. Cela signifie que la détection nécessite un contexte complémentaire avant qu’un analyste puisse attribuer une intention.

Le flux discret provient de l’adoption non technique. Les employés peuvent autoriser un service d’IA à accéder à des comptes d’entreprise, téléverser des documents ou coller du contenu sensible dans des prompts. Ces actions ne créent parfois jamais de processus inhabituel sur un terminal.

Intezer a observé des consentements OAuth accordés à ChatGPT dans plusieurs tenants. L’entreprise a également constaté les premières connexions à une application OpenAI et un groupe d’alertes de protection des données impliquant des téléversements vers une IA générative chez un client.

La plupart des événements étaient bénins. Ils représentaient néanmoins des informations d’entreprise se déplaçant vers des services hors du contrôle immédiat du terminal.

Cette distinction explique pourquoi bloquer quelques exécutables ne peut pas résoudre la sécurité de l’IA en entreprise. Une partie du risque réside dans les processus. Une autre réside dans les sessions de navigateur, les autorisations d’identité, les intégrations logicielles et les flux de données.

Un inventaire utile doit donc aller au-delà d’une liste d’applications approuvées. Il doit relier utilisateurs, identités, agents, extensions, autorisations OAuth, destinations de données et ressources auxquelles chaque outil peut accéder.

Ce travail dépasse le SOC. Les équipes d’identité gèrent le consentement et l’accès. Les équipes de gouvernance des données définissent les informations sensibles. Les responsables de l’ingénierie décident quelles configurations d’agents sont acceptables.

Les équipes achats et juridiques évaluent les conditions de traitement par des tiers. Les responsables métier déterminent si les employés disposent d’alternatives approuvées réellement exploitables.

Le SOC reste le point où ces signaux convergent. Il reçoit les alertes lorsqu’un outil lance une commande suspecte, ouvre un tunnel ou accède à des informations protégées.

L’adoption à l’échelle de l’entreprise modifie également le sens de l’attribution. Avant les agents généralistes, une commande exécutée sous le compte d’un utilisateur reflétait généralement soit cet utilisateur, soit un attaquant contrôlant ce compte.

Un agent introduit un troisième acteur. Il opère avec l’autorité de l’utilisateur, mais peut sélectionner des commandes que celui-ci n’a jamais examinées. L’activité appartient au compte sans refléter pleinement l’action directe de son titulaire.

Cet écart est particulièrement important pour les chronologies d’incident. Les analystes doivent savoir si un humain a saisi une commande, si un agent approuvé l’a générée ou si un contenu malveillant a manipulé l’agent.

Les équipes de sécurité ont également besoin d’un contexte organisationnel durable. Une base de connaissances d’ingénierie consultable peut préserver les flux de travail approuvés et les décisions techniques locales. Toutefois, la documentation doit être reliée aux preuves actuelles provenant des identités et des terminaux afin de soutenir le triage.

L’objectif opérationnel n’est pas une visibilité parfaite sur chaque prompt. Il s’agit de disposer d’un contexte vérifié suffisant pour distinguer le travail approuvé, les comportements dangereux et l’activité adverse, sans surveiller les employés plus largement que nécessaire.

La logique de détection héritée entre en collision avec le comportement normal des agents

Le principal affrontement oppose la logique de détection héritée au contexte des agents d’IA, et non les analystes humains à l’automatisation.

Les produits de sécurité détectent souvent des techniques plutôt que des intentions. L’accès aux identifiants, l’exécution de commandes, la persistance, le tunneling et la collecte de données restent dangereux, quelle que soit l’application qui les initie.

Les agents d’IA compliquent ce modèle, car des outils légitimes exécutent désormais des combinaisons autrefois principalement associées aux administrateurs, aux testeurs d’intrusion et aux attaquants. Ce chevauchement est structurel, et non accidentel.

Intezer a constaté des taux d’événements bénins allant de 77 % à 99 % parmi les groupes de détection liés à l’IA les plus bruyants. Plusieurs règles se trompaient sur le comportement généré par l’IA plus de quatre fois sur cinq.

Un exemple concernait OpenAI Codex lancé via Node.js avec des indicateurs tels que --yolo ou --dangerously-skip-permissions. L’activité qui en résultait déclenchait des détections liées à ClickFix, aux outils désactivés et à l’injection de DLL.

Les indicateurs de contournement des autorisations suppriment les demandes d’approbation avant qu’un agent n’agisse. Les développeurs les utilisent pour réduire les interruptions, mais cette même commodité affaiblit une importante frontière de contrôle.

Le groupe ClickFix constituait une exception dans les conclusions d’Intezer sur le bruit. Seules 37 % de ces alertes étaient bénignes. Ce résultat ne signifie pas que chaque alerte est une attaque, mais il confère davantage de valeur d’investigation à ce groupe.

C’est là que la simple mise sur liste blanche échoue. Déclarer Codex, Claude ou Cursor comme fiables réduirait le bruit, mais pourrait aussi dissimuler des actions dangereuses lancées par ces outils.

L’approche la plus sûre évalue toute la chaîne. Le SOC doit prendre en compte l’application signée, l’utilisateur à l’origine de l’action, la configuration de l’agent, la tâche demandée, les processus enfants, les ressources consultées, la destination réseau et les déplacements de données qui en résultent.

La matrice de menaces IA de MITRE reflète cette vision plus large. Elle comprend l’invocation d’outils par des agents, la collecte d’identifiants, l’injection de prompts, les reverse shells et l’exfiltration via des mécanismes liés à l’IA.

Ces techniques expliquent pourquoi un agent approuvé ne peut pas bénéficier d’une confiance globale permanente. L’outil peut être légitime tout en restant dangereux dans le cadre d’une invocation particulière.

L’ingénierie de détection doit donc devenir plus conditionnelle. Un serveur local démarré dans un dépôt de développement connu peut être courant. Le même interpréteur créant un tunnel externe depuis un poste de travail du service financier mérite un traitement différent.

Un agent de codage lisant son propre jeton de configuration peut être attendu. Extraire l’intégralité du trousseau macOS dans un fichier temporaire n’est pas proportionné à cette tâche.

Intezer a observé exactement ce schéma. Un agent a utilisé security dump-keychain et redirigé la sortie vers un emplacement temporaire en tentant de récupérer des identifiants stockés.

La tâche prévue ne nécessitait aucune intention malveillante. La méthode retenue a néanmoins exposé davantage d'informations que nécessaire et créé une cible précieuse sur le disque.

Un autre cas concernait un éditeur de code IA qui a lancé PowerShell puis ngrok, un service qui crée des tunnels accessibles depuis Internet. Il a ouvert un tunnel inverse nommé à l'aide du jeton d'authentification de l'employé.

L'objectif de l'utilisateur pouvait être un dépannage ou un développement légitime. Pourtant, cette action a créé un véritable chemin depuis l'Internet public vers un environnement d'entreprise.

Un troisième exemple impliquait Cursor lançant une chaîne de processus utilisant une méthode connue de vidage de mémoire. Cursor a lancé PowerShell, qui a appelé rundll32.exe et la fonctionnalité MiniDump dans comsvcs.dll.

Cette technique peut extraire des secrets de la mémoire d'un processus. Même lorsqu'un agent la sélectionne à des fins de débogage, ce comportement crée un risque d'accès aux identifiants qui mérite une enquête.

Ces exemples appuient une politique fondée sur les actions et les limites, et pas seulement sur les noms de produits. Les agents approuvés devraient tout de même être soumis à des restrictions concernant les magasins d'identifiants, les systèmes de production, les tunnels publics et les dépôts sensibles.

L'isolation peut aider. Intezer recommande d'exécuter les outils d'IA dans des environnements contraints, notamment des conteneurs ou des machines virtuelles, lorsque le flux de travail le permet.

Un conteneur encapsule un processus avec des ressources et des limites d'accès définies. Une machine virtuelle fournit un environnement d'exploitation distinct avec une isolation plus forte dans de nombreuses configurations.

Aucune de ces protections n'est absolue. Les conteneurs peuvent être mal configurés, tandis que les machines virtuelles nécessitent toujours des contrôles d'identité, de réseau, de stockage et de mise à jour. Les deux peuvent réduire le nombre de ressources auxquelles un agent accède par défaut.

Elles améliorent également l'attribution. L'activité provenant d'un environnement attribué à un agent est plus facile à distinguer de l'activité habituelle d'un utilisateur sur son poste de travail.

Ce changement exige une mesure rigoureuse. Les équipes devraient suivre les taux de faux positifs par détection, agent, configuration et unité opérationnelle. Elles devraient également consigner les suppressions qui ont ensuite nécessité une correction.

Une baisse générale du volume d'alertes n'est pas un succès. La mesure utile consiste à déterminer si l'ajustement élimine le bruit prévisible sans masquer l'accès aux identifiants, l'exposition externe ou le déplacement de données sensibles.

Les risques de sécurité IA discrets comptent davantage que les alertes bruyantes

Les risques IA les plus conséquents dans les données d'Intezer étaient souvent des expositions, et non des compromissions confirmées ou des alertes de gravité maximale.

Intezer a classé 5,8 % de la population liée à l'IA comme de véritables risques de sécurité. Ces événements ne prouvaient pas qu'un attaquant avait obtenu un accès. Ils révélaient des conditions susceptibles d'aggraver les conséquences d'une compromission ultérieure.

Le contournement des autorisations constituait un exemple central. Un agent fonctionnant sans invites d'approbation peut exécuter une longue séquence avant qu'un utilisateur n'en voie les détails.

Cette conception devient plus dangereuse lorsque l'agent lit du code, des sites web, des tickets, des e-mails ou des documents non fiables. Des instructions malveillantes cachées dans ces sources peuvent influencer les choix d'un agent.

L'injection de prompt est une tentative visant à faire suivre à un modèle des instructions hostiles intégrées à son entrée. Elle devient plus grave lorsqu'un agent peut utiliser des outils ou accéder à des données métier.

Une injection indirecte peut parvenir via du contenu que l'utilisateur ne considère jamais comme une instruction. Une page web ou un fichier de dépôt peut contenir du texte destiné à l'agent plutôt qu'au lecteur humain.

Le profil d'IA générative du NIST recommande de gouverner, cartographier, mesurer et gérer les risques liés à l'IA tout au long du cycle de vie du système. Ce modèle convient aux agents d'entreprise, car le risque traverse les frontières technologiques et organisationnelles.

Une alerte sur un terminal peut révéler la commande finale tout en ignorant le contenu qui a influencé le modèle. Un journal d'identité peut révéler une autorisation OAuth sans indiquer quels documents ont ensuite été transmis au service.

Un produit de prévention des fuites de données peut voir un téléversement sans en connaître l'objectif métier. Chaque outil n'observe qu'un fragment de l'événement.

Le SOC doit corréler ces fragments. Il devrait relier l'utilisateur, l'agent, la source du prompt, les autorisations, l'activité des processus, la destination et la classification des données lorsque la télémétrie disponible le permet.

Cela ne nécessite pas de collecter chaque conversation des employés. La confidentialité et la proportionnalité restent importantes. Les organisations devraient recueillir le minimum de preuves nécessaire pour appliquer une politique établie et enquêter sur les risques significatifs.

Une politique claire est également importante, car une même action peut avoir des conséquences différentes selon les services. Téléverser un texte marketing public est différent de téléverser des dossiers clients, des informations financières non publiées ou du code source contenant des secrets.

Les outils approuvés n'éliminent pas cette différence. Une licence d'entreprise peut améliorer les contrôles administratifs, mais elle ne peut pas déterminer si chaque donnée a sa place dans chaque prompt.

Le consentement OAuth mérite une attention similaire. OAuth permet à un utilisateur d'autoriser une application sans remettre de mot de passe. Le jeton qui en résulte peut néanmoins fournir un accès important aux e-mails, fichiers, calendriers ou autres services.

Les portées demandées par une application d'IA légitime peuvent dépasser la tâche immédiate. Un compte compromis ou un agent manipulé peut alors utiliser ces autorisations d'une manière que l'employé n'a jamais envisagée.

Les équipes SOC devraient examiner les autorisations à haut risque, les applications inhabituelles utilisées pour la première fois et les permissions qui traversent des systèmes sensibles. Elles devraient également offrir aux utilisateurs une voie rapide pour demander des intégrations approuvées.

Si la gouvernance avance trop lentement, les employés la contourneront. Cela crée une IA fantôme, c'est-à-dire des outils ou des usages qui fonctionnent en dehors de l'approbation et de la supervision établies par l'organisation.

La réponse n'est pas une interdiction indiscriminée. Une interdiction peut réduire l'activité visible tout en poussant le travail utile vers des comptes personnels et des sessions de navigateur non gérées.

Les équipes de sécurité ont besoin d'une voie approuvée et pratique, assortie de contrôles adaptés. Les employés devraient comprendre quels outils ils peuvent utiliser, quelles informations ils peuvent partager et à quel moment un agent nécessite un environnement isolé.

CISA et ses partenaires internationaux ont accordé une importance similaire à la responsabilité, à la transparence et à la conception sécurisée dans leurs lignes directrices sur la sécurité de l'IA. Ces principes s'appliquent aux fournisseurs, mais les acheteurs d'entreprise doivent également les évaluer.

Les questions d'approvisionnement devraient couvrir la journalisation, la conservation, l'entraînement des modèles, les portées d'accès, les contrôles administratifs, la notification des incidents et la suppression des données. Les tests techniques devraient vérifier les affirmations importantes chaque fois que possible.

Les procédures SOC doivent ensuite traduire la politique en étapes d'enquête. Un analyste qui voit un tunnel inhabituel devrait pouvoir identifier rapidement l'agent, l'utilisateur, la tâche et la destination responsables.

La procédure ne devrait pas automatiquement clore l'événement parce qu'un outil approuvé l'a lancé. Elle devrait déterminer si l'action est restée dans une limite approuvée.

Le même principe s'applique à l'accès aux identifiants. Un agent qui lit un secret limité via un intermédiaire approuvé est différent d'un agent qui exporte un magasin complet d'identifiants.

Ce modèle centré sur l'action préserve les détections utiles tout en réduisant le bruit évitable. Il aligne également les alertes sur les risques que l'organisation a effectivement décidé de gérer.

Ce que les données d'Intezer ne prouvent pas encore

Les conclusions d'Intezer constituent un instantané opérationnel utile, mais elles ne représentent pas une mesure universelle du risque IA en entreprise.

L'étude couvre les alertes visibles dans les environnements connectés à la plateforme d'Intezer. Elle ne représente pas toutes les entreprises, piles de sécurité, secteurs, zones géographiques ou approches de déploiement de l'IA.

Intezer n'a pas publié le nombre total de ses clients ni une répartition détaillée par secteur dans l'article. L'entreprise a également anonymisé les informations sur les clients, hôtes, utilisateurs et identifiants.

Cela protège les organisations, mais limite la reproduction indépendante. Les lecteurs ne peuvent pas déterminer dans quelle mesure un grand environnement a influencé chaque catégorie au-delà des exemples divulgués par Intezer.

La recherche mesure également les alertes, et non toute l'activité liée à l'IA. Une action qui ne déclenche jamais un contrôle connecté peut être absente de l'ensemble de données.

Cela compte particulièrement pour les outils basés sur le navigateur, les comptes personnels, les extensions non approuvées et les échanges de données que les produits de sécurité des terminaux ne peuvent pas observer. Les usages discrets peuvent être sous-représentés par rapport à l'activité des agents exécutables.

Le chiffre de 94,1 % de bruit devrait donc orienter l'ajustement des détections, et non devenir un taux universel de faux positifs. Une autre organisation peut disposer d'agents, de politiques, d'utilisateurs ou de télémétrie différents.

La part de 0,02 % d'attaques nécessite également une interprétation prudente. Elle ne montre pas que les agents IA sont intrinsèquement sûrs ou que les attaques facilitées par les agents sont négligeables partout.

Elle montre que les attaques confirmées étaient extrêmement rares au sein de cette population d'alertes spécifique liée à l'IA. Intezer a indiqué qu'aucune de ces attaques confirmées ne résultait d'un agent interne à une organisation ayant provoqué une compromission.

Les véritables attaques qu'elle a identifiées utilisaient des marques IA connues comme leurres de phishing. Les attaquants usurpaient des noms tels qu'Anthropic, Gemini et OpenAI, car les employés les reconnaissent et leur font de plus en plus confiance.

Un e-mail faisait référence à un supposé engagement avec Anthropic et à une demande de paiement. Un autre utilisait une fausse invitation publicitaire Gemini avec une infrastructure sans lien avec Google.

Un troisième usurpait un événement partenaire OpenAI tout en utilisant une infrastructure Zoom légitime pour rendre l'invitation crédible. Dans chaque cas, l'adoption de l'IA renforçait le prétexte plutôt que de fournir une nouvelle technique d'attaque.

Cette distinction est utile, mais elle peut évoluer. Des autorisations d'agent plus étendues, des capacités autonomes plus fortes et des intégrations métier plus profondes augmentent les conséquences de la manipulation.

L'absence de nombreuses compromissions confirmées causées par des agents dans cet ensemble de données ne prouve pas que les futurs déploiements resteront sûrs. Elle constitue une référence pour surveiller la transition.

Les motivations des fournisseurs méritent également attention. Intezer vend une plateforme AI SOC et des services de triage automatisé. Ses recherches mettent naturellement en avant les problèmes que l'enquête contextuelle et l'automatisation peuvent résoudre.

Cela n'invalide pas les données. Cela signifie que les acheteurs devraient comparer les résultats avec leur propre télémétrie, les conclusions de leurs équipes de red teaming et leur historique d'incidents avant de modifier les contrôles.

Les équipes de sécurité devraient vérifier si les verdicts automatisés restent exacts dans leur environnement. Elles devraient échantillonner les alertes supprimées, examiner les classifications incertaines et surveiller les éléments ultérieurs qui contredisent une décision antérieure.

Elles devraient également documenter la différence entre les résultats vérifiés et les affirmations des fournisseurs. Par exemple, Intezer affirme que sa plateforme élargie peut enquêter sur les alertes à grande échelle, mais cette étude ne valide pas indépendamment chaque affirmation de performance.

La question plus difficile concerne les signaux manquants. Un SOC peut éliminer le bruit visible tout en manquant de couverture pour les outils de navigateur non autorisés ou le partage risqué de données.

C'est pourquoi la réduction des alertes ne peut pas être la seule mesure de réussite. Les équipes ont également besoin d'une couverture de l'inventaire des agents, de décomptes d'autorisations risquées, de tendances des téléversements sensibles et du temps nécessaire pour remonter une action jusqu'à sa source.

Une organisation avec moins d'alertes mais aucune visibilité sur OAuth ou l'activité des navigateurs n'a pas nécessairement amélioré sa sécurité. Elle peut avoir déplacé le risque hors du canal mesuré.

Trois signaux montreront si les SOC s'adaptent

Le prochain test consiste à déterminer si les équipes de sécurité peuvent améliorer le contexte plus vite que l'activité IA ne se développe.

Le premier signal est la performance des faux positifs pour les détections liées aux agents. Les responsables SOC devraient mesurer les taux d'événements bénins avant et après l'ajustement des règles les plus bruyantes.

Une modification efficace réduira les alertes répétées provenant d’installateurs connus, de serveurs de développement locaux et de chaînes de processus approuvées. Elle préservera l’examen des contournements d’autorisations, de l’extraction d’identifiants, des tunnels externes et des mouvements de données inhabituels.

Si les taux d’événements bénins diminuent sans hausse des incidents manqués, le SOC apprend ce qui constitue un comportement normal des IA. Si les analystes continuent à clôturer manuellement les mêmes schémas, l’adoption devance toujours l’ingénierie de détection.

Le deuxième signal concerne la couverture de l’entreprise à travers les contrôles d’identité, de navigateur, de terminaux, de cloud et de données. Une liste des agents de programmation installés ne constitue pas un inventaire IA complet.

Les équipes doivent rechercher de nouvelles autorisations OAuth, les premières connexions à des applications IA, des extensions non gérées, l’utilisation de comptes personnels et les connexions entre les agents et des dépôts sensibles.

Une meilleure couverture révélera d’abord davantage d’expositions discrètes. Cette hausse temporaire ne doit pas être interprétée comme une dégradation de la sécurité. Une meilleure mesure rend souvent visible un risque existant avant que les contrôles ne le réduisent.

Le troisième signal consiste à déterminer si les déploiements d’agents adoptent par défaut une exécution contrainte. Les invites d’autorisation, les identifiants restreints, les environnements isolés et l’accès réseau limité fournissent des limites mesurables.

Les organisations doivent surveiller la proportion d’agents lancés avec des indicateurs de contournement. Elles doivent également suivre la fréquence à laquelle les agents tentent d’exécuter des commandes interdites, même lorsqu’un contrôle bloque l’exécution.

Une baisse du taux de contournement renforcerait l’idée que la gouvernance devient opérationnelle. Une croissance continue montrerait que la commodité prime encore sur le confinement.

Les tests de sécurité doivent inclure des flux de travail réalistes d’agents, et pas seulement des invites de modèles. Une évaluation peut placer des instructions non fiables dans du code, des documents, des tickets ou du contenu web, puis observer la réponse de l’agent.

L’objectif est de tester l’ensemble du système. Cela inclut les autorisations d’identité, les outils, la mémoire, le contenu externe, les contrôles d’exécution, la journalisation et l’approbation humaine.

Les alertes du SOC IA d’Intezer offrent un premier aperçu de cette transition. Le résultat principal n’est rassurant qu’au premier regard. Les attaques confirmées étaient rares, mais l’exposition et le bruit opérationnel augmentaient déjà rapidement.

Pour les équipes SOC, la question immédiate est concrète : peuvent-elles identifier le comportement normal des agents sans leur accorder une confiance générale ?

Commencez par les détections qui génèrent le plus d’alertes bénignes répétées. Comparez ensuite cet ajustement aux contournements d’autorisations, à l’accès aux identifiants, aux tunnels, aux autorisations OAuth et aux téléversements sensibles. Si ces signaux à plus forte valeur deviennent plus faciles à repérer, le SOC s’adapte. Si le nombre d’alertes diminue tandis que la visibilité reste fragmentée, l’amélioration apparente n’est qu’une incertitude plus silencieuse.