Agents IA en cybersécurité : détecter sans angles morts

Face à l’alerte, votre équipe reçoit une alerte générée par un agent IA : connexion inhabituelle, exécution PowerShell, transfert vers un stockage externe. L’outil regroupe les signaux, propose une priorité et promet de réduire le temps d’analyse. Pourtant, vous devez encore vérifier le contexte métier, distinguer une sauvegarde légitime d’une exfiltration et décider sans preuve complète. Verizon indique que l’élément humain intervient dans 68 % des violations étudiées dans son rapport DBIR 2024 (source : Verizon, 2024). Cette réalité rend l’automatisation utile, mais insuffisante seule.

Une lecture critique des capacités réelles des agents IA examine leurs sources de données, leurs méthodes de détection, leurs appels d’outils et leurs mécanismes d’escalade. L’analyse distingue les tâches bien couvertes, comme le tri d’événements corrélés, des zones fragiles, notamment les attaques inédites, les environnements hybrides mal inventoriés et les décisions dépendantes d’un contexte métier. Elle confronte les promesses des éditeurs aux limites observables : faux positifs, angles morts, dépendance aux journaux disponibles, exposition des données et traçabilité des actions. Cette approche aide à cadrer les usages, les contrôles humains et les critères de déploiement, avant toute intégration au SOC.

En bref : que détectent réellement les agents IA en cybersécurité, et quelles attaques leur échappent ?

Détection réaliste Les agents IA détectent surtout des signaux corrélés dans les journaux, les flux réseau et les comportements inhabituels, accélérant le tri, l’investigation et certaines réponses automatisées. Ils restent moins fiables face aux attaques inédites, aux données incomplètes, aux environnements mal instrumentés et aux adversaires qui imitent des usages légitimes. Leur efficacité dépend donc de la qualité des règles, des accès, de la supervision humaine et de tests réguliers sur des scénarios réalistes.

• Priorité opérationnelle Les agents repèrent mieux les écarts connus et corrélés que les compromissions lentes, discrètes ou entièrement nouvelles.
• Garde-fous nécessaires Limitez leurs actions irréversibles, imposez une validation humaine et journalisez chaque décision automatisée, conformément aux principes du NIST AI RMF.
• Validation recommandée Testez régulièrement les agents avec des scénarios MITRE ATT&CK, des données dégradées et des comportements légitimes atypiques.
• Limite persistante Une IA ne compense ni des journaux incomplets, ni des identités mal protégées, ni une segmentation réseau insuffisante.

Que détectent vraiment les agents IA en cybersécurité ?

Détection assistée concrète Les agents IA repèrent surtout des signaux déjà présents dans les journaux, l’EDR, l’identité et la messagerie. Leur apport se situe dans la corrélation, la synthèse d’alertes et la formulation d’une hypothèse exploitable par l’analyste. Une étude publiée par Microsoft sur Security Copilot rapporte une meilleure exactitude de 44 % et une rapidité supérieure de 26 % chez les participants utilisant l’outil, par rapport au groupe témoin (Microsoft Security Copilot). Ces résultats mesurent une assistance encadrée, pas une autonomie opérationnelle.

Visibilité comme limite Un agent ne détecte pas ce que les capteurs ne collectent pas. Une compromission d’identité sans journalisation des connexions, une commande exécutée sur un serveur exclu de l’EDR ou une règle de pare-feu absente restent invisibles, quelle que soit la qualité du modèle. L’agent peut aussi confondre une activité administratrice légitime avec une intrusion, notamment lorsque les comptes partagés empêchent l’attribution. Le référentiel MITRE ATT&CK aide à vérifier quelles techniques disposent réellement d’une couverture de détection, plutôt qu’à assimiler une interface conversationnelle à une couverture complète.

Attaques contre l’agent Les agents ajoutent une surface d’attaque propre, particulièrement lorsqu’ils consultent des courriels, tickets ou documents non fiables. Une instruction dissimulée dans une pièce jointe peut tenter d’influencer la réponse, d’exfiltrer des données récupérées par le connecteur ou de provoquer une action non prévue. L’OWASP Top 10 for Large Language Model Applications classe l’injection de prompt et la divulgation d’informations parmi les risques structurants. Les droits d’écriture doivent donc rester séparés de l’analyse, avec validation humaine et journalisation complète.

Autonomie sous contrôle Pour une PME ou une ETI, l’usage le plus défendable commence par le triage, l’enrichissement et la rédaction de procédures, puis s’étend progressivement aux actions réversibles. La désactivation d’un compte privilégié, l’isolement d’un serveur ou la suppression d’un courriel exigent une règle explicite, un périmètre limité et une possibilité de retour arrière. Le NIST AI Risk Management Framework recommande de documenter les usages, les limites et la supervision. La mesure pertinente reste le taux d’alertes correctement priorisées, pas le nombre de tâches automatisées.

Quels sont les 3 angles morts des agents IA en cybersécurité ?

1. Ce que les agents repèrent dans les signaux techniques

Les journaux corrélés Les agents IA excellent d’abord dans le tri de volumes élevés de journaux, lorsqu’une organisation dispose de sources correctement normalisées. Un agent connecté au SIEM peut rapprocher une authentification inhabituelle, une élévation de privilèges et une connexion sortante vers une adresse récemment observée. Cette capacité réduit le temps consacré à la recherche manuelle, mais ne transforme pas un journal incomplet en preuve exploitable. Microsoft décrit notamment l’usage de Security Copilot pour accélérer l’analyse et la synthèse d’incidents (documentation Microsoft). Le RSSI doit donc vérifier la qualité des données avant toute automatisation.

Les comportements déviants Un agent peut aussi identifier des écarts par rapport aux habitudes d’un compte, d’un poste ou d’un service. Une connexion depuis un pays inhabituel, suivie du téléchargement massif de fichiers SharePoint, mérite une investigation, même si chaque événement pris isolément reste autorisé. Les modèles comportementaux restent toutefois sensibles aux changements légitimes, comme une migration informatique ou une astreinte exceptionnelle. Le NIST recommande de documenter les limites, les hypothèses et la surveillance des systèmes d’IA dans son AI Risk Management Framework (cadre NIST). Cette traçabilité doit accompagner chaque alerte automatisée.

Les chaînes d’attaque La valeur opérationnelle apparaît lorsque l’agent relie plusieurs indices dans une séquence cohérente. Dans un scénario inspiré d’attaque par hameçonnage, il peut associer un courriel malveillant, l’exécution de PowerShell, la création d’une tâche planifiée et une extraction vers un domaine nouvellement enregistré. Cette lecture réduit les faux positifs provoqués par des événements isolés. Le référentiel MITRE ATT&CK fournit une grammaire commune pour décrire les tactiques et techniques observées (MITRE ATT&CK). L’agent ne remplace pas cette modélisation, il l’exploite pour hiérarchiser les investigations.

Les réponses encadrées Les agents peuvent exécuter des actions limitées, par exemple enrichir une adresse IP, ouvrir un ticket ou isoler un poste selon une règle validée. Un cas concret consiste à suspendre temporairement un compte compromis après plusieurs signaux concordants, puis à demander une validation humaine avant réactivation. Cette séparation entre recommandation et exécution réduit le risque d’une remédiation disproportionnée. Le guide CISA sur la réponse aux incidents rappelle la nécessité de préserver les preuves et de coordonner les décisions (CISA Incident Response). Toute action irréversible devrait rester soumise à approbation.

2. Les scénarios qui échappent encore à l’automatisation

Les données manquantes Un agent ne détecte que ce que ses capteurs observent, comprennent et conservent. Une PME dont les journaux SaaS sont désactivés peut manquer une création de règle de transfert dans Microsoft 365, même si l’attaque est ensuite correctement analysée par le modèle. Une journalisation partielle produit alors une conclusion faussement rassurante. Le Centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques recommande d’identifier précisément les sources utiles à la détection (ANSSI, journalisation). L’inventaire des flux doit précéder le choix de l’agent.

Les abus légitimes L’usage d’identifiants valides reste difficile à distinguer d’une activité normale, surtout lorsque l’attaquant agit pendant les horaires habituels. Un compte d’administrateur compromis peut consulter des fichiers, créer une boîte aux lettres ou modifier une stratégie sans produire de logiciel malveillant. L’agent repère parfois une anomalie de séquence, mais il ne connaît pas toujours la justification métier. Les recommandations MITRE concernant les techniques d’utilisation de comptes valides décrivent cette difficulté (MITRE T1078). Une validation par le propriétaire du processus demeure nécessaire.

Les attaques contre modèles Les agents IA peuvent être influencés par des contenus conçus pour détourner leur analyse. Un courriel contenant des instructions dissimulées, un ticket manipulé ou une page web compromise peut tenter de faire ignorer un indicateur ou d’exécuter une action non prévue. Ce risque relève de l’injection indirecte de consignes, particulièrement sensible pour les agents disposant d’outils. Le projet OWASP consacré aux applications génératives recense ces menaces et leurs mesures de réduction (OWASP Top 10 for LLM Applications). Les entrées externes doivent rester non fiables par défaut.

Les attaques inédites Un agent entraîné ou configuré sur des signaux connus ne garantit pas la détection d’une méthode nouvelle. Une campagne peut exploiter une faiblesse de configuration, un outil interne détourné ou une chaîne d’accès encore absente des référentiels. Les modèles génératifs peuvent produire une hypothèse plausible, mais aussi relier abusivement des événements sans rapport. Le rapport Verizon DBIR documente chaque année l’évolution des modes d’intrusion à partir d’incidents déclarés (Verizon DBIR). Les exercices de chasse, les règles déterministes et la veille restent donc indispensables.

3. Le cadre opérationnel pour éviter la confiance excessive

Les preuves avant l’action Chaque recommandation d’agent devrait être accompagnée des événements sources, de leur chronologie et d’un niveau d’incertitude compréhensible. Un ticket indiquant seulement « activité probablement malveillante » ne permet pas à un analyste de décider rapidement ni de défendre son choix devant la direction. Pour un compte compromis, l’analyste doit retrouver l’adresse source, les ressources consultées, les changements effectués et les mesures déjà prises. Le NIST recommande une approche structurée de la réponse aux incidents, incluant analyse, décision et amélioration (NIST SP 800-61). La sortie doit rester vérifiable.

Les droits minimaux Un agent connecté à un outil de sécurité dispose souvent de privilèges qui dépassent son besoin réel. Dans une ETI, une architecture prudente sépare la lecture des journaux, l’enrichissement, la création de tickets et l’isolement des équipements. Un agent chargé d’analyser les courriels ne devrait pas pouvoir supprimer une boîte aux lettres ou modifier une politique globale. Les contrôles d’accès recommandés par l’ANSSI s’appliquent aussi aux comptes techniques et aux services automatisés (ANSSI, administration sécurisée). Chaque permission doit avoir un propriétaire et une échéance de revue.

Les tests en conditions réelles Avant déploiement, un agent doit être évalué sur des cas bénins, des incidents confirmés et des données incomplètes. Une entreprise peut rejouer un hameçonnage simulé, une compromission de compte Microsoft 365 et une exfiltration vers un service autorisé, puis mesurer les alertes produites et les actions proposées. Les résultats doivent inclure les erreurs de détection, les délais et les interventions humaines. MITRE propose une méthodologie d’évaluation des capacités de détection dans ses évaluations ATT&CK (MITRE Engenuity). Un pilote limité vaut mieux qu’un déploiement irréversible.

La gouvernance des décisions L’agent ne doit jamais devenir l’unique arbitre d’un incident affectant une personne, une activité critique ou une obligation réglementaire. Les procédures doivent préciser qui valide l’isolement, qui autorise la restauration et qui conserve les preuves. Elles doivent aussi prévoir l’arrêt du service si les résultats deviennent incohérents ou si une source de données est indisponible. Le règlement européen sur l’intelligence artificielle impose une approche de gestion des risques pour certains systèmes concernés (Commission européenne, AI Act). Pour un RSSI, cette gouvernance complète les contrôles techniques, elle ne les remplace pas.

Tableau comparatif

Agent ou méthode	Télémétrie exploitée	Détections et analyses pertinentes	Limites et angles morts	Validation humaine et sources
Microsoft Security Copilot	Incidents Microsoft Defender XDR, Microsoft Sentinel, Entra ID, Intune et données connectées	Corrélation d’alertes, synthèse d’incidents, analyse de scripts, requêtes KQL générées ou expliquées	Dépendance à la qualité des connecteurs et des journaux, risque d’interprétation erronée, visibilité réduite hors écosystème Microsoft	Validation des recommandations par un analyste. Documentation Microsoft Security Copilot
CrowdStrike Charlotte AI	Télémétrie Falcon : postes, serveurs, identités, charges cloud et événements réseau intégrés	Recherche en langage naturel, résumé d’incidents, investigation d’hôtes et aide à la réponse dans Falcon	Ne remplace pas la couverture EDR ni la qualité des règles de détection, limites possibles sur les environnements non connectés	Actions sensibles soumises aux contrôles et autorisations de la plateforme. Documentation CrowdStrike Charlotte AI
SentinelOne Purple AI	Données Singularity provenant des terminaux, identités, workloads cloud et sources intégrées	Interrogation conversationnelle, regroupement d’alertes, explication de comportements et génération de requêtes	Résultats dépendants du périmètre Singularity, risque de faux positifs et de conclusions incomplètes sur les systèmes non instrumentés	Revue des preuves et des événements avant toute remédiation. Documentation SentinelOne Purple AI
Google Gemini in Security Operations	Journaux SIEM Google Security Operations, détections, renseignements sur les menaces et données chronologiques	Recherche de menaces, synthèse d’alertes, traduction de requêtes, analyse d’événements et assistance à l’investigation	Les réponses peuvent manquer de contexte métier, la qualité dépend de l’ingestion et de la normalisation des journaux	Conservation des journaux sources et vérification par l’analyste. Documentation Google Cloud Gemini in Security Operations
Analyse comportementale EDR sans agent génératif	Événements de processus, réseau, fichiers, registre, identité et politiques de sécurité	Détection de comportements connus ou anormaux, blocage d’exécution, corrélation technique et réponse automatisée	Détection limitée face aux comptes compromis légitimes, aux attaques lentes et aux activités hors périmètre de l’EDR	Paramétrage des seuils, exceptions contrôlées et investigation manuelle. Référentiel MITRE ATT&CK, techniques et logiciels documentés
SIEM avec règles et corrélation classiques	Journaux d’authentification, pare-feu, VPN, DNS, proxy, applications et systèmes	Détection déterministe d’indicateurs, corrélation temporelle, contrôle de conformité et recherche rétrospective	Sensibilité aux journaux absents ou incomplets, faible compréhension du contexte et contournement possible par des techniques inédites	Revue des règles, tests réguliers et enrichissement par le renseignement. NIST SP 800-92 et MITRE ATT&CK

Quelles erreurs faut-il éviter ?

Confondre corrélation et preuve reste une erreur fréquente avec les agents qui analysent journaux, EDR et identités. Un enchaînement crédible, connexion inhabituelle, création d’un compte, exécution PowerShell, peut produire une conclusion trop affirmative alors que chaque événement possède une explication légitime. Les modèles génératifs complètent parfois les éléments absents au lieu de signaler l’incertitude. Le rapport d’incident doit donc distinguer faits observés, hypothèses et données manquantes. Les recommandations de l’ANSSI sur l’IA générative invitent précisément à contrôler les sorties et leur traçabilité, plutôt qu’à les traiter comme des preuves.

Nourrir l’agent avec des données propres en apparence peut masquer une lacune critique : les journaux disponibles ne couvrent pas les comptes de service, les équipements OT ou les applications SaaS. L’agent détecte alors correctement les signaux présents, mais conclut à tort que l’absence d’événement signifie l’absence d’attaque. Les campagnes contre Microsoft 365 l’ont illustré, avec des compromissions passant par des jetons valides et des règles de boîte aux lettres. MITRE ATT&CK documente ces techniques, notamment T1078 et T1098. Vérifiez donc la couverture réelle avant d’évaluer la qualité des détections.

Autoriser la remédiation automatique après une analyse convaincante expose à un piège opérationnel : l’agent peut isoler le mauvais poste, révoquer le compte d’un administrateur ou supprimer un artefact utile à l’investigation. Une alerte issue d’un logiciel de sécurité compromis peut aussi déclencher une action parfaitement cohérente, mais hostile. Les incidents liés à SolarWinds ont rappelé qu’une chaîne de confiance technique peut être manipulée. Conservez une validation humaine pour les actions irréversibles, imposez des fenêtres d’exécution et journalisez la décision, le périmètre ainsi que la possibilité de retour arrière.

Tester uniquement sur des alertes historiques donne une illusion de performance. Un agent peut reproduire les conclusions attendues dans vos tickets tout en échouant face à une consigne malveillante placée dans un fichier, un courriel ou un commentaire de ticket. Les travaux OWASP sur le prompt injection montrent que des instructions externes peuvent détourner un modèle chargé d’exécuter des actions. Séparez les contenus à analyser des instructions système, limitez les outils accessibles et organisez des tests adversariaux. Sans cette vérification, la détection peut fonctionner, tandis que l’orchestration devient la surface d’attaque.

Conclusion

Une capacité ciblée Les agents IA repèrent efficacement des signaux répétitifs, corrèlent des journaux, enrichissent des alertes et accélèrent le triage lorsque les données sont accessibles, structurées et correctement contextualisées. Ils restent moins fiables face aux attaques inédites, aux chaînes d’attaque incomplètes, aux abus légitimes de privilèges et aux environnements mal instrumentés. Pour votre PME ou ETI, leur valeur dépend donc moins de l’autonomie affichée que de la qualité des sources, des règles d’escalade et de la supervision humaine. Consultez aussi notre guide sur les agents IA en SOC.

Une autonomie sous contrôle Confier une réponse automatique à un agent revient à déléguer une décision opérationnelle, avec des conséquences potentiellement coûteuses. Les actions destructrices, la désactivation d’un compte critique ou l’isolement d’un serveur doivent rester encadrés par des seuils, une validation humaine et des journaux d’audit exploitables. Les tests doivent couvrir les faux positifs, les erreurs de contexte, l’empoisonnement des données et les contournements par ingénierie sociale. La comparaison des solutions mérite une lecture distincte dans notre analyse des plateformes SOC augmentées.

Une feuille de route réaliste La priorité consiste à sélectionner quelques scénarios mesurables, tels que l’enrichissement d’alertes, la qualification initiale ou la recherche dans les journaux, puis à vérifier les résultats sur des incidents connus. Documentez les limites, les droits accordés, les dépendances au fournisseur et les modalités de réversibilité avant tout élargissement. Les agents IA peuvent renforcer une équipe sous tension, mais ils ne remplacent ni l’architecture de sécurité, ni la compétence d’analyse, ni la responsabilité du RSSI. Pour approfondir, consultez ce dossier sur la gouvernance des agents IA.