Incidents liés aux agents IA : des risques non maîtrisés exposent 65 % des organisations

La Cloud Security Alliance et Token Security ont publié le 21 avril 2026 une étude intitulée Autonomous but Not Controlled: AI Agent Incidents Now Common in Enterprises. Le constat est sans appel : 65 % des organisations ont subi au moins un incident de cybersécurité au cours de l’année écoulée, causé par des agents IA opérant sur leurs réseaux d’entreprise.

Points clés à retenir

1. Les incidents d’agents IA sont désormais la norme, pas l’exception. De nouvelles recherches montrent que 65 % des organisations ont connu au moins un incident de cybersécurité lié à un agent IA cette année. Cela rebat totalement les cartes du débat sur les risques IA : on ne parle plus d’hypothèses, mais de faits avérés.
2. L’exposition de données est la principale cause d’incident. Parmi les incidents impliquant des agents IA, 61 % concernent une exposition de données sensibles, 43 % une perturbation opérationnelle et 41 % des actions non intentionnelles dans les processus métiers. L’agent ne « dysfonctionne » pas : il agit dans le cadre des autorisations qui lui ont été accordées.
3. La plupart des organisations ne peuvent pas stopper un agent défaillant. Selon Kiteworks, 63 % des organisations ne peuvent pas imposer de limitations d’usage aux agents IA et 60 % ne peuvent pas mettre fin à l’activité d’un agent défaillant. Le confinement est la fonction qui manque.
4. Seules 19 % des organisations considèrent les agents IA comme des collaborateurs internes. Le manque de classification est un problème de gouvernance. Si un agent n’est pas identifié comme un risque interne, il n’est pas intégré au programme de gestion des risques internes.
5. La solution est architecturale, pas administrative. La gouvernance au niveau des données — accès minimal, usage limité, accès temporaire appliqué au point d’accès des données — est la seule réponse à grande échelle à un problème de contrôle désormais omniprésent dans les réseaux d’entreprise.

Ce n’est pas une prévision. C’est un constat. Les incidents ont déjà eu lieu.

L’analyse détaillée compte autant que le constat global. Parmi les organisations ayant signalé des incidents liés aux agents IA, 61 % concernent une exposition de données, 43 % une perturbation opérationnelle, 41 % des actions non intentionnelles dans les processus métiers, 35 % des pertes financières et 31 % des retards de service.

Lisez bien ceci : l’issue la plus fréquente lorsqu’un agent IA non gouverné circule librement sur un réseau d’entreprise, c’est la fuite de données. L’agent ne « casse » pas : il divulgue. Il fait ce pour quoi il a été conçu. Le problème, c’est que sa mission n’a jamais été encadrée par une politique de gouvernance des données.

Pourquoi ce n’est pas un nouveau problème — juste un problème plus rapide

Les entreprises ont déjà connu ce scénario. Quand l’adoption du SaaS a explosé il y a dix ans, le shadow IT est devenu le principal canal d’exfiltration de données. Quand le télétravail s’est généralisé, les endpoints non gérés sont devenus la principale source de vol d’identifiants. Le schéma est toujours le même : l’adoption technologique va plus vite que la gouvernance, et c’est la multiplication des fuites qui impose un réajustement.

Les agents IA accélèrent considérablement ce cycle. Selon le DTEX 2026 Insider Threat Report, 92 % des organisations estiment que l’IA générative a fondamentalement transformé la façon dont les collaborateurs accèdent et partagent l’information — mais seules 13 % ont intégré l’IA dans leur stratégie métier. DTEX identifie le shadow AI comme principal facteur d’incidents internes par négligence, devant le partage de fichiers non surveillé et l’utilisation de webmails personnels.

Ce même rapport indique que 73 % des organisations craignent que l’utilisation non autorisée de l’IA ne crée des voies de fuite invisibles, et seules 19 % classent les agents IA comme des collaborateurs internes. La catégorie de gouvernance existe. Les agents n’y figurent pas.

La faille apparaît dans les données de violation. Selon le IBM Cost of a Data Breach Report 2025, 97 % des organisations ayant déclaré une fuite liée à l’IA n’avaient pas de contrôle d’accès IA adapté. Le shadow AI ajoute environ 670 000 $ au coût moyen d’une fuite. Aux États-Unis, le coût moyen d’une violation dépasse désormais 10 millions de dollars, principalement à cause des sanctions réglementaires.

C’est le prix de l’absence de classification, en dollars.

À quoi ressemble concrètement un « agent IA non contrôlé »

Voyons comment cela se passe dans une entreprise type. Une équipe d’ingénierie déploie un assistant IA pour le code. Il a besoin d’un accès en lecture au dépôt. Cet accès fonctionne, donc il reste. Un membre d’une autre équipe donne à ce même agent un accès en lecture au système de tickets, car il aide à traiter les incidents. Ensuite, il obtient l’accès aux documents de conception — pour le contexte. Puis à la boîte mail du support client — pour rédiger des réponses.

Six mois plus tard, l’agent a accumulé des accès en lecture au code source, aux tickets clients, aux roadmaps, et aux échanges avec les clients. Aucun accès n’était déraisonnable pris isolément. Aucune équipe n’avait la vision d’ensemble. Et personne n’a revu ce que l’agent pouvait toucher dans sa globalité.

Maintenant, l’agent est compromis — via une injection de prompt, une attaque sur la supply chain de son fournisseur, ou une fuite d’identifiants. L’attaquant hérite de tout ce que l’agent pouvait consulter. La fuite Vercel révélée le 21 avril 2026 illustre parfaitement ce schéma : les attaquants ont pivoté d’un outil IA tiers compromis (Context.ai) vers les systèmes internes de Vercel grâce aux accès octroyés par un collaborateur.

L’attaquant n’a pas eu besoin de pirater Vercel. Il a compromis l’outil IA auquel l’employé faisait confiance.

Les trois failles de gouvernance derrière le chiffre de 65 %

Le Kiteworks Data Security and Compliance Risk: 2026 Forecast Report a identifié trois failles de contrôle qui expliquent le taux d’incidents de la CSA. Ce ne sont pas des manques abstraits, mais les raisons concrètes pour lesquelles les agents IA provoquent des incidents d’exposition de données.

L’encadrement de l’usage fait défaut. 63 % des organisations ne peuvent pas imposer de limitations d’usage aux agents IA. Un agent ayant accès à un système de service client pour rédiger des réponses n’a aucun contrôle technique l’empêchant de lire les données financières clients dans ce même système. L’usage, dans la plupart des environnements, relève de l’intention — documentée dans la politique, mais non appliquée au niveau des données.

Le confinement fait défaut. 60 % des organisations ne peuvent pas mettre fin à l’activité d’un agent IA défaillant. Surveiller un agent qui exfiltre activement des données ne sert à rien s’il n’existe aucun moyen de l’arrêter. Le rapport prévisionnel 2026 considère cette faille comme la plus critique : les organisations ont investi dans la surveillance des agents, mais pas dans leur arrêt.

Les preuves font défaut. 67 % disposent en théorie de journaux d’audit — mais selon le rapport 2026, seuls quelques-uns offrent des logs exploitables couvrant tous les canaux qu’un agent IA peut toucher (e-mail, partage de fichiers, API, serveurs MCP, bases de données). Quand le régulateur demande « que fait cet agent avec des données réglementées ? », des logs fragmentés ne suffisent pas.

Chacune de ces failles explique pourquoi un programme de gouvernance existant sur le papier échoue en production.

Pourquoi la « sécurité du modèle » ne suffit pas

L’industrie de la sécurité IA a beaucoup investi dans les garde-fous au niveau du modèle — défenses contre l’injection de prompt, filtrage des sorties, tests d’alignement, techniques d’IA constitutionnelle. C’est utile. Mais cela ne résout pas le problème décrit par les données de la CSA.

Voici pourquoi. Les garde-fous au niveau du modèle cherchent à empêcher l’IA de faire un usage malveillant des données auxquelles elle a accès. C’est utile, mais cela suppose que le modèle d’accès est correct. Les 65 % d’organisations ayant connu des incidents d’agents IA ne souffrent pas principalement de modèles mal alignés produisant des résultats dangereux. Elles souffrent de modèles qui fonctionnent correctement, mais qui accèdent à des données qu’ils n’auraient jamais dû recevoir.

Selon le Thales Data Threat Report 2026, l’exposition de données sensibles est le principal type d’attaque basée sur l’IA/LLM en hausse — et seules 33 % des organisations savent précisément où se trouvent leurs données sensibles. Impossible de gouverner l’accès IA à des données que l’on ne sait pas localiser.

La sécurité à l’exécution et la sécurité des données sont deux disciplines complémentaires, pas interchangeables. La sécurité à l’exécution rend l’agent plus sûr en tant que système. La sécurité des données protège les données contre l’agent. L’IA d’entreprise a besoin des deux. La plupart des entreprises n’ont investi que dans l’une, négligeant l’autre — d’où le taux d’incident de 65 %.

L’approche Kiteworks : gouvernance au niveau des données pour les agents IA

Kiteworks comble la faille de gouvernance au niveau des données, là où la recherche de la CSA identifie les défaillances réelles. L’approche est architecturale, pas un simple ajout.

Accès limité par usage. Chaque agent IA se connecte aux données réglementées via la passerelle IA Data Gateway de Kiteworks, qui applique un contrôle d’accès basé sur les attributs (ABAC) au moment de la récupération des données. L’identité de l’agent, la classification des données, l’usage prévu et le contexte de la demande sont tous évalués avant que les données ne circulent. Un agent ne peut pas accéder accidentellement à des données hors de son périmètre, car l’usage est codé dans le moteur de règles — pas dans le prompt.

Intégration MCP encadrée. Le serveur Secure MCP de Kiteworks donne aux agents IA un accès contrôlé aux données d’entreprise via le Model Context Protocol tout en respectant le principe du moindre privilège. L’agent reçoit exactement le contexte nécessaire à sa tâche — rien de plus — et chaque récupération est tracée.

Confinement et interrupteurs d’arrêt. L’application des règles se fait au niveau de la plateforme, pas de l’agent. Si le comportement d’un agent s’écarte de son usage autorisé, l’accès peut être révoqué instantanément sur tous les canaux de données concernés. Le confinement ne nécessite pas de traquer l’agent dans différents systèmes.

Journaux d’audit exploitables. Chaque interaction d’un agent IA avec des données réglementées génère des logs d’audit infalsifiables et unifiés couvrant e-mail, partage de fichiers, SFTP, MFT, API, formulaires web et MCP. Ces logs facilitent l’intégration SIEM, les audits réglementaires et la conservation à des fins juridiques. Quand un régulateur demande ce que l’agent a fait, la réponse est accessible en une requête — pas un puzzle à reconstituer sur cinq systèmes.

C’est le modèle architectural dont le secteur a besoin pour combler le fossé entre adoption de l’IA et gouvernance des données IA. C’est aussi le seul modèle qui passe à l’échelle pour des milliers d’agents dans des dizaines de processus métiers — ce vers quoi tendent la plupart des entreprises dans les vingt-quatre prochains mois.

Ce que les organisations doivent faire dès maintenant

Première étape : recenser tous les agents IA ayant accès à des données réglementées. Cela inclut les assistants de codage, copilotes service client, agents d’analytique, processeurs de documents et tout outil IA tiers ayant reçu un accès OAuth ou API aux systèmes internes. Faites le lien avec le constat de la CSA : la plupart des organisations n’ont aucune stratégie de retrait — considérez chaque agent recensé comme une obligation de gouvernance.

Deuxième étape : classer les agents IA comme des collaborateurs internes non humains dans le programme de gestion des risques internes. Le rapport DTEX 2026 montre que seules 19 % des organisations le font aujourd’hui. La solution passe par une mise à jour de la politique et un changement technique : appliquez les mêmes revues d’accès, seuils de surveillance et procédures de révocation que pour les utilisateurs privilégiés humains, adaptés à l’échelle et à la rapidité des agents.

Troisième étape : imposer les limitations d’usage au niveau des données, pas au niveau de l’agent. L’usage d’un agent doit être codé dans une règle évaluée à chaque demande d’accès. Faire confiance à l’agent pour « rester dans les clous » n’est pas un contrôle. Le rapport prévisionnel 2026 montre que 63 % ne savent pas le faire aujourd’hui — combler cette faille est l’investissement de contrôle le plus efficace disponible.

Quatrième étape : déployer la capacité de confinement avant de généraliser les agents. S’il n’existe aucun moyen de mettre fin à l’activité d’un agent IA qui exfiltre activement des données, le programme de gouvernance est incomplet. Les interrupteurs d’arrêt, l’isolation réseau et la révocation des identifiants doivent être en place et testés — pas juste envisagés.

Cinquième étape : construire des journaux d’audit exploitables et unifiés sur tous les canaux accessibles à l’agent. Régulateurs, auditeurs et avocats demanderont ce que l’agent a fait et sous quelle autorisation. Selon le CrowdStrike 2026 Global Threat Report, les acteurs étatiques exploitent de plus en plus des identités légitimes pour accéder discrètement aux données — la qualité des logs fait la différence entre une détection en quelques jours ou en plusieurs mois.

Sixième étape : aligner la gouvernance des agents IA sur les cadres réglementaires déjà en vigueur. HIPAA, CMMC, PCI DSS, SEC et SOX imposent tous des exigences sur le contrôle d’accès aux données, les journaux d’audit et l’accès minimal nécessaire. Aucun n’exempte les agents IA. Le chemin le plus rapide vers la conformité des agents IA, c’est de reconnaître que le cadre existe déjà — ce sont les contrôles qui manquent.

La recherche de la CSA n’est pas un avertissement sur ce qui pourrait arriver. C’est un rapport sur ce qui s’est déjà produit. Les organisations qui feront la différence en 2026 et 2027 sont celles qui répondront aux données par un changement d’architecture, pas par une simple mise à jour de politique.

La réponse réglementaire 2026 arrive plus vite que prévu

Les régulateurs lisent les mêmes études que les RSSI. Selon le rapport prévisionnel 2026, les dispositions à haut risque de l’AI Act européen seront pleinement applicables en août 2026 — avec des amendes pouvant aller jusqu’à 35 millions d’euros ou 7 % du chiffre d’affaires mondial en cas de non-conformité. L’AI Act impose aux systèmes IA à haut risque de tenir une documentation détaillée, de passer des évaluations de conformité et d’être enregistrés dans une base de données publique européenne.

Côté européen, la voie est tracée. Aux États-Unis, la réglementation évolue via des lois d’État, des actions de la FTC et des directives sectorielles. Le Colorado AI Act, la législation du Texas et les amendements en Californie, Kentucky et Delaware élargissent tous la définition des données sensibles pour inclure les catégories inférées par l’IA. L’étude Cisco Data Privacy Benchmark 2025 montre que la maturité des programmes de protection de la vie privée dépend de plus en plus de la posture de gouvernance des données IA — et non d’une discipline séparée.

Le schéma est le même partout : les régulateurs convergent vers l’idée que les systèmes IA traitant des données personnelles ou réglementées doivent démontrer un accès gouverné, des comportements auditables et des modes de défaillance maîtrisables. Les organisations capables de produire une documentation de qualité passeront. Les autres feront l’objet de sanctions.

La recherche de la CSA est déterminante car elle établit la prévisibilité. Quand un régulateur demandera si une organisation « savait ou aurait dû savoir » que des agents IA non gouvernés ont causé des incidents d’exposition de données, la réponse après avril 2026 est documentée : deux tiers des entreprises avaient déjà connu de tels incidents à la date de publication. « Nous ne savions pas » n’est plus une défense recevable. Pas plus que « c’est la pratique standard du secteur » — car la pratique standard, selon les données, cause des incidents.