Quand les défenseurs lisent encore l’alerte, les attaquants ont déjà passé la main. Le rapport M-Trends 2026 publié par Mandiant en mars 2026 chiffre ce basculement : le délai médian entre la compromission initiale et la transmission de l’accès à un second groupe offensif est tombé à 22 secondes, contre plus de huit heures en 2022. Sur la même période, l’IA générative est passée du statut de gadget à celui de force multiplicatrice utilisée à toutes les étapes de la chaîne d’attaque, du phishing hyper-personnalisé jusqu’aux malwares qui interrogent un grand modèle de langage en pleine exécution.
Ce guide pose le cadre de la cybersécurité agentique : la défense par agents IA autonomes ou semi-autonomes intégrés au SOC, et la défense contre des attaquants qui s’appuient eux-mêmes sur l’IA. On y croise les chiffres clés de M-Trends 2026, les recommandations du CERT-FR (notamment le bulletin CERTFR-2026-CTI-001 du 4 février 2026 et l’alerte CERTFR-2026-ACT-016 du 13 avril 2026), et les briques techniques opérationnelles : SIEM open source, frameworks d’agents (LangChain, MCP), modèles de menaces propres aux LLM, garde-fous de production.
Sommaire
- L’état du champ de bataille en 2026
- Trois concepts à clarifier avant tout déploiement
- L’IA défensive : SOC AI, triage SIEM, riposte automatisée
- L’IA offensive : ce que les attaquants font déjà
- Ce que l’ANSSI exige des RSSI en 2026
- Architecture de référence d’un SOC augmenté par agents
- Mises en pratique pas à pas
- Erreurs fréquentes à éviter
- Questions fréquentes
- Références
L’état du champ de bataille en 2026
Le rapport M-Trends 2026 s’appuie sur plus de 500 000 heures de réponse à incident menées par Mandiant et Google Threat Intelligence Group sur l’année 2025. Trois chiffres résument la fenêtre de réaction réelle d’un SOC moderne. D’abord, les 22 secondes de délai médian entre la compromission initiale et le passage de l’accès à un opérateur post-exploitation, contre plus de huit heures en 2022. Ensuite, le délai médian de détection : 9 jours quand l’organisation détecte elle-même l’intrusion (en amélioration depuis 10 jours en 2024), mais 25 jours quand l’alerte vient d’un tiers (FBI, partenaire, victime de la compromission en aval), contre 11 jours en 2024. Enfin, la persistance des exploits comme premier vecteur d’entrée (32 % des intrusions, sixième année consécutive en tête), suivis désormais par le vishing (11 %, ingénierie sociale par appel téléphonique), porté en grande partie par la qualité des voix synthétiques produites par IA et par des opérations contre les help desks IT.
Côté outils, Google Threat Intelligence Group (GTIG) documente l’apparition de familles de malwares « LLM-aware » comme PROMPTFLUX et PROMPTSTEAL. PROMPTFLUX, un dropper VBScript, interroge périodiquement l’API Gemini avec une clé codée en dur pour obtenir de nouvelles techniques d’obfuscation et se réécrire à la volée. PROMPTSTEAL, attribué au groupe APT28, interroge le modèle Qwen2.5-Coder-32B-Instruct via l’API Hugging Face pour générer dynamiquement les commandes à exécuter — la première observation publique d’un malware utilisant un LLM en opération réelle. Le ransomware suit la même trajectoire d’industrialisation : les opérateurs ne se contentent plus de chiffrer et d’exfiltrer, ils ciblent désormais les services d’identité, les plans de gestion de virtualisation et l’infrastructure de sauvegarde pour empêcher toute restauration.
Côté défense, le constat est sans appel : aucun analyste humain ne peut réagir en 22 secondes. La seule réponse réaliste est l’agent — un programme capable d’observer une alerte, de la croiser avec d’autres signaux, de prendre une décision conservatoire (isoler la machine, révoquer le token, geler le compte) puis de remonter le contexte enrichi à un opérateur humain pour validation. C’est ce qu’on appelle un SOC AI ou SOC augmenté par agents.
Trois concepts à clarifier avant tout déploiement
Agent IA, copilote, automation : ce n’est pas la même chose
Une automation classique (script SOAR, playbook Cortex XSOAR, règle Wazuh active-response) suit un arbre de décision déterministe. Un copilote propose des actions à un humain qui décide. Un agent IA, lui, choisit ses propres outils et enchaîne plusieurs appels (recherche, requête API, écriture) pour atteindre un objectif formulé en langage naturel. La frontière compte : un copilote bien conçu reste sous contrôle d’un analyste, alors qu’un agent autonome peut, sans garde-fous, exécuter une action irréversible sur la base d’une hallucination ou d’une injection de prompt.
SIEM, SOAR, XDR : où se branche l’IA ?
Le SIEM (Security Information and Event Management) collecte les logs et applique des règles de détection. Le SOAR (Security Orchestration, Automation and Response) orchestre la réponse. Le XDR (Extended Detection and Response) corrèle endpoint, réseau, identité et cloud. L’agent IA s’insère typiquement entre le SIEM et le SOAR : il consomme l’alerte SIEM, l’enrichit (réputation IP, géolocalisation, contexte utilisateur), formule une hypothèse de menace et déclenche, après validation, le playbook SOAR. Wazuh, Splunk, Elastic Security, OpenSearch ou Microsoft Sentinel jouent tous le rôle de SIEM ; l’agent peut être bâti sur LangChain, LangGraph, Semantic Kernel ou un serveur MCP custom.
MCP, le standard d’interopérabilité qui s’impose
Le Model Context Protocol, ouvert par Anthropic en novembre 2024 et désormais supporté par OpenAI, Google et la plupart des éditeurs SIEM, normalise la façon dont un agent appelle un outil externe. Pour la cybersécurité, c’est l’équivalent de ce que JDBC a été pour les bases de données : une interface unique pour interroger Wazuh, VirusTotal, MISP, ServiceNow ou Active Directory depuis n’importe quel modèle. C’est aussi un nouveau périmètre d’attaque, abordé en détail plus loin.
L’IA défensive : SOC AI, triage SIEM, riposte automatisée
La promesse d’un SOC augmenté par agents tient en trois mots : triage, enrichissement, endiguement. Le triage trie le bruit du signal. L’enrichissement ajoute le contexte qu’un analyste de niveau 1 mettrait dix minutes à rassembler. L’endiguement applique une mesure conservatoire avant qu’un humain ne valide la suite. Les premières données quantitatives publiques convergent : Microsoft documente une réduction de l’ordre de 30 % du temps moyen de résolution sur les organisations équipées de Security Copilot trois mois après adoption, et plusieurs analyses notent que les analystes juniors peuvent désormais traiter des tâches autrefois réservées aux niveaux 3 et 4. Ce gain libère les analystes humains pour la chasse aux menaces.
Le triage par agent : ce qui change vraiment
Un agent de triage ne remplace pas la règle SIEM, il la post-traite. Une alerte Wazuh sur un échec d’authentification SSH suivi d’une réussite peut signifier un brute-force réussi, ou simplement un utilisateur fatigué qui a tapé son mot de passe deux fois. L’agent vérifie l’IP source, son historique sur les 30 derniers jours, le user-agent, la géolocalisation, croise avec les voyages d’affaires connus, interroge le CMDB pour identifier la criticité de la machine cible, puis classe l’alerte sur une échelle de 1 à 10 avec un raisonnement traçable. C’est ce raisonnement traçable, audit-friendly, qui justifie le passage à l’agent : un humain peut relire et contester la décision en lisant un paragraphe plutôt qu’en remontant trente requêtes Lucene.
L’enrichissement : MCP comme couche de connecteurs
Là où la veille SOAR exigeait un connecteur dédié par source, MCP permet à l’agent de découvrir dynamiquement les outils disponibles. Un même agent peut interroger Wazuh pour les logs, VirusTotal pour la réputation d’un hash, AbuseIPDB pour une IP, Active Directory pour le contexte d’un compte, et ServiceNow pour ouvrir un ticket. Chaque outil expose un schéma JSON, l’agent choisit l’appel pertinent. Le gain n’est pas seulement économique, il est sécuritaire : moins de code custom, moins de credentials dispersés, un journal centralisé des appels.
L’endiguement : la frontière à ne pas franchir sans garde-fou
C’est ici que le bulletin CERTFR-2026-ACT-016 prend tout son sens. L’ANSSI déconseille formellement le déploiement en production d’agents IA autonomes — capables d’agir sans validation — sur les postes de travail des entreprises. La raison : un agent qui peut ouvrir un fichier, envoyer un email ou exécuter une commande shell devient une cible d’injection de prompt à très haute valeur. Pour la riposte automatisée, le bon réglage est un mode two-key : l’agent prépare l’action (commande de quarantaine endpoint, révocation de session, blocage IP au pare-feu), produit le diff exact qui sera appliqué, et attend qu’un humain valide. Pour les actions à très faible risque (révocation d’un token jetable, ajout temporaire d’une IP en greylist), un mode totalement automatique reste défendable, à condition d’un journal d’audit immuable et d’une procédure de rollback testée.
L’IA offensive : ce que les attaquants font déjà
Le rapport CERTFR-2026-CTI-001 du 4 février 2026 est la première synthèse publique française dédiée à l’usage offensif de l’IA générative. Il documente quatre familles d’usages observées dans des opérations réelles : reconnaissance et OSINT, ingénierie sociale, développement de code malveillant, et désinformation ciblée. Côté acteurs étatiques, le bulletin cite des opérateurs liés à la Corée du Nord créant de faux profils LinkedIn pour approcher des cibles dans la défense et la finance, et des groupes liés à l’Iran utilisant Gemini pour identifier des experts à compromettre.
Le phishing devient hyper-personnalisé
L’email frauduleux générique appartient au passé. Les campagnes documentées en 2025 et 2026 combinent scraping de profils publics, reformulation par LLM dans le ton de l’expéditeur usurpé, et A/B testing à grande échelle. Le résultat est un message qui mentionne le bon prénom du destinataire, une référence interne plausible (un projet réel mentionné sur le site de l’entreprise) et une demande cohérente avec son rôle. Mandiant note dans M-Trends 2026 que ces campagnes hyper-personnalisées ont fait passer le vishing de la quatrième à la deuxième place des vecteurs d’accès initial réussis.
Les malwares qui dialoguent avec un LLM
PROMPTFLUX et PROMPTSTEAL, documentés par Google Threat Intelligence Group, illustrent une nouvelle classe de menaces. Ces souches embarquent une clé d’API ou exploitent un compte compromis pour interroger un grand modèle pendant leur exécution. Elles peuvent ainsi se réécrire à intervalle régulier pour échapper aux signatures (le « Thinking Robot » de PROMPTFLUX requête Gemini pour obtenir de nouvelles techniques d’évasion), ou décider dynamiquement des commandes à exécuter en fonction d’une requête formulée en langage naturel (PROMPTSTEAL via Qwen sur Hugging Face). Le défi pour le défenseur est double : la signature traditionnelle ne fonctionne plus, et le trafic sortant vers une API LLM légitime (generativelanguage.googleapis.com, api-inference.huggingface.co, api.openai.com, api.anthropic.com) ne déclenche aucune alerte de filtrage classique.
L’empoisonnement des données : 250 documents suffisent
Une étude publiée en octobre 2025 par Anthropic, le UK AI Security Institute et l’Alan Turing Institute démontre qu’il suffit de 250 documents malveillants dans un corpus d’entraînement pour installer une porte dérobée fiable dans un modèle, indépendamment de sa taille (testé de 600 millions à 13 milliards de paramètres). Le résultat invalide l’hypothèse intuitive selon laquelle l’attaquant doit contrôler un pourcentage du corpus : un nombre fixe et modeste suffit. Pour un défenseur qui s’apprête à fine-tuner un LLM sur ses propres logs ou tickets ServiceNow, c’est une alerte rouge : la chaîne d’approvisionnement des données d’entraînement devient un périmètre à protéger comme un dépôt de code.
L’injection de prompt : la nouvelle XSS
L’OWASP, dans la version 2025 de son Top 10 for LLM Applications, classe l’injection de prompt en première position (LLM01:2025). Le mécanisme est simple : un attaquant glisse une instruction dans un contenu que l’agent va lire (un email, une page web, un ticket Jira, un commit message) et l’agent obéit comme si l’instruction venait de l’utilisateur. Pour un agent de triage SIEM qui lit un user-agent ou un nom de fichier compromis, l’injection peut le pousser à clore l’alerte ou à débloquer une IP malveillante. La défense passe par la séparation stricte des canaux : ce que l’utilisateur dit à l’agent, et ce que l’agent observe, ne doivent jamais transiter par le même contexte sans étiquetage explicite.
Ce que l’ANSSI exige des RSSI en 2026
L’alerte CERTFR-2026-ACT-016 du 13 avril 2026 fixe trois chantiers immédiats pour les responsables de la sécurité des systèmes d’information. Premier chantier : cartographier et proscrire le Shadow IT IA. Tout agent installé sans validation des équipes IT et RSSI doit être identifié et neutralisé. Cela inclut les extensions navigateur agentiques, les copilotes embarqués dans les suites bureautiques tierces, et les workflows n8n ou Make qui appellent une API LLM avec des données internes. Deuxième chantier : encadrer les agents validés par une analyse de risque dédiée, un journal d’audit immuable, une politique de moindre privilège (un agent qui lit ne doit pas pouvoir écrire), et une revue régulière des prompts système. Troisième chantier : former les utilisateurs à reconnaître une demande agentique anormale et à signaler tout comportement inattendu.
Le bulletin insiste sur un point souvent négligé : les greffons (plugins, tools, MCP servers) chargés dynamiquement par un agent s’exécutent avec les privilèges de l’application hôte. Un seul prompt mal intentionné peut déclencher une cascade d’actions système, de l’exfiltration de fichiers à l’envoi d’emails frauduleux. La conclusion pratique : tout agent doit tourner dans un compte de service dédié, avec uniquement les permissions strictement nécessaires, et toute extension de périmètre doit faire l’objet d’une revue de sécurité.
Architecture de référence d’un SOC augmenté par agents
Une architecture mature en 2026 s’organise en cinq couches superposées, chacune avec une responsabilité claire et des frontières de confiance explicites. Cette séparation est la condition pour qu’une compromission d’une couche ne contamine pas les autres et reste détectable.
- Collecte : agents Wazuh, Beats, Fluent Bit ou Vector sur les endpoints, les serveurs, les conteneurs et les équipements réseau. Tout passe par un message broker (Kafka, Redpanda) pour découpler la collecte de la corrélation.
- Détection : règles SIEM (Wazuh, Sigma, Elastic Detection Rules) et modèles ML supervisés pour les comportements anormaux. C’est la couche déterministe, celle qui produit les alertes brutes.
- Enrichissement agentique : un agent par classe d’alerte (authentification, exfiltration, exécution suspecte, scan réseau) consomme les alertes via une file dédiée, interroge les outils MCP autorisés, et produit un verdict structuré (sévérité, hypothèse, contexte, actions recommandées).
- Décision : pour les actions automatiques pré-approuvées, un workflow SOAR exécute. Pour les actions sensibles, l’alerte enrichie est routée vers un analyste humain avec le diff de l’action proposée.
- Audit : tous les appels d’outils, les prompts utilisés, les réponses du modèle, les décisions prises et les actions exécutées sont écrits dans un journal append-only signé. Sans cette couche, aucun retour en arrière n’est possible en cas d’incident impliquant l’agent lui-même.
Le choix du modèle (LLM commercial via API, modèle open source local type Llama 3 ou Mistral, ou hybride) dépend de la sensibilité des données. Les logs SIEM contiennent souvent des éléments à protéger : noms d’utilisateurs, structures de réseau interne, indicateurs de configuration. Pour une défense en profondeur, un déploiement local via vLLM ou Ollama, accessible uniquement depuis le sous-réseau SOC, élimine la dépendance à un fournisseur tiers et coupe la possibilité d’exfiltration via l’API du modèle.
Mises en pratique pas à pas
Trois tutoriels approfondissent les briques opérationnelles abordées ici. Chacun se lit indépendamment, mais l’ordre proposé construit une montée en compétence cohérente : d’abord installer le triage agentique sur un SIEM existant, ensuite apprendre à reconnaître les attaques pilotées par IA dans les logs, enfin sécuriser l’agent lui-même contre les injections et les abus.
- Triage SIEM par un agent IA — workflow LangChain et Wazuh pas à pas — comment connecter un agent à un SIEM Wazuh existant, écrire le prompt système, exposer les outils MCP, et tester sur des alertes réelles.
- Détecter une attaque pilotée par IA — prompt injection, deepfake vocal, malware LLM-aware — règles Sigma, signatures réseau, indicateurs comportementaux et procédure de réponse pour les nouvelles classes de menaces documentées par Mandiant et l’ANSSI.
- Sandboxer un agent IA en production — isolation, garde-fous, audit immuable — comment exécuter un agent dans un compte de service dédié, restreindre les outils MCP, journaliser les prompts et automatiser le rollback en cas de comportement anormal.
Erreurs fréquentes à éviter
| Erreur | Cause | Solution |
|---|---|---|
| Donner à l’agent les droits admin du SIEM | Facilité de développement | Compte de service dédié, lecture seule par défaut, escalade explicite par playbook |
| Mélanger prompt utilisateur et contenu observé | Concaténation naïve dans le prompt | Sections balisées, échappement, structured prompting (system/user/tool) |
| Auto-approuver toute action proposée | Confiance excessive dans le modèle | Mode two-key obligatoire pour les actions irréversibles |
| Pas de journal d’audit des appels LLM | Pas pensé à l’avance | Logger prompt, modèle, réponse, outils appelés, dans un store immuable |
| Utiliser un LLM cloud pour des logs sensibles | Choix par défaut | Évaluer un modèle local (Llama 3, Mistral) selon la classification des données |
| Ignorer les greffons MCP installés | Méconnaissance de la surface d’attaque | Inventaire régulier, allowlist stricte, revue à chaque mise à jour |
| Tester l’agent uniquement sur des alertes nominales | Manque de scénarios offensifs | Red team dédiée à l’injection de prompt, jeux de données empoisonnés |
Questions fréquentes
Faut-il fine-tuner un modèle dédié à la cybersécurité ou utiliser un modèle généraliste ?
En 2026, les retours d’expérience publiés par Microsoft Security Copilot, IBM QRadar Suite et plusieurs équipes open source convergent : un modèle généraliste de bonne taille (GPT-4 class, Claude Sonnet, Llama 3 70B) avec un prompt système rigoureux et un accès outils via MCP donne d’aussi bons résultats qu’un modèle fine-tuné, pour un coût opérationnel moindre. Le fine-tuning ne devient rentable qu’au-delà d’un certain volume de tickets traités et pour des cas très spécifiques (analyse de logs propriétaires, langage métier).
Un agent IA peut-il remplacer un analyste de niveau 1 ?
Non, et ce n’est pas la bonne question. Un agent absorbe le triage répétitif, mais l’analyste reste indispensable pour décider, valider les actions sensibles et chasser les menaces qui échappent à la détection automatique. Le bon dimensionnement est un analyste qui supervise plusieurs agents en parallèle, avec une charge de validation intelligente et non une saisie de tickets.
Comment justifier le coût d’un LLM appelé sur chaque alerte ?
Le coût se contrôle par trois leviers : filtrer en amont avec les règles SIEM (l’agent ne voit que ce qui mérite triage), utiliser un petit modèle pour la pré-classification puis un grand modèle uniquement sur les alertes ambiguës, et basculer sur un modèle local pour les flux à très haut volume. Sur un SOC traitant 50 000 alertes par jour, le coût mensuel d’un agent bien réglé reste inférieur au salaire chargé d’un analyste équivalent.
Que dit l’AI Act européen sur les agents de cybersécurité ?
Le règlement (UE) 2024/1689, entré en application progressive depuis février 2025, classe la plupart des outils de cybersécurité en risque limité, sauf s’ils prennent des décisions automatisées affectant des personnes (par exemple, blocage automatique d’un employé). Dans ce cas, des obligations de transparence et de supervision humaine s’appliquent. La documentation du système, le journal d’audit et la possibilité de contestation sont les éléments clés pour la conformité.
Comment détecter qu’un agent défensif a été compromis ?
Trois signaux faibles à surveiller : variations soudaines du taux de classification (un agent qui se met à clore beaucoup plus d’alertes), apparition d’outils MCP appelés en dehors de l’allowlist, prompts système modifiés sans changement de version git. Une supervision dédiée du comportement de l’agent — un meta-agent ou un dashboard Grafana — est indispensable.
Faut-il interdire ChatGPT et Claude aux équipes SOC ?
L’interdiction sèche pousse au Shadow IT. La position recommandée par l’ANSSI est l’encadrement : interdire l’envoi de données classifiées, fournir une alternative sanctionnée (modèle local ou compte enterprise avec engagement de non-rétention), former les équipes sur ce qui peut ou ne peut pas sortir, et auditer régulièrement les usages.
Références
- Mandiant / Google Cloud, M-Trends 2026 Report — synthèse annuelle des incidents traités, mars 2026.
- ANSSI, CERTFR-2026-CTI-001 — L’IA générative face aux attaques informatiques, 4 février 2026.
- ANSSI, CERTFR-2026-ACT-016 — Recommandations sur les agents IA autonomes, 13 avril 2026.
- OWASP, OWASP Top 10 for LLM Applications, version 2025 — LLM01 Prompt Injection.
- Anthropic, Model Context Protocol — spécification, ouvert depuis novembre 2024.
- Anthropic, UK AI Security Institute & Alan Turing Institute, A small number of samples can poison LLMs of any size, octobre 2025.
- Google Threat Intelligence Group, GTIG AI Threat Tracker — PROMPTFLUX et PROMPTSTEAL.
- Wazuh, documentation officielle — SIEM open source utilisé dans les tutoriels associés.
- Règlement (UE) 2024/1689 du Parlement européen et du Conseil — AI Act, application progressive depuis février 2025.