L'IA agentique : la surface d'attaque que personne ne voit

En 2026, les agents IA autonomes ne sont plus un concept de recherche. Ils sont en production dans vos SI, ils gèrent des pipelines de données critiques, automatisent des workflows RH et financiers, prennent des décisions en temps réel sur des systèmes qui touchent directement vos clients. Et pendant que vos équipes sécurité bataillent sur les CVE classiques, ces agents créent silencieusement une surface d'attaque d'une ampleur que personne n'a encore vraiment mesurée. Selon le Ponemon Institute, 48 % des professionnels de la cybersécurité considèrent l'IA agentique comme le principal vecteur de menace d'ici fin 2026. Pourtant, les modèles de menace des SOC n'ont pas bougé d'un millimètre pour intégrer cette réalité. Quand on déploie un agent IA capable de lire des fichiers, d'appeler des API et d'exécuter du code à la vitesse de la machine, on crée un utilisateur à privilèges que personne ne supervise vraiment. C'est le problème que je vois se répéter chez mes clients depuis dix-huit mois, et il est temps d'en parler sans détour : l'IA agentique est votre prochain angle mort majeur, et vous avez probablement déjà le problème en production aujourd'hui.

Une surface d'attaque créée par conception, pas par accident

Le terme "dark matter applications" décrit le phénomène mieux que n'importe quelle métaphore de séminaire. Selon Gartner (2025), l'entreprise moyenne dispose de plus de 400 applications qui fonctionnent en dehors du périmètre de son système de gestion des identités centralisé. Ajoutez-y les agents IA autonomes qui s'authentifient via des tokens de service non rotés, des clés API stockées en variables d'environnement dans des manifestes Kubernetes, des credentials hardcodés dans des workflows n8n ou Make.com, et vous obtenez une surface d'attaque massive, non gouvernée, et créée délibérément par les équipes métier pour gagner en vélocité.

Les chiffres de CrowdStrike (Global Threat Report 2026) sont édifiants : le temps moyen de mouvement latéral d'un attaquant est passé sous les 2 minutes 7 secondes en 2025, contre 18 minutes en 2023. Ce n'est pas un hasard de calendrier. C'est la conséquence directe d'un écosystème applicatif où des agents autonomes avec des accès étendus fonctionnent 24h/24 sans supervision humaine, créant des chemins de pivot que des outils d'automatisation d'attaque peuvent exploiter à vitesse machine.

J'ai audité récemment une infrastructure mid-market (800 salariés, secteur services financiers) où un agent IA de traitement documentaire — une solution SaaS intégrée en trois clics par l'équipe marketing — disposait d'un accès en lecture à l'intégralité du SharePoint de l'entreprise, incluant les drives RH et les documents contractuels. Aucune journalisation de ses requêtes. Aucun scope limité. Aucune revue d'accès planifiée. C'est l'équivalent d'un compte de service avec les droits d'un admin, que personne n'a mis dans son inventaire IAM, et qui traite 10 000 documents par jour. Quand on m'a demandé quand cet agent avait été déployé, personne dans l'équipe IT ne le savait. Il avait été mis en place directement par la DSI marketing via un connecteur Zapier.

Selon le rapport ANSSI sur la sécurité des systèmes d'information 2025, les incidents liés à des comptes de service non supervisés représentent 34 % des causes de compromission initiale dans les incidents traités par le CERT-FR l'an dernier. Les agents IA autonomes sont des comptes de service sur-outillés, et ils arrivent dans vos SI sans passer par la case DSI.

Analyse technique : pourquoi les agents IA sont structurellement dangereux

Pour comprendre pourquoi l'IA agentique est un vecteur d'attaque particulièrement efficace, il faut déconstruire son architecture technique. Un agent IA moderne est composé de trois éléments : un modèle de langage (le "cerveau"), un orchestrateur (le "chef de projet"), et des outils (les "bras"). C'est la combinaison de ces trois éléments qui crée la dangerosité.

L'orchestrateur — LangGraph, CrewAI, AutoGen, LangChain — gère la chaîne de décision et les appels aux outils. Ces outils sont des fonctions Python ou des appels API qui permettent à l'agent de lire des fichiers, d'exécuter des commandes shell, d'appeler des APIs internes, d'envoyer des emails. Quand un attaquant peut influencer ce que l'agent reçoit en entrée — via une injection de prompt dans un document qu'il analyse, via un email piégé dans une boîte qu'il surveille, via un fichier JSON dans un répertoire qu'il scrute — il peut détourner la chaîne de décision et faire exécuter à l'agent des actions qu'aucun humain n'a autorisées.

Les attaques par injection de prompt indirecte (OWASP LLM Top 10, LLM01) sont documentées depuis 2023, mais leur surface d'impact était limitée aux chatbots sans outils. Appliquées à un agent avec accès à un système de fichiers, une base de données, une API d'envoi d'emails, elles deviennent dévastices. Le groupe ATLAS-7 a démontré en janvier 2026 qu'une injection de prompt dans un CV soumis à un système de recrutement automatisé IA pouvait exfiltrer les données des 50 candidats précédents et envoyer les informations vers un webhook externe. Aucun CVE. Aucun patch. La vulnérabilité est dans la conception architecturale de l'agent.

Le problème s'aggrave avec les architectures multi-agents. Un agent de planification qui délègue à un agent d'exécution qui appelle un agent de validation : chaque maillon est un point de pivot. Si l'agent de planification est compromis, l'attaquant hérite transitoirement des droits de tous les agents subordonnés. Ce n'est pas de l'escalade de privilèges au sens classique — c'est de la délégation d'autorité détournée, sans aucune trace dans les journaux IAM traditionnels.

Mandiant (M-Trends 2026) identifie déjà les "agent-in-the-middle attacks" comme une catégorie émergente : un attaquant qui compromet l'environnement d'exécution d'un agent (les variables d'environnement, le fichier de configuration, les prompts système stockés en base) peut modifier silencieusement le comportement de l'agent pour l'ensemble de ses interactions futures. Pas de nouveau malware. Pas de nouvel accès à tracer. Une simple modification de quatre lignes de configuration.

Trois incidents documentés qui ont changé la donne

Les cas concrets permettent de sortir du théorique. Voici trois incidents qui ont marqué le premier semestre 2026 et que je cite régulièrement lors de mes interventions.

FortiGate × IA générative — Février 2026. Un acteur de menace peu sophistiqué a compromis plus de 600 appliances FortiGate dans 55 pays en s'appuyant sur des outils d'IA générative commerciaux pour planifier son attaque, adapter ses payloads en temps réel, et automatiser le mouvement latéral après exploitation de CVE-2024-21762. Ce n'était pas un APT étatique avec des millions de budget de R&D. C'était un individu augmenté par l'IA. L'ANSSI a publié une alerte en urgence. La leçon : l'asymétrie entre attaquant et défenseur s'est inversée. Les défenseurs ont besoin d'experts, de processus, de comités de validation. L'attaquant a besoin d'un prompt et d'une carte de crédit prépayée.

Pipeline CI/CD compromis via agent code review — Mars 2026. Une entreprise tech britannique de taille intermédiaire a vu son pipeline de déploiement compromis via son agent IA de revue de code. L'attaquant a soumis une pull request contenant une injection de prompt cachée dans un commentaire de documentation. L'agent a approuvé le code, déclenché le déploiement, et exfiltré les secrets AWS du runner CI vers un serveur externe. Détection : 19 jours après compromission initiale. Source : National Cyber Security Centre (NCSC-UK), bulletin du 15 mars 2026.

Agent de customer support — Exfiltration de données PII — Avril 2026. Un opérateur télécoms français (non nommé dans le rapport CERT-FR mais identifié dans plusieurs publications sectorielles) a exposé les données de plus de 40 000 clients via son chatbot de support propulsé par IA. L'injection de prompt permettait de faire répondre l'agent avec les informations de compte d'autres utilisateurs. Pas de piratage de base de données au sens classique. Pas de CVE. Une logique applicative défaillante, exploitée à l'échelle via un script automatisé.

Implications pratiques pour les RSSI : ce que votre gouvernance ne couvre pas encore

Je pose la même question dans tous mes audits depuis six mois : "Combien d'agents IA sont en production dans votre SI ?" La réponse la plus fréquente est "je ne sais pas exactement". C'est le premier problème. Vous ne pouvez pas sécuriser ce que vous ne savez pas compter.

Le framework NIST AI Risk Management (AI RMF 1.0) propose une approche de gouvernance, mais il reste très théorique sur l'implémentation opérationnelle. Les RSSI qui avancent le plus vite sur ce sujet sont ceux qui ont adapté leur processus de gestion des comptes de service pour y inclure les agents IA. Concrètement : chaque agent IA en production doit avoir une fiche d'identité dans le référentiel IAM (nom, propriétaire métier, accès accordés, date de révision), exactement comme un compte de service Active Directory.

La question du monitoring est encore plus mal adressée. Les SIEM actuels ne sont pas conçus pour traiter le volume et la vélocité des actions d'un agent autonome. Un agent de traitement documentaire peut générer des dizaines de milliers d'événements par heure — lire un fichier, appeler une API, écrire un résultat — avec une légitimité parfaite pour chaque action individuelle. La détection d'anomalie ne peut pas fonctionner à la granularité de l'événement ; elle doit fonctionner à la granularité de la séquence comportementale. C'est un chantier que très peu de SOC ont entamé.

Le principe du moindre privilège, pilier de la sécurité des identités depuis trente ans, s'applique directement aux agents IA mais nécessite une granularité que les outils actuels ne facilitent pas. Un agent qui résume des emails n'a pas besoin de lire le drive RH. Un agent de facturation n'a pas besoin d'accès à la base clients marketing. Ces distinctions existent dans vos politiques de sécurité pour les utilisateurs humains ; elles doivent exister pour vos agents.

Recommandations actionnables : par où commencer cette semaine

Je refuse les recommandations théoriques sans ordre de priorité. Voici ce que je ferai si j'arrive dans votre organisation demain matin avec pour mandat de sécuriser votre posture IA agentique.

• Inventaire immédiat (J+0 à J+7) : Identifiez chaque agent IA en production. Consultez les équipes IT, mais aussi les équipes métier — marketing, RH, finance, commercial. La majorité des agents sont déployés par le métier sans passer par la DSI. Utilisez les logs de trafic sortant pour identifier les appels vers les APIs des grands providers (OpenAI, Anthropic, Azure OpenAI, Google Vertex). Un agent qui appelle api.openai.com génère du trafic observable.
• Mapping des accès (J+7 à J+14) : Pour chaque agent identifié, documentez exactement quels accès il détient : scopes OAuth, tokens API, credentials, accès système de fichiers, droits base de données. Comparez avec le besoin métier réel. Dans 80 % des cas, vous trouverez des accès en excès significatifs.
• Isolation des credentials (J+14 à J+30) : Chaque agent doit avoir ses propres credentials, distincts de tout compte humain. Activez la rotation automatique de ces credentials (vault HashiCorp, AWS Secrets Manager, Azure Key Vault). Limitez la durée de vie des tokens. Interdisez les credentials partagés entre agents.
• Journalisation des actions (J+14 à J+45) : Instrumentez les orchestrateurs (LangSmith pour LangChain, Phoenix pour d'autres frameworks) pour capturer chaque action, chaque appel d'outil, chaque décision. Envoyez ces logs dans votre SIEM. Créez des alertes sur les actions anormales : appel vers une URL inconnue, lecture de fichier hors périmètre habituel, volume d'actions multiplié par 10 en 5 minutes.
• Tests d'injection de prompt (J+30 à J+60) : Incluez des scénarios d'injection de prompt dans vos prochains exercices red team. Si vous déployez un agent avec accès à des données sensibles, testez explicitement ce vecteur avant de le passer en production. Des frameworks comme Garak ou PyRIT permettent d'automatiser ces tests.
• Politique de déploiement (processus permanent) : Aucun agent IA avec accès à des données sensibles ne peut être déployé en production sans validation sécurité. Créez un formulaire de demande simple (5 questions : quel agent, quels accès demandés, quel propriétaire métier, quelle durée, quelle revue planifiée) et intégrez-le dans votre processus de gestion des changements.

Cadre de gouvernance pour les agents IA en entreprise : ce que les politiques de sécurité doivent couvrir

L'adoption des agents IA en entreprise est actuellement pilotée principalement par les équipes produit et métier, souvent avec un engagement minimal des équipes sécurité en amont. Cette situation crée des risques concrets et documentés. La gouvernance des agents IA doit être formalisée avant le déploiement, pas après un incident.

Une politique de sécurité pour les agents IA doit couvrir au minimum cinq domaines : le périmètre d'autorisation (quels systèmes l'agent peut interroger et modifier, avec approbation explicite pour chaque outil), la gestion des identités et des accès (l'agent doit disposer de son propre compte de service avec des permissions minimales, jamais des credentials d'un utilisateur humain), la journalisation complète et immuable de toutes les actions exécutées par l'agent, la supervision humaine pour les actions irréversibles (suppression de données, envoi d'e-mails externes, modifications de configuration), et les mécanismes d'arrêt d'urgence permettant de désactiver un agent immédiatement en cas de comportement anormal.

Le modèle de permission doit appliquer le principe du moindre privilège de manière encore plus stricte que pour les utilisateurs humains. Un agent IA ne doit avoir accès qu'aux données strictement nécessaires à sa tâche, et cet accès doit être temporel — révoqué automatiquement à la fin de chaque session de travail. Les accès permanents accordés à des agents IA constituent un risque d'escalade de privilèges particulièrement difficile à détecter.

Détection des comportements anormaux d'agents IA : nouveaux cas d'usage pour les équipes SOC

Les équipes SOC doivent développer de nouveaux scénarios de détection spécifiquement adaptés aux agents IA. Les comportements malveillants induits par des injections de prompt ou par une compromission de l'infrastructure d'exécution génèrent des patterns d'activité distincts des comportements humains normaux et des intrusions traditionnelles.

Les signaux d'alerte les plus pertinents incluent : une séquence d'appels API inhabituellement longue ou atypique pour l'agent concerné (l'exfiltration de données via un agent compromis se manifeste souvent par des appels répétés à des endpoints de lecture de données suivis d'appels vers des services externes), des tentatives d'accès à des ressources hors du périmètre d'autorisation défini, une modification des paramètres de configuration propres à l'agent (tentative de se donner des permissions supplémentaires), et des communications vers des endpoints réseau non répertoriés dans le comportement baseline de l'agent.

La baseline comportementale est la clé. Un agent IA légitime a un comportement très prévisible — il exécute les mêmes séquences d'appels dans le même ordre pour des tâches similaires. Tout écart significatif par rapport à cette baseline doit être investigué. Cette caractéristique rend les agents IA paradoxalement plus faciles à surveiller que les utilisateurs humains, à condition que la baseline soit correctement établie et que le monitoring soit en place depuis le déploiement initial.

Responsabilité juridique et assurance cyber : le statut ambigu des agents IA autonomes

L'introduction d'agents IA autonomes dans les processus métier crée des questions de responsabilité juridique encore largement non résolues en 2026. Lorsqu'un agent IA supprime des données clients suite à une injection de prompt, qui est responsable — l'organisation qui a déployé l'agent, le fournisseur du modèle de langage, ou l'éditeur du framework d'orchestration ? La réponse n'est pas évidente, et les jurisprudences commencent seulement à se former.

Du point de vue de l'assurance cyber, les polices existantes n'ont pas encore été adaptées pour couvrir explicitement les incidents causés par des agents IA autonomes. Les courtiers spécialisés recommandent de vérifier explicitement avec son assureur si les dommages causés par un agent IA — qu'il soit compromis de l'extérieur ou qu'il agisse de façon non conforme suite à une faute de configuration — sont couverts par la police en vigueur. En l'absence de couverture explicite, une clause d'exclusion peut s'appliquer, laissant l'organisation sans protection pour une catégorie de risques en forte croissance.

La documentation du cycle de vie de l'agent IA devient un enjeu légal : politiques de sécurité appliquées, tests de sécurité réalisés avant le déploiement, incidents antérieurs et mesures correctives, formation des opérateurs. Cette documentation constitue la preuve que l'organisation a exercé une diligence raisonnable, ce qui peut être déterminant en cas de litige ou de mise en cause réglementaire.

Conclusion

L'IA agentique est une révolution de productivité. C'est aussi une révolution pour les attaquants, qui bénéficient désormais d'une asymétrie sans précédent : un individu équipé d'outils IA peut conduire une attaque d'une sophistication qui nécessitait auparavant une équipe d'une dizaine de personnes. Les organisations qui survivront à cette transition seront celles qui auront traité leurs agents IA comme ce qu'ils sont réellement : des utilisateurs à privilèges élevés, nécessitant une gouvernance de sécurité aussi rigoureuse que leurs administrateurs humains. La fenêtre pour agir avant le premier incident majeur se ferme. Si vous n'avez pas encore commencé l'inventaire de vos agents IA, commencez cette semaine.

Standards émergents pour la sécurité des agents IA : MCP, A2A et les frameworks de gouvernance

La réponse de l'industrie aux risques des agents IA autonomes se structure progressivement autour de plusieurs initiatives de standardisation. Le protocole MCP (Model Context Protocol), développé par Anthropic et adopté par un nombre croissant d'éditeurs, définit une interface standardisée entre les agents LLM et les outils qu'ils utilisent — incluant des mécanismes d'audit des appels d'outils et de restriction des permissions par contexte. Le protocole A2A (Agent-to-Agent), proposé par Google, adresse quant à lui la communication sécurisée entre agents distincts, avec des mécanismes d'authentification mutuelle et de traçabilité des échanges inter-agents. Ces deux protocoles, encore en phase d'adoption, commencent à intégrer les exigences de sécurité que les RSSI doivent connaître pour évaluer les solutions commerciales qui les implémentent.

Du côté des frameworks de gouvernance, le NIST a publié en 2025 un profil spécifique pour les systèmes IA autonomes dans le cadre de son AI RMF (Risk Management Framework). Ce profil introduit des concepts directement applicables aux agents IA en production : la notion de trustworthy AI behavior vérifiable, les exigences de traçabilité des décisions automatisées, et les critères d'évaluation de la robustesse face aux entrées adversariales. L'adoption de ce référentiel comme grille d'audit interne des déploiements d'agents IA constitue une première mesure concrète pour les organisations qui cherchent à structurer leur gouvernance.

Tests de sécurité spécifiques aux agents IA : red teaming et évaluation de robustesse

La sécurité des agents IA ne peut pas être évaluée uniquement par les méthodes de pentest classiques. Un agent IA autonome présente des surfaces d'attaque nouvelles qui nécessitent des approches de test dédiées. Le prompt injection red teaming consiste à tester systématiquement la résistance de l'agent à des entrées malveillantes injectées dans son contexte — via des documents traités, des emails analysés, des pages web visitées — pour évaluer si ces injections peuvent modifier le comportement de l'agent ou lui faire exécuter des actions non autorisées. Les outils comme Garak (open source) ou les frameworks d'évaluation adversariale commerciaux permettent d'automatiser une partie de ces tests.

Le tool misuse testing évalue si l'agent peut être manipulé pour utiliser ses outils légitimes à des fins malveillantes : faire appel à une API de messagerie pour exfiltrer des données, utiliser un outil de recherche pour effectuer une reconnaissance, ou exploiter des permissions d'écriture pour modifier des configurations. Ce type de test révèle les failles dans la définition des garde-fous comportementaux de l'agent. Les résultats doivent alimenter directement la configuration des mécanismes de contrôle : validation humaine obligatoire pour certaines catégories d'actions, restrictions de périmètre par environnement, et alertes en temps réel sur les comportements déviants détectés par les journaux d'audit.

Intégration de la sécurité des agents IA dans le cycle de développement (AI-SDLC)

Comme pour la sécurité applicative classique, les contrôles de sécurité les plus efficaces sont ceux intégrés dès la conception des agents IA, et non ajoutés après déploiement. L'émergence de pratiques AI-SDLC (Software Development Lifecycle adapté à l'IA) structure cette intégration : modélisation des menaces spécifique à l'agent en phase de design, revue des permissions et des outils accordés avant tout déploiement en production, tests de sécurité automatisés dans les pipelines CI/CD incluant des scénarios d'injection, et surveillance continue en production avec des métriques de comportement anormal. Les équipes sécurité doivent s'impliquer dans la définition des system prompts des agents — ces instructions fondamentales qui définissent le comportement autorisé — en y intégrant explicitement les restrictions de sécurité et en les traitant comme du code critique soumis à revue.