Les alertes d'IA dans le COS augmentent de 685% entre février et juin 2026; la plupart est le bruit

Ces derniers mois, les opérations de sécurité dans les entreprises ont commencé à recevoir un nouveau type d'alertes : celles générées par l'utilisation interne d'outils et d'agents IA. Une analyse d'environ 16,9 millions d'alertes SOC révèle qu'environ 73 000 0,43% de l'ensemble) ont été étiquetés comme étant liés à l'IV, et cette portion a augmenté continuellement: entre février et juin 2026 685%. C'est-à-dire qu'aujourd'hui, les alertes d'IA sont une fraction modérée du flux mondial, mais elles sont la partie qui croît le plus rapidement et posent des défis opérationnels qui affectent déjà les équipes de détection et d'intervention.

Ce sont les faits confirmés qui ressortent de l'ensemble de données analysées : la plupart des alertes provenant d'agents ou d'outils IA ne représentent pas des intrusions; elles sont divisées en trois catégories par composition : 94,1 % bruit(activité légitime qui déclenche les anciennes règles), 5,8% risque(utilisation non sûre de l'outil qui expose les données ou les références) et 0,02 % attaques réelles(engagements confirmés). En outre, lorsque ces alertes passent à travers les plates-formes de tri automatique, 79,8% reçoivent un verdict bénin, 81,7% sont automatiquement supprimés et seulement 5,4% finissent par grimper à un analyste humain.

Techniquement, pourquoi les outils IA génèrent-ils autant de fausses alarmes ? Les agents de développement et les assistants automatisés effectuent des actions que nous associons traditionnellement à un intrus : créer des shells, lancer PowerShell, écrire des scripts temporaires, ouvrir des tunnels sortants (par exemple avec ngrok) et accéder aux magasins d'identification. Ces mêmes signes - processus enfant qui lancent des interprètes, création de tunnel, lectures de porte-clés - correspondent aux signatures des outils de mouvement latéral et d'exfiltration, de sorte que les règles de détection pré-IA qualifient l'activité de grande sévérité même si elle est légitime. Le coût d'exploitation réel ne provient pas, jusqu'à présent, des lacunes massives causées par les agents de l'IV; il provient d'une vague d'alertes crédibles qui consomment du temps des analystes et cachent les expositions réelles.

Les cas classés comme risques méritent une attention particulière parce qu'ils ne sont pas faux positifs : ils sont des modes d'utilisation d'agents qui créent des expositions tangibles. Parmi les observations récurrentes, mentionnons les agents lancés avec des drapeaux qui suppriment les confirmations de l'utilisateur (p. ex. -- yolo ou --permissions de skip dangereuses dans plusieurs environnements), les tunnels publics inversés créés avec les propres jetons de l'employé, les spins de porte-clés (p. ex. -keychain > / tmp /) et les permissions sans discrimination d'OAuth pour des applications IA tierces. Ces scénarios ne sont pas des incidents par eux-mêmes, mais laissent l'organisation dans une position d'exploitation hautement probable si le code ou le flux étant automatisé est malveillant ou si le compte tiers est compromis.

Dans les quelques attaques réelles détectées dans l'échantillon, le vecteur n'était pas un « IA interne » qui prenait le contrôle, mais des campagnes externes qui profitaient de la familiarité du personnel avec les marques IA pour construire des appâts d'hameçonnage très crédibles : des questions et des textes qui mentionnaient des fournisseurs tels qu'Anthropic, Gemini ou OpenAI pour légitimer des demandes de paiement ou des invitations. Cette technique exploite un changement culturel (les employés attendent des messages légitimes de ces plateformes) et confirme que l'adoption de l'IV peut créer des zones de tromperie sans que l'outil lui-même soit compromis.

Il y a des exemples techniques concrets qui illustrent comment la frontière entre normal et dangereux est devenue floue: un installateur légitime du bureau de Claude, signé par son fabricant, a activé des règles qui étiquettent les comportements d'installateur d'électrons / Squirrel comme «opérations de ransomware»; un IDE ou un éditeur avec agent a ouvert un tunnel de ngrok et a posté un port Internet avec le jeton du développeur; un agent a fouillé l'entrepôt d'identification macOS pour récupérer des jetons et a transformé des secrets en fichiers temporaires. Dans toutes ces inspections, la critique est constante : sans contexte, les détections produisent des alarmes de haute gravité sur des comportements qui peuvent être à la fois bénins et dangereux.

Qu'est-ce que les organisations et les équipes SOC devraient faire maintenant? Je propose des recommandations spécifiques et applicables:

1) Modifier et hiérarchiser les règles de détection légales. Tuning immédiat des règles qui génèrent le plus de bruit contre les flux d'agents connus: réduire la sévérité, ajouter des exceptions pour les binaires signés et les processus d'installation légitimes, et introduire le contexte de processus-parent et le répertoire d'exécution avant de marquer comme critique. C'est l'action de retour la plus efficace pour réduire la fatigue des analystes.

2) Détecter et bloquer les drapeaux des "permissions-skip" et les modèles d'exécution dangereux. Surveiller l'invocation avec des drapeaux qui désactivent les impulsions, et traiter ces exécutions comme des indicateurs à haut risque pour la recherche prioritaire. Chasser activement les processus qui lancent des ngroks, des ngroks équivalents ou d'autres tunnels inversés en utilisant des jetons d'utilisateur.

3) Scellez les agents. Exécuter des outils et des agents IA ayant une capacité de fonctionnement dans des environnements contenorisés ou des machines virtuelles avec des politiques restrictives (p. ex. Docker ou VM) pour limiter l'accès aux références et aux ressources sensibles. Le confinement réduit la portée de toute exécution automatisée; voir les guides de sécurité des conteneurs https: / / docs.docker.com / sécurité /.

(4) Limiter et vérifier les concessions OAuth et les charges de données à des tiers. Appliquer les politiques allowlist / dénilist pour les applications OAuth, activer les examens de consentement de l'entreprise et enregistrer chaque première connexion aux applications externes. Les organisations devraient traiter les intégrations IA comme tout autre fournisseur SaaS avec des contrôles DLP et CASB dans la chaîne de données.

5) Triage automatique avec analyse médico-légale orientée IA. Les équipes ont besoin d'outils qui non seulement suppriment le bruit, mais fournissent un contexte médico-légal (arbre de processus, signature binaire, jeton / corrélation tunnel) pour déterminer si une action a été ordonnée par un agent utilisateur ou un attaquant. Cela réduit le besoin d'intervention humaine sur les événements bénins et libère la capacité d'étudier les expositions réelles.

(6) Élaborer et ajuster les politiques à utiliser. Interdire les drapeaux dangereux dans les environnements productifs, exiger des harnais qui limitent l'exécution de commandes dangereuses et éduquer les développeurs sur les risques d'exposer des secrets aux agents automatisés. Pour les outils de tunnel et l'accès à distance, examiner l'utilisation de services tels que les exceptions pour ngrok et les documents; la documentation technique se trouve dans https: / / ngrok.com / docs.

Limites et zones d'incertitude : les chiffres proviennent de l'analyse décrite et sont solides pour cet échantillon, mais l'adoption et la configuration des agents varient selon les secteurs et la géographie, de sorte que la proportion et la vitesse de croissance peuvent varier selon les organisations. Il n'y a pas non plus de preuve dans l'échantillon révisé d'un nouveau modèle d'agents internes utilisés par les agresseurs pour compromettre les environnements à grande échelle; toutefois, la combinaison des permis supprimés et de l'automatisation constitue une occasion éprouvée d'attaque lors d'incidents antérieurs et donc un risque réel.

En bref, l'ère de l'IA dans le point final pose un double problème: d'une part, le bruit de masse qui menace de saturer la SOC; d'autre part, une poignée d'expositions silencieuses - tunnels, secrets renversés, autorisations excessives d'OAuth - qui peuvent devenir des lacunes concrètes si elles ne sont pas gérées. Prioriser le réglage des détections héritées, contenir des agents et surveiller les indicateurs de permiso-bypass et d'exfiltration doit être la feuille de route immédiate pour éviter de confondre le bruit avec ce qui compte vraiment.