Vos agents de code noient la détection

Ce qui se passe

Une nouvelle catégorie d'alertes a poussé dans les centres opérationnels de sécurité : non pas des attaques contre l'IA, mais l'empreinte ordinaire d'une entreprise qui s'en sert. Intezer a classé cette population sur le parc de ses clients, et publie deux chiffres qui encadrent le reste.

• Les alertes liées à l'IA pèsent 0,43 % du flux total.
• Cette part a été multipliée par 18 entre février et juin 2026.

C'est la plus petite tranche du flux et la plus rapide à croître.

Le mécanisme

L'adoption arrive par deux chemins qui n'ont rien en commun.

Le premier est bruyant et technique. Un agent de code lance des interpréteurs de commandes, lit des magasins d'identifiants, ouvre des tunnels réseau, télécharge des paquets, exécute des outils de sécurité. Tout cela est du travail légitime — et tout cela est indiscernable, pour un moteur de détection écrit avant ces outils, des premières étapes d'une intrusion.

Le second est silencieux : un salarié accorde un consentement OAuth à une application d'IA tierce et y colle des documents. Ça ne déclenche presque jamais l'antivirus du poste, et c'est par là que les données sortent.

Les chiffres

Classement de chaque alerte d'après l'activité réelle qui l'a déclenchée :

Et le traitement automatique, sans humain dans la boucle : 79,8 % de verdicts bénins, 81,7 % d'alertes étouffées automatiquement, 5,4 % seulement escaladées vers un analyste.

Le détail vaut mieux que le total. Chez un client, une seule détection — Expand.exe signalé comme transfert d'outil latéral — représentait 55 % de toutes les alertes de verdict critique. C'était un agent de code qui installait son environnement shell.

Les risques réels, eux, sont nommés :

• un agent exécutant security dump-keychain > /tmp/ pour récupérer un seul jeton, et écrivant au passage tous les secrets du trousseau macOS dans un fichier temporaire ;
• un éditeur IA ouvrant un tunnel inverse ngrok vers l'internet public avec le jeton d'authentification de l'utilisateur ;
• la chaîne Cursor.exe → powershell.exe → rundll32.exe, avec un vidage mémoire par MiniDump via comsvcs.dll — une technique d'extraction d'identifiants, déclenchée en tentant de déboguer.

Aucune attaque confirmée n'a été causée par l'agent d'une organisation. Ce qui était réel, c'est du hameçonnage qui s'appuie sur l'IA : gemini-advertisers[.]com, un faux « OpenAI Partner Summit 2026 » expédié depuis noreply-zoomevents@zoom.us, un objet de message en RE: Anthropic Engagement approval & payment pour crédibiliser une fraude à la facture.

Ce que ça change

L'action la plus rentable n'est pas une nouvelle règle de détection, c'est de régler les anciennes pour qu'un développeur lançant un agent ne produise plus une alerte de sévérité maximale. Deux autres consignes en découlent :

1. Ne pas lancer un agent avec ses garde-fous de permissions désactivés. C'est à la fois la première source de faux positifs et l'exposition qui compte, le jour où le code que l'agent exécute n'est pas bénin.
2. Isoler l'agent dans un conteneur ou une machine virtuelle — ça limite sa portée, et ça rend son comportement distinguable de celui de l'utilisateur.

À retenir

Le coût de l'IA dans un SOC, à ce stade, n'est pas la brèche. C'est un flux d'alertes alarmantes et presque toujours fausses, qui enterre le petit ensemble d'expositions véritables. Et la mesure vient d'un éditeur qui vend la réponse au problème qu'il décrit, sur son propre parc, sans audit externe : les cas techniques sont vérifiables, les pourcentages se lisent en le sachant.