Pourquoi le fossé d’identité de l’IA fantôme représente le véritable risque pour les entreprises en 2026
Près de la moitié des activités d’IA en entreprise se déroulent aujourd’hui via des identités que votre équipe de cybersécurité ne peut ni voir, ni auditer, ni justifier auprès d’un régulateur en cas de contrôle. C’est la conclusion centrale du nouveau rapport State of the Internet d’Akamai sur les risques liés à l’usage de l’IA en entreprise, qui doit amener chaque RSSI et responsable conformité à repenser la gouvernance de l’IA à l’horizon 2026.
Depuis deux ans, la plupart des programmes de sécurité liés à l’IA en entreprise se sont structurés autour d’une question unique : qui est autorisé à accéder à quel outil d’IA ? Cette question a donné naissance à des listes d’autorisations, à l’authentification unique et à des workflows d’approbation d’applications. Mais selon le rapport d’Akamai, fondé sur la télémétrie de sa plateforme LayerX (rachetée par Akamai), cette question n’est plus la bonne. Le risque majeur lié à l’IA en 2026 ne porte plus sur l’accès, mais sur les collaborateurs qui partagent des données sensibles avec l’IA, et sur l’identité via laquelle ces données quittent l’entreprise.
Cette distinction est cruciale, car l’IA ne fait pas circuler les données comme les outils traditionnels de prévention des pertes de données. Les canaux d’e-mail, de transfert ou de dépôt de fichiers sont bien définis et contrôlables. Les interactions avec l’IA ne le sont pas. Les informations sensibles se fragmentent entre les prompts, le contexte conversationnel, le code collé, les captures d’écran et les réponses générées ; chaque fragment semble anodin, mais l’ensemble représente une exposition majeure. La plateforme d’échange sécurisé de données Kiteworks existe justement parce que la gouvernance doit suivre la donnée, et non l’application qu’elle traverse. Les données d’Akamai fournissent aux RSSI et responsables conformité la preuve la plus claire à ce jour de l’urgence de ce changement.
Résumé des points clés
1. La question du risque a changé.
Le rapport d’Akamai affirme que le principal risque lié à l’IA en entreprise ne concerne plus les collaborateurs autorisés à accéder aux outils d’IA, mais ceux qui partagent des données sensibles avec l’IA et via quelle identité. On passe ainsi d’une problématique de contrôle d’accès à une problématique de gouvernance des données.
2. Près de la moitié de l’activité IA en entreprise échappe à la gestion des identités.
Les données LayerX d’Akamai révèlent que 47,11 % des conversations IA en entreprise ont lieu via des comptes personnels, et non via des identités gérées par l’entreprise. Autrement dit, près de la moitié de l’activité IA échappe à la gouvernance classique des identités.
3. Une identité professionnelle ne garantit pas un contrôle par l’entreprise.
Même lorsqu’un collaborateur se connecte avec une adresse e-mail professionnelle, 14,4 % de ces conversations utilisent en réalité des abonnements freemium personnels. Les données peuvent donc alimenter les pipelines publics d’entraînement des fournisseurs, même si l’usage semble autorisé.
4. Une minorité d’utilisateurs intensifs concentre la majorité de l’exposition.
L’usage et la profondeur des conversations sont très concentrés : les 5 % d’utilisateurs les plus actifs génèrent au moins 144 conversations, et les 5 % de conversations les plus longues atteignent au moins 18 prompts. Le risque n’est donc pas réparti uniformément, mais concentré sur une minorité.
5. Les agents IA deviennent une nouvelle classe d’identités en entreprise, qui nécessite toujours une responsabilité humaine.
Le rapport d’Akamai invite les RSSI à inventorier les agents, leurs accès et leurs comportements, comme ils le font déjà pour les identités humaines. Kiteworks propose son Control Plane pour offrir aux équipes sécurité et conformité ce niveau de gouvernance et de preuve, aussi bien pour les accès humains que pour les agents IA.
La question de l’accès n’est plus pertinente pour le risque IA en entreprise
Le rapport d’Akamai commence par un cadrage à reprendre presque mot pour mot : en 2026, l’adoption de l’IA est un impératif structurel, pas une expérimentation. Cette phrase explique pourquoi de nombreux programmes de gouvernance de l’IA conçus en 2024 et 2025 sont déjà dépassés. Ces programmes ont traité l’IA comme une nouvelle catégorie SaaS, en identifiant l’outil, en l’approuvant ou en le bloquant, puis en passant à autre chose. Or, l’IA ne se comporte pas comme une application statique : elle consomme, génère, stocke et exploite en continu les données de l’entreprise. Le moment de « l’accès » n’apprend donc presque rien à l’équipe sécurité sur le devenir des informations sensibles.
Un seul dossier client sensible peut passer dans un prompt, être reformulé dans une réponse, collé dans un second outil pour la mise en forme, puis capturé en capture d’écran pour une présentation, sans jamais déclencher une règle DLP classique, car aucune étape ne ressemble à une exfiltration de données. Le rapport d’Akamai est clair : le plus grand risque de sécurité lié à l’IA n’est plus « les collaborateurs qui accèdent à l’IA », mais « ceux qui partagent des données sensibles avec l’IA ». Pour un responsable conformité, ce changement de perspective a une conséquence directe : les régulateurs n’auditent pas les listes d’accès aux applications, mais la gestion des données. Les programmes centrés sur la gouvernance des données IA plutôt que sur le filtrage applicatif sont ceux qui pourront répondre à la question que posera réellement un régulateur.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Analyse des données LayerX d’Akamai sur l’usage de l’IA en entreprise
Le rapport d’Akamai s’appuie sur LayerX, l’activité de sécurité du navigateur qu’il a acquise. Cette édition (publiée en août 2026) repose entièrement sur la télémétrie comportementale, c’est-à-dire sur l’usage réel des outils d’IA par les collaborateurs, et non sur des enquêtes déclaratives.
Le schéma d’utilisation mérite d’être analysé avant d’aborder les chiffres sur les identités. Environ 18,24 % des collaborateurs utilisent l’IA chaque semaine, 30,47 % chaque mois, et 47,67 % au moins une fois par trimestre. Près de la moitié des utilisateurs d’IA en entreprise l’utilisent donc de façon occasionnelle. L’utilisateur moyen participe à 36 conversations IA, mais la moitié inférieure des utilisateurs en génère 12 ou moins, tandis que les 5 % les plus actifs en génèrent au moins 144. La profondeur des conversations suit la même logique : la conversation moyenne contient 5,09 prompts, la médiane seulement 2, mais les 5 % les plus longues dépassent 18 prompts, preuve de sessions itératives et soutenues, et non de simples recherches ponctuelles.
La multiplication des applications accentue ce phénomène de concentration. Les quatre principales applications IA d’une organisation sont chacune utilisées par plus de 20 % des collaborateurs, mais la part d’utilisation tombe sous les 5 % dès la dixième application la plus utilisée, et frôle zéro à la trentième. Cette longue traîne d’outils IA de niche, régionaux ou personnels, incluant des plateformes grand public comme DeepSeek (utilisée à 99,83 % via des comptes personnels selon Akamai, alors même que les pouvoirs publics s’inquiètent du devenir de ces données), constitue le terrain où les programmes de gouvernance ont le moins de visibilité et où l’exposition par utilisateur est la plus forte.
Près de la moitié de l’activité IA en entreprise passe par des identités non gérées
La statistique centrale du rapport est limpide : 47,11 % des conversations IA en entreprise se font via des identités personnelles, contre 52,89 % via des comptes gérés par l’entreprise. Près de la moitié de ce que font les collaborateurs avec l’IA en entreprise passe donc par une identité que l’organisation ne peut pas désactiver en cas de départ, ni auditer.
La répartition varie selon les plateformes. ChatGPT fonctionne à 61,36 % via des comptes personnels, Copilot à 63,92 %, Claude à 61,09 %, tandis que les offres conçues pour l’entreprise inversent la tendance : Gemini Enterprise est utilisé à 98,15 % via des comptes professionnels, Copilot for Microsoft 365 à 90,55 %. Ce fossé n’est pas inhérent à l’adoption de l’IA, mais révèle un défaut de gouvernance propre aux outils grand public opérant sans gestion dans l’entreprise.
Le problème se cache aussi dans des comptes en apparence conformes. Parmi les conversations IA initiées depuis une adresse e-mail professionnelle, 14,4 % sont en réalité liées à des abonnements freemium personnels, et non à des licences gérées par l’entreprise. Les données transmises peuvent donc alimenter les pipelines publics d’entraînement des fournisseurs, même si, sur un rapport d’accès basé sur le domaine, l’usage semble autorisé. Un RSSI qui se base uniquement sur le domaine e-mail pour rendre compte de l’usage de l’IA surestime très probablement la couverture réelle de la gouvernance. C’est précisément ce fossé que Kiteworks Compliant AI vise à combler, en gouvernant la donnée elle-même au moment où elle quitte l’environnement autorisé, plutôt qu’en tentant d’identifier chaque compte personnel après coup.
Les utilisateurs intensifs d’IA concentrent le risque et la surface d’attaque
Akamai consacre un focus aux « power users » de l’IA : une minorité qui mène des sessions plus longues et contextuelles, partage plus de données sensibles et délègue de plus en plus de tâches à des agents autonomes. Cette dépendance à la production de l’IA croise l’étude de cas sur le « vibe hacking » du rapport. En 2026, les chercheurs LayerX ont démontré qu’un assistant IA de codage pouvait être manipulé par la modification subtile d’un fichier markdown local, utilisé pour définir le contexte du modèle, amenant l’assistant à réaliser des actions non autorisées ou à générer du code non sécurisé tout en paraissant fonctionner normalement.
La recommandation d’Akamai est directe : identifier les utilisateurs intensifs, mesurer l’usage réel de l’IA (et pas seulement les applications ouvertes), et surveiller prompts, dépôts et réponses impliquant des données sensibles. Mais cela n’est possible que si l’organisation peut observer le contenu des interactions, et pas seulement enregistrer l’ouverture d’une application.
CursorJacking et CometJacking : les attaquants ciblent l’agent, pas l’utilisateur
Akamai documente deux incidents illustrant comment les outils IA deviennent eux-mêmes une surface d’attaque. Dans CursorJacking, une extension de navigateur malveillante, déguisée en outil de productivité, accède au stockage local de l’assistant IA Cursor, extrait des clés API et des jetons de session, puis les exfiltre discrètement. L’attaquant peut alors se faire passer pour le développeur, abuser des services connectés et compromettre les dépôts associés. Dans CometJacking, analysé sur le navigateur Comet AI de Perplexity, un attaquant insère des instructions malveillantes dans une page web : il suffit de la visiter via un lien pour manipuler l’agent IA du navigateur par injection indirecte de prompt, exposant e-mails, identifiants et fichiers locaux sans téléchargement nécessaire.
Dans les deux cas, l’attaque exploite la confiance déjà accordée à l’outil IA, et contourne les contrôles surveillant le comportement humain, car l’action est réalisée par un logiciel autorisé une fois par l’utilisateur, puis oublié. Une gouvernance centrée uniquement sur les clics humains passera à côté de ces menaces.
L’incident CISA Data Spill montre que la bonne intention n’est pas un contrôle
L’incident le plus instructif du rapport d’Akamai n’est pas un piratage. Début 2026, plusieurs médias ont révélé qu’un fonctionnaire américain avait accidentellement divulgué des données internes et sensibles de la Cybersecurity and Infrastructure Security Agency via un outil IA public. Akamai est explicite : il ne s’agit pas d’une compromission externe ni d’une cyberattaque, mais d’une erreur d’optimisation commise par un utilisateur expérimenté dans le cadre d’une analyse quotidienne.
Ce constat doit alerter tout responsable sécurité dont la gouvernance IA repose sur la détection d’initiés malveillants, car ici il n’y a ni malveillance, ni défaut d’accès. C’est une erreur de gestion des données, qu’aucune liste blanche ou processus d’approbation d’application n’aurait pu détecter, puisque l’outil était autorisé. Seuls des contrôles inspectant en temps réel les données circulant dans une interaction autorisée peuvent détecter ce type d’incident : c’est l’écart entre le contrôle d’accès et une véritable approche zero trust de la gouvernance des données IA.
Les extensions de navigateur IA : des logiciels privilégiés sans gouvernance
L’adoption des extensions IA pour navigateur atteint son pic dans les entreprises de taille moyenne : 17,70 % pour les sociétés de 1 000 à 2 500 employés, contre 9,53 % dans les grandes entreprises. Mais c’est le profil d’autorisations qui concentre le risque : près de 75 % des extensions IA demandent des autorisations élevées ou critiques, elles sont presque trois fois plus susceptibles de demander l’accès aux cookies que la moyenne (18,19 % contre 6,67 %), et 41,91 % demandent l’accès au scripting. De plus, 16,31 % comportent des CVE connus, soit un taux 1,5 fois supérieur à la moyenne des extensions. CursorJacking en est la conséquence concrète. Akamai recommande de traiter ces extensions comme des logiciels privilégiés, avec un inventaire mis à jour en continu, et non comme une approbation ponctuelle. Cela requiert une capacité de gouvernance que la plupart des organisations ont conçue avant l’essor de l’IA générative.
Les agents IA deviennent une nouvelle classe d’identités en entreprise
Le cinquième risque de la liste Akamai concerne les agents IA opérant hors des garde-fous existants, et c’est celui que le rapport juge le moins résolu. Akamai prend soin de ne pas présenter les agents comme agissant indépendamment des humains ou des organisations qui les déploient. Un agent agit sous autorité déléguée, avec des accès accordés par un humain ou une règle, et chaque action est en principe traçable jusqu’à cette délégation. Le défaut de gouvernance vient du fait que la plupart des organisations n’ont pas encore étendu aux agents les contrôles d’identité, de surveillance et d’accès déjà appliqués aux utilisateurs humains.
C’est précisément ce qu’apporte un Control Plane unifié. Le Control Plane Kiteworks gouverne l’accès, l’utilisation et l’échange de contenu sensible par les utilisateurs humains comme par les agents IA, sous une même couche de règles et d’audit. Ainsi, lorsqu’un agent récupère un document réglementé, il est soumis à la même évaluation de politique ABAC et au même journal d’audit qu’un humain effectuant la même opération. Une intégration Secure MCP Server qui connecte un agent au contenu de l’entreprise sans passer par un accès gouverné et journalisé réintroduit le même écart d’identité que celui dénoncé dans le rapport, mais cette fois avec un agent à la place d’un compte ChatGPT personnel non géré.
Les cinq piliers d’Akamai : comment Kiteworks comble le manque de preuves
Akamai conclut son rapport par un cadre en cinq piliers : se concentrer sur les utilisateurs intensifs, éliminer le shadow AI via la fédération d’identités, protéger les données au niveau de l’interaction IA avec un DLP contextuel plutôt qu’un simple filtrage de motifs, sécuriser les extensions comme des logiciels privilégiés, et préparer l’arrivée des agents autonomes en les gouvernant comme une classe d’identités distincte. Cette liste de contrôle est pertinente et écrite du point de vue des opérations de sécurité, axée sur la visibilité et la détection. Mais ce n’est pas, à elle seule, la perspective d’un Chief Compliance Officer confronté à un délai réglementaire. Savoir qu’une interaction a eu lieu et qu’elle était risquée relève de la détection. Être capable, dans les délais imposés, de fournir une preuve défendable de quelles données ont été impliquées et sous quelle autorité, relève de la preuve, et un programme fondé uniquement sur la détection doit malgré tout s’appuyer sur une couche de preuve.
Kiteworks Compliant AI applique les règles au moment où le contenu sensible transite vers ou depuis une interaction IA, de sorte que la gouvernance ne dépend pas de l’identification préalable de chaque application utilisée par un collaborateur ou un agent. Le Control Plane Kiteworks étend cette même couche de règles et d’audit à la messagerie électronique, au partage sécurisé de fichiers, au transfert sécurisé de fichiers, aux formulaires web sécurisés et aux interactions IA. Lorsqu’un examinateur demande quelles données une interaction IA a traitées, la réponse doit provenir d’un journal d’audit gouverné, et non d’une reconstitution approximative. Un CISO Dashboard qui remonte cette activité pour les accès humains comme pour les agents rend les recommandations d’Akamai réellement applicables.
Pour en savoir plus sur la façon de combler le fossé identitaire du shadow AI et de gouverner l’accès des agents IA aux données sensibles sous un Control Plane prêt à fournir des preuves, réservez une démo personnalisée dès maintenant.
Questions fréquentes
Le risque d’accès consiste à vérifier si un collaborateur est autorisé à ouvrir un outil IA donné, ce que contrôlent les listes d’autorisations, les exigences SSO et les workflows d’approbation d’applications. Le risque d’usage s’intéresse à la donnée qui a circulé lors de cette interaction et à sa destination. Les contrôles d’accès ne peuvent pas répondre à cette question, car les données d’Akamai montrent que les activités les plus risquées (comptes personnels et abonnements freemium) passent souvent tous les contrôles d’accès tout en sortant du périmètre de gouvernance de l’entreprise. Les programmes structurés autour de la gouvernance des données IA comblent ce fossé, car ils gouvernent la donnée elle-même, indépendamment de l’identité ou de l’application.
Elle signifie qu’un examinateur, un auditeur ou un avocat qui cherche à savoir ce qu’il est advenu de données sensibles dans une conversation IA a une chance sur deux de tomber sur une identité avec laquelle l’organisation n’a aucun lien formel et pour laquelle elle ne peut produire aucun justificatif. Un programme de conformité doit s’appuyer sur une gouvernance des données et une capacité d’audit qui opèrent au moment où le contenu sensible quitte un environnement gouverné, et non seulement sur le suivi d’activités de comptes déjà connus.
Le rapport d’Akamai et la vision de Kiteworks considèrent les agents IA comme une nouvelle classe d’identités, opérant toujours sous l’autorité humaine et organisationnelle déléguée, et non comme des acteurs autonomes sans responsabilité. Les agents disposent généralement d’un accès privilégié au SaaS, à la messagerie et aux fichiers de l’entreprise, comme l’illustre l’étude de cas CometJacking. Ils nécessitent donc la même application de règles ABAC et le même audit que les comptes humains, étendus à cette seconde population.
Non. Le rapport d’Akamai précise que l’objectif de la sécurité IA est de permettre un usage sécurisé, pas de restreindre la technologie. Kiteworks Compliant AI s’inscrit dans cette logique, en appliquant les règles au moment où le contenu sensible transite vers ou depuis une interaction IA. Les collaborateurs peuvent ainsi continuer à utiliser les outils IA approuvés de façon productive, tout en maintenant la gouvernance et l’auditabilité des données sensibles.
Un auditeur attend généralement un justificatif indiquant quelles données l’agent a consultées, sous quelle autorité, à quel moment, et quels contrôles, chiffrement, restrictions d’accès et journalisation étaient appliqués au moment de l’accès, le tout dans les délais impartis. Un Control Plane Kiteworks gouverné, avec un journal d’audit cohérent pour les activités humaines et agents, permet à une équipe conformité de constituer ce dossier de preuve à la demande.
Ressources complémentaires
- Article de blog
Stratégies Zero Trust pour une protection abordable de la confidentialité IA - Article de blog
Comment 77 % des organisations échouent à sécuriser les données IA - eBook
Le fossé de la gouvernance IA : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025 - Article de blog
Il n’existe pas de « –dangerously-skip-permissions » pour vos données - Article de blog
Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves de son efficacité.