De GenAI à Agentic AI : Évolution des Risques de Sécurité

La transition de la GenAI vers l'Agentic AI est l'une des évolutions technologiques les plus rapides et les plus significatives de l'histoire récente de l'informatique d'entreprise. En moins de trois ans, les organisations sont passées d'outils de génération de texte relativement passifs à des systèmes capables d'agir de manière autonome dans des environnements complexes. Cette transition n'est pas seulement une amélioration quantitative des capacités IA — c'est un changement qualitatif qui reconfigure fondamentalement le paysage des risques de sécurité. Comprendre précisément comment les risques évoluent entre la GenAI et l'Agentic AI est devenu une compétence stratégique pour les équipes de sécurité. Selon Gartner, les organisations qui n'auront pas mis à jour leur évaluation des risques IA pour intégrer les spécificités agentiques d'ici fin 2026 seront exposées à des incidents dont elles n'auront pas prévu la nature ni l'ampleur. Ce n'est pas de la fatalité — c'est de l'anticipation. Les risques GenAI classiques (fuites de données, hallucinations, biais) ne disparaissent pas avec l'Agentic AI : ils se combinent avec de nouveaux risques propres à l'autonomie et à la capacité d'action. L'enjeu est d'identifier clairement ce qui change, ce qui s'aggrave et ce qui est véritablement nouveau pour construire une stratégie de sécurité adaptée à cette nouvelle réalité.

Ce qui ne change pas : les risques GenAI restent présents

Avant d'explorer les nouveaux risques introduits par l'Agentic AI, il est important de confirmer que les risques de la GenAI classique ne disparaissent pas — ils persistent et s'aggravent souvent dans le contexte agentique.

Fuites de données : Le risque de fuite de données via des modèles GenAI — quand des données sensibles sont incluses dans des prompts envoyés à des services externes — reste entièrement présent dans les contextes agentiques. Il s'aggrave même : un agent traite souvent des volumes de données plus importants et plus variés qu'un utilisateur humain utilisant un chatbot, augmentant la surface de fuite potentielle. Notre article sur le Shadow AI couvre les risques de fuite associés aux outils IA non contrôlés.

Hallucinations : Les agents IA héritent des capacités hallucinatoires des modèles de langage. Dans un chatbot, une hallucination produit une réponse incorrecte que l'humain peut invalider. Dans un agent, une hallucination peut déclencher une action incorrecte : un agent de traitement de factures qui hallucine un montant peut déclencher un paiement erroné avant que l'erreur ne soit détectée.

Biais : Les biais des modèles de langage se traduisent en biais dans les décisions autonomes des agents. Un agent de screening de CVs qui hérite des biais de son modèle de base prend des décisions discriminatoires à grande échelle et de manière automatisée — un risque légal et éthique sévère.

Désinformation : Un agent GenAI peut générer et diffuser de la désinformation à grande échelle si ses sorties ne sont pas validées avant distribution. Ce risque est amplifié dans les contextes agentiques où un agent peut publier automatiquement du contenu.

Ce qui s'aggrave : les risques amplifiés par l'autonomie

Plusieurs risques existants sont qualitativement aggravés par le passage à l'architecture agentique. L'amplification vient principalement de deux facteurs : l'autonomie (l'agent agit sans validation humaine systématique) et la persistence (l'agent opère en continu, pas seulement lors d'une session utilisateur).

Prompt injection : Dans un chatbot, une prompt injection réussie produit une réponse inappropriée. Dans un agent, elle peut déclencher des actions irréversibles (exfiltration de données, modification de systèmes, envoi d'e-mails). La même vulnérabilité, dans un contexte agentique, a des conséquences exponentiellement plus graves.

Supply chain de modèles : La dépendance à des modèles de langage de base (GPT-4, Claude, Gemini) crée un risque de supply chain : si le modèle de base est compromis (empoisonnement des données d'entraînement, modification non autorisée des poids), tous les agents qui l'utilisent héritent du comportement malveillant. Ce risque est gérable avec des chatbots (une réponse incorrecte est visible et corrigeable) mais beaucoup plus difficile avec des agents (des actions incorrectes peuvent avoir eu lieu avant détection).

Confiance excessive : Le risque d'over-reliance (LLM09 OWASP) — accorder trop de confiance aux décisions de l'IA — est systémiquement aggravé par l'architecture agentique. Quand un agent exécute des actions de manière autonome, les humains tendent à valider moins systématiquement ses décisions, normalisant progressivement des comportements qui devraient être questionnés.

Ce qui est nouveau : les risques propres à l'Agentic AI

Au-delà des risques amplifiés, l'Agentic AI introduit des catégories de risques qui n'existaient pas dans la GenAI classique.

Reconnaissance autonome : Un agent IA peut cartographier une infrastructure, identifier des vulnérabilités et collecter du renseignement de manière autonome — capacités qui nécessitaient auparavant une intervention humaine active. Côté attaquant, cela accélère dramatiquement les phases de reconnaissance. Côté défenseur, cela crée un risque si des agents légitimes mal configurés font de la reconnaissance non intentionnelle.

Exploitation latérale agentique : Les agents peuvent se déplacer latéralement dans un système d'information en utilisant leurs permissions légitimes de manière non intentionnelle. Un agent compromis peut accéder à des ressources qui ne sont pas sa cible directe mais qui sont dans son périmètre de permissions. Ce mouvement latéral « par accident » est une surface d'attaque inédite.

Collusion inter-agents : Dans les architectures multi-agents, des agents peuvent se coordonner d'une manière qui n'était pas prévue par leurs concepteurs — soit par compromission d'un des agents, soit par émergence comportementale. La collusion inter-agents peut aboutir à des actions que ni l'un ni l'autre des agents n'aurait pu réaliser individuellement.

Memory poisoning : Les agents maintenant une mémoire persistante sont vulnérables à un empoisonnement de cette mémoire. Des instructions malveillantes injectées dans la mémoire d'un agent persistent entre les sessions et influencent son comportement futur — une forme de persistance que les défenses classiques ne détectent pas. Pour contrer ce risque, consultez notre guide sur la sécurisation des agents autonomes.

Identités non-humaines non gouvernées : La prolifération d'agents crée une multiplication des identités non-humaines (NHI) qui, sans gouvernance appropriée, deviennent des vecteurs d'attaque. Les NHI ont tendance à accumuler des permissions sans les perdre (les humains ont des offboarding, les agents rarement), créant des « fantômes de permissions » exploitables longtemps après que l'agent a été désactivé.

Comparatif détaillé : profil de risque GenAI vs Agentic AI

Roadmap de migration sécurisée de GenAI vers Agentic AI

La migration d'une organisation depuis des usages GenAI vers l'Agentic AI doit être planifiée en tenant compte de l'évolution du profil de risque. Voici une roadmap en cinq phases.

Phase 1 — Évaluation (semaines 1-4) : Cartographier les usages GenAI actuels, identifier ceux qui évoluent vers de l'Agentic AI (ou sont déjà agentiques sans être clairement identifiés comme tels). Évaluer les risques actuels selon la grille de comparaison ci-dessus. Définir le niveau d'appétit pour le risque agentique.

Phase 2 — Fondations de gouvernance (semaines 5-12) : Formaliser la politique d'usage des agents IA. Établir les processus d'approbation. Désigner des propriétaires pour les agents existants. Créer le registre des agents. Ces fondations doivent précéder tout nouveau déploiement agentique.

Phase 3 — Contrôles techniques de base (semaines 8-20) : Déployer les identités NHI dédiées. Auditer et réduire les permissions. Activer le logging structuré. Déployer les guardrails sur les agents existants. Ces contrôles peuvent être développés en parallèle des fondations de gouvernance.

Phase 4 — Monitoring et détection (semaines 16-30) : Intégrer les alertes agents dans le SIEM. Déployer le behavioral monitoring. Former les équipes SOC à la réponse aux incidents agentiques. Réaliser un premier exercice de red team agentique.

Phase 5 — Maturité avancée (mois 8-18) : Déployer le Governance-as-Code dans les pipelines CI/CD. Explorer les Guardian Agents pour les agents critiques. Intégrer la threat intelligence sur les menaces agentiques. Mesurer et optimiser en continu. Utilisez notre checklist Agentic AI pour évaluer votre progression à chaque phase.

FAQ transition GenAI vers Agentic AI

Si notre organisation n'a que des chatbots GenAI, doit-elle déjà s'inquiéter des risques agentiques ?

Oui, pour deux raisons : (1) les éditeurs de solutions GenAI ajoutent régulièrement des capacités agentiques à leurs produits (Copilot, Gemini, etc.) qui peuvent s'activer sans décision explicite de votre organisation ; (2) les employés ont accès à des outils agentiques en self-service et peuvent créer des Shadow Agents sans information de la DSI.

Combien de temps faut-il pour mettre à jour une politique de sécurité IA GenAI existante pour couvrir l'Agentic AI ?

Une mise à jour complète d'une politique existante prend généralement 4 à 8 semaines, incluant la consultation des parties prenantes (équipes IA, juridique, conformité, métier) et la validation. Une mise à jour d'urgence couvrant les risques les plus critiques peut être réalisée en 2 semaines.

Les fournisseurs d'agents IA (Microsoft, Google, Salesforce) offrent-ils des garanties de sécurité suffisantes ?

Les fournisseurs assurent la sécurité de leur infrastructure et de leurs modèles. Mais la configuration des agents (permissions, outils, données accessibles), le déploiement et la supervision relèvent du client selon le modèle de responsabilité partagée. Les garanties fournisseur ne couvrent pas les mauvaises configurations client.

Sources de référence : OWASP Top 10 for LLM Applications CISA : Secure AI Guidance

Quelle est la différence fondamentale entre GenAI et Agentic AI du point de vue sécurité ?

La transition de la GenAI vers l'Agentic AI représente un changement de paradigme de sécurité aussi important que le passage des applications monolithiques aux microservices. Avec la GenAI (chatbots, assistants de génération de contenu), le risque est principalement lié aux outputs : hallucinations, fuites de données dans le prompt, génération de contenu inapproprié. L'humain reste dans la boucle pour chaque action — il copie-colle un texte, adapte un code, décide d'utiliser ou non la réponse. Le rayon d'explosion d'un incident GenAI est limité à la qualité de l'output.

Avec l'Agentic AI, le risque se déplace des outputs vers les actions : l'agent peut envoyer des emails, modifier des fichiers, appeler des APIs, exécuter du code, créer des enregistrements en base de données — tout cela de façon autonome et séquentielle sur des dizaines d'étapes. Un agent compromis par prompt injection peut enchaîner des actions irréversibles avant qu'un humain ne détecte le problème. Selon OWASP Agentic AI Top 10 (2026), les 3 risques les plus critiques sont : (1) l'escalade de privilèges non autorisée via les tool calls, (2) l'exfiltration de données via des canaux de sortie secondaires (emails, webhooks), (3) les actions irréversibles sans approbation humaine (suppression de données, transactions financières).

Comment évaluer la maturité de votre organisation dans la gestion des risques Agentic AI ?

Un modèle de maturité en 4 niveaux permet d'évaluer où en est votre organisation. Niveau 1 — Naïf : utilisation d'agents sans politique formelle, aucun audit trail, permissions non scoped. Niveau 2 — Conscient : politique d'usage existante mais non appliquée, monitoring basique, inventaire partiel des agents. Niveau 3 — Géré : gouvernance formelle avec inventaire complet, audit trail systématique, IAM adapté aux agents, réponse aux incidents documentée. Niveau 4 — Optimisé : Guardian Agents actifs, Governance-as-Code intégré dans CI/CD, red team IA semestriel, métriques de sécurité en temps réel communiquées au COMEX.

Selon Gartner (2026), 68% des organisations ayant déployé des agents IA en production sont au niveau 1 ou 2. Seules 8% atteignent le niveau 4. La progression de niveau 1 à niveau 3 prend en moyenne 12 à 18 mois avec des ressources dédiées. Les organisations du secteur financier et de la santé progressent plus vite en raison des pressions réglementaires (DORA, AI Act, réglementations sectorielles). Notre audit de sécurité IA permet d'évaluer votre niveau actuel et de définir la feuille de route vers le niveau 3.

Quelles nouvelles classes d'attaques sont spécifiques à l'Agentic AI ?

L'Agentic AI introduit des classes d'attaques inédites que les référentiels de sécurité traditionnels ne couvrent pas encore totalement. La prompt injection indirecte — l'agent lit un document ou une page web piégée qui modifie son comportement — est l'attaque la plus documentée en 2026. Le goal hijacking permet à un attaquant de substituer progressivement l'objectif de l'agent (l'agent commence à vouloir exfiltrer des données au lieu de répondre aux emails). Le tool misuse exploite les outils légitimes de l'agent à des fins non autorisées : utiliser l'outil "envoyer email" pour exfiltrer des données plutôt que pour communiquer. La mémoire poisoning consiste à introduire de fausses informations dans la mémoire à long terme de l'agent pour biaiser ses décisions futures. Ces attaques sont particulièrement dangereuses car elles passent souvent inaperçues dans les journaux classiques — elles nécessitent un monitoring spécifique de la sémantique des actions, pas seulement de leur occurrence.

Architecture de transition GenAI vers Agentic AI : phases et jalons

La transition d'une organisation vers l'IA agentique n'est pas un basculement instantané mais une progression structurée en quatre phases distinctes. La phase GenAI assistée (maturité 1) est le point de départ le plus courant en 2024 : des assistants IA répondent aux questions des opérateurs de sécurité, génèrent des rapports d'analyse, suggèrent des règles de détection — mais aucune action n'est exécutée sans validation humaine explicite. Cette phase est réversible et peu risquée, ce qui explique son adoption large (selon Gartner, 68 % des grandes entreprises européennes étaient à ce niveau en fin 2024).

La phase semi-agentique (maturité 2) introduit des agents à périmètre contraint : l'agent peut exécuter des actions prédéfinies dans un playbook approuvé, mais ne peut pas sortir du script. Une validation humaine reste requise pour les décisions à fort impact. La phase agentique supervisée (maturité 3) donne aux agents une autonomie décisionnelle étendue avec supervision ex-post : les actions sont exécutées automatiquement, et les équipes humaines vérifient les résultats. Des mécanismes de rollback automatique permettent d'annuler les actions si une anomalie est détectée dans les 30 minutes suivant l'exécution. La phase agentique autonome (maturité 4) est réservée aux processus de sécurité les mieux documentés, avec une tolérance au risque explicitement définie : l'agent agit, s'auto-évalue et apprend en continu.

Les jalons de transition recommandés par le SANS Institute pour passer d'une phase à la suivante : 6 mois minimum à chaque niveau de maturité, taux de faux positifs inférieur à 8 % sur les 3 derniers mois, couverture de 80 % des scénarios documentés dans les playbooks, et réalisation d'un red team exercise sur le système agentique validant l'absence de vecteurs d'attaque critiques non couverts.

Gestion des identités dans un écosystème agentique

L'un des défis les plus sous-estimés de l'IA agentique est la gestion des identités machines. Chaque agent est une entité autonome qui agit au nom de l'organisation — il doit donc disposer d'une identité numérique propre, avec des permissions granulaires et un cycle de vie géré. Les erreurs courantes : donner aux agents des credentials humains (compte de service partagé, token API sans expiration), créer des agents sans politique de moindre privilège, et ne pas auditer les permissions réellement utilisées par les agents en production.

Le framework SPIFFE/SPIRE (Secure Production Identity Framework For Everyone) est aujourd'hui la référence pour l'identité des workloads IA. Il attribue à chaque agent un certificat X.509 à durée de vie courte (4 à 24 heures), renouvelé automatiquement, lié à l'identité cryptographique du workload. En cas de compromission, la surface d'exposition est limitée à la durée de vie du certificat. Pour les appels API entre agents (protocols comme MCP ou A2A), l'authentification mutuelle via SPIFFE garantit qu'aucun agent non autorisé ne peut usurper l'identité d'un autre dans le système.

La gestion du cycle de vie des agents impose un registre centralisé : chaque agent doit avoir un propriétaire humain identifié, une date de mise en production, un périmètre de permissions documenté, et un processus de décommissionnement. Selon une étude Saviynt 2024, 43 % des violations de sécurité impliquant des agents IA en production provenaient d'agents orphelins — des agents dont le propriétaire d'origine avait quitté l'organisation et dont les credentials n'avaient jamais été révoqués. La mise en place d'une revue semestrielle automatique des agents actifs est une mesure minimale recommandée par l'ANSSI.

Supervision humaine et points de contrôle : le modèle HITL en contexte agentique

Le modèle HITL (Human-In-The-Loop) a évolué dans le contexte agentique pour donner naissance à des variantes plus adaptées aux volumes de traitement. Le HITL strict — validation humaine de chaque décision — devient opérationnellement impossible dès que le système traite des milliers d'événements par heure. Les organisations avancées utilisent désormais le HOTL (Human-On-The-Loop) : l'agent agit, et l'humain supervise les tableaux de bord d'agrégation, n'intervenant que sur les exceptions signalées automatiquement. Pour les décisions à fort impact irréversible (blocage d'un compte utilisateur de direction, isolation d'un segment réseau critique), le HITL strict reste obligatoire.

La conception des points de contrôle humains doit répondre à quatre critères. Réversibilité : les actions irréversibles (suppression de données, rupture de contrat de service) requièrent toujours une validation humaine. Impact business : les actions touchant des systèmes critiques (ERP, SCADA, systèmes de paiement) nécessitent une double validation. Nouveauté : un scénario que l'agent n'a jamais rencontré (score de confiance < 70 % sur la classification) doit être escaladé. Réglementation : les actions généralement soumises à des obligations légales (traitement de données personnelles, notification d'incident) nécessitent une validation humaine pour établir la responsabilité juridique. L'AI Act européen, en vigueur progressive depuis 2024, impose explicitement des points de contrôle humains pour les systèmes IA à haut risque — catégorie dans laquelle entrent la plupart des agents de cybersécurité automatisés.

• Éviter la "validation rubber stamp" : si les humains approuvent systématiquement les décisions de l'agent sans les examiner réellement, le point de contrôle devient inefficace. Mesurer le taux de rejet humain comme indicateur de qualité du contrôle.
• Charge cognitive : un analyste ne peut efficacement superviser plus de 50 à 80 décisions HITL par heure selon les études ergonomiques de Sandia National Laboratories — dimensionner les équipes en conséquence.
• Documentation des décisions : chaque intervention humaine (approbation ou rejet) doit être journalisée avec horodatage et identifiant de l'analyste pour la traçabilité réglementaire.