Ce n’est pas l’IA qui pose problème, c’est l’accès que vous lui accordez.

Un chiffre du rapport 2026 de Teleport sur l’état de l’IA dans la sécurité des infrastructures d’entreprise devrait interpeller chaque RSSI : 4,5 fois.

Les organisations dotées de systèmes d’IA surdotés en droits d’accès sont 4,5 fois plus susceptibles de subir des incidents de sécurité que celles appliquant le principe du moindre privilège. Ce n’est pas deux fois plus. Ce n’est pas une exposition modérée. C’est quatre fois et demie. Le rapport identifie ce facteur comme le plus prédictif d’incidents liés à l’IA — devant le secteur d’activité, le niveau de maturité ou la confiance affichée dans la sécurité de l’IA.

Ev Kontsevoy, CEO de Teleport, résume clairement la situation : les données sont sans appel. Ce n’est pas l’IA qui est dangereuse. C’est l’accès que nous lui donnons.

Cette affirmation rebat complètement les cartes du débat sur la sécurité de l’IA. Le risque ne réside pas dans la dangerosité intrinsèque des systèmes d’IA. Le risque, c’est que les organisations déploient l’IA avec des droits d’accès qu’aucun humain occupant un poste équivalent n’aurait — et découvrent, au fil des incidents, que des accès surdimensionnés à la vitesse machine engendrent des conséquences à l’échelle machine.

5 enseignements clés

1. Une IA surdotée en droits d’accès est le facteur le plus prédictif d’incidents de sécurité. Les organisations où les systèmes d’IA disposent de plus de droits d’accès que nécessaire enregistrent un taux d’incident de 76 %. Celles qui appliquent le principe du moindre privilège n’en déclarent que 17 %. Soit un écart de 4,5 fois — et le rapport Teleport le cite comme le facteur le plus prédictif d’incidents liés à l’IA, devant le secteur, le niveau de maturité ou la confiance affichée. L’IA n’est pas le problème. C’est l’accès que les organisations lui accordent qui l’est.
2. 70 % des systèmes d’IA disposent de plus de droits d’accès qu’un humain occupant le même poste. Près des trois quarts des répondants déclarent que leurs systèmes d’IA ont plus de droits d’accès qu’un humain effectuant les mêmes tâches. Un cinquième indique que leur IA en a nettement plus. Il ne s’agit pas d’un simple excès marginal. C’est une faille structurelle dans la façon dont les organisations attribuent des accès aux identités non humaines — une faille qui crée précisément les conditions des incidents documentés dans le rapport.
3. 85 % des responsables sécurité s’inquiètent des risques liés à l’IA — sur la base de leur expérience, pas de la théorie. Ce n’est pas une crainte hypothétique. Un tiers des répondants confirment au moins un incident lié à l’IA. 24 % soupçonnent qu’un incident a pu se produire. L’inquiétude repose sur la réalité opérationnelle : les organisations constatent que l’IA apporte de vrais gains de productivité — investigation d’incidents plus rapide (66 %), meilleure documentation (71 %), amélioration de la production technique (65 %) — tout en subissant les conséquences de sécurité d’un déploiement d’IA avec des accès trop larges.
4. Les identifiants statiques alimentent la dérive des privilèges de l’IA. Les mots de passe, clés API et jetons longue durée permettent aux systèmes d’IA d’accumuler des accès excessifs. Les organisations qui s’appuient fortement sur ces identifiants statiques affichent un taux d’incident de 67 %, contre 47 % pour celles qui en dépendent peu. Les identifiants statiques n’expirent pas, ne s’adaptent pas et n’imposent pas de décisions d’accès contextuelles. C’est un modèle d’authentification de 2015 appliqué à l’infrastructure IA de 2026.
5. 64 % des organisations n’ont aucun contrôle de gouvernance formel pour l’infrastructure IA. 43 % des organisations déclarent ne disposer d’aucun contrôle de gouvernance formel pour leur infrastructure IA. 21 % supplémentaires n’ont aucun contrôle du tout. Au total, près des deux tiers des organisations déploient l’IA dans leur infrastructure sans les structures de gouvernance nécessaires pour éviter la surdotation en droits, détecter les incidents ou prouver la conformité. L’IA est déjà déployée. Les contrôles, non.

Le problème des accès en chiffres

Teleport a interrogé plus de 200 responsables de la sécurité des infrastructures aux États-Unis pour établir ce rapport, en définissant l’IA dans l’infrastructure comme les charges de travail pilotées par l’IA, les systèmes agentiques, la communication machine à machine, le ChatOps, l’automatisation de la conformité et la détection d’incidents. Les résultats dressent le portrait d’un secteur qui a adopté les gains de productivité de l’IA tout en négligeant de gouverner les accès nécessaires à ces systèmes.

70 % des répondants déclarent que leurs systèmes d’IA disposent de plus de droits d’accès qu’un humain occupant le même poste. 19 % indiquent que leur IA bénéficie d’un accès nettement supérieur. Lorsque les systèmes d’IA sont surdotés, le taux d’incident atteint 76 %. Lorsqu’ils appliquent le principe du moindre privilège, il tombe à 17 %. Ce n’est pas un écart progressif. C’est un changement de catégorie.

Les identifiants statiques — mots de passe, clés API, jetons longue durée — sont le principal vecteur de cette surdotation. Les organisations qui s’appuient fortement sur ces identifiants affichent un taux d’incident de 67 %, contre 47 % pour celles qui en dépendent peu. Les identifiants statiques n’expirent pas d’eux-mêmes. Ils ne s’adaptent pas au contexte. Ils n’imposent pas de limites d’usage. Une fois délivrés, ils octroient un accès permanent jusqu’à ce que quelqu’un pense à les révoquer.

L’absence de gouvernance aggrave le problème. 43 % des organisations n’ont aucun contrôle de gouvernance formel pour leur infrastructure IA. 21 % n’ont aucun contrôle du tout. Au total, près des deux tiers des organisations déploient l’IA dans leur environnement d’infrastructure sans approche structurée pour gérer les accès accordés à ces systèmes. Les systèmes d’IA sont en production. Les cadres de gouvernance sont encore à l’étude.

La gestion des identités d’infrastructure est nécessaire, mais pas suffisante.

Le rapport Teleport identifie à juste titre la nécessité de faire évoluer la gestion des identités pour l’IA. 69 % des responsables sécurité sont d’accord. Mais l’évolution requise va plus loin que ce que suggèrent les recommandations du rapport.

La gestion traditionnelle des identités répond à la question : qui ou quoi est cette entité, et à quels systèmes peut-elle accéder ? Pour les agents IA, cela signifie gérer l’authentification auprès des serveurs, API, bases de données et infrastructures cloud. Des plateformes comme Teleport couvrent ce niveau. Elles gèrent les identités des agents IA, délivrent les identifiants et contrôlent l’accès aux ressources d’infrastructure.

Mais voici la faille : un agent IA disposant d’identifiants d’infrastructure valides et d’une authentification correcte peut toujours accéder à des données auxquelles il ne devrait pas avoir accès. L’accès à l’infrastructure et l’accès aux données sont deux choses différentes. Un agent IA authentifié sur un serveur de base de données peut, par défaut, interroger toutes les tables et tous les enregistrements de cette base. Un agent IA disposant d’un accès API à un dépôt de fichiers peut, par défaut, lire tous les fichiers. L’identité d’infrastructure est vérifiée. L’accès aux données ne l’est pas.

C’est là que naît le multiplicateur de 4,5 fois. Une IA surdotée ne signifie pas une IA avec des identifiants volés ou compromis. Cela signifie une IA disposant d’un accès légitime à une infrastructure contenant des données bien au-delà de ce que sa fonction exige. L’incident ne démarre pas par un échec d’authentification. Il démarre par une autorisation trop large.

Pour combler cette faille, il faut des contrôles d’accès centrés sur la donnée, indépendants de l’identité d’infrastructure. Même lorsqu’un agent IA dispose d’identifiants valides pour un système, les contrôles centrés sur la donnée imposent quelles données il peut consulter, dans quel but et sous quelles conditions. C’est la différence entre gérer qui est l’IA et gouverner ce qu’elle peut faire avec les données auxquelles elle accède.

À quoi ressemblent concrètement les contrôles centrés sur la donnée pour l’IA

Pour éviter la surdotation des IA, il faut des contrôles qui s’appliquent au niveau de la donnée, pas seulement au niveau de l’infrastructure. Voici ce que cela signifie concrètement.

Un accès aux données selon le principe du moindre privilège par défaut signifie qu’un agent IA authentifié sur un système ne peut accéder qu’aux classifications de données nécessaires à sa fonction. Une IA de détection d’incident peut accéder aux journaux système, mais pas aux informations personnelles clients. Une IA d’automatisation de la conformité peut analyser les métadonnées des journaux d’audit, mais pas les enregistrements sensibles sous-jacents. Un bot ChatOps peut récupérer des données de statut opérationnel, mais pas les données financières. La frontière d’accès se situe au niveau de la donnée, pas du système.

Le « purpose binding » limite les agents IA à des référentiels de données et des cas d’usage spécifiques. L’accès de l’IA n’est pas défini par les systèmes qu’elle peut atteindre, mais par ce qu’elle est censée faire. Si une IA de détection d’incident commence soudain à interroger des données financières clients, cet accès est bloqué et signalé — même si l’IA dispose d’identifiants d’infrastructure valides pour le système hébergeant ces données.

La vérification continue implique que chaque requête de données par l’IA est réévaluée selon les règles en vigueur. Il ne s’agit pas de s’authentifier une fois pour accéder à toutes les données indéfiniment. Chaque requête, chaque extraction, chaque interaction avec les données d’entreprise est contrôlée en fonction de la finalité autorisée de l’IA, de la classification des données demandées et du contexte de risque actuel. Cela évite la dérive des privilèges qui survient lorsque les systèmes d’IA accumulent des accès au fil du temps sans gouvernance adaptée.

La détection d’anomalies surveille le comportement des agents IA pour identifier les écarts par rapport aux habitudes établies. Lorsqu’un agent IA qui traite habituellement 50 enregistrements par heure en demande soudain 5 000, ou lorsqu’un outil d’automatisation de la conformité commence à accéder à des catégories de données hors de son périmètre, la déviation déclenche une alerte automatique et peut activer un kill switch révoquant immédiatement l’accès aux données.

Des journaux d’audit détaillés consignent chaque interaction de l’IA avec les données d’entreprise — ce qui a été consulté, quand, par quel agent IA, sous quelle autorisation et quelles actions ont été menées. Ces journaux ne servent pas qu’au reporting de conformité. Ils constituent la base d’investigations forensiques permettant l’investigation rapide des incidents (66 %) et une meilleure documentation (71 %) identifiées comme des bénéfices clés de l’IA dans le rapport Teleport. Impossible d’enquêter sur un incident IA qu’on ne peut pas retracer.

Appliquer les contrôles centrés sur la donnée à tous les usages de l’infrastructure IA

Le rapport Teleport définit l’infrastructure IA de façon large : charges de travail pilotées par l’IA, systèmes agentiques, communication machine à machine, ChatOps, automatisation de la conformité et détection d’incidents. Chacun de ces cas d’usage implique des besoins d’accès aux données spécifiques — et des risques de surdotation particuliers.

Les charges de travail pilotées par l’IA nécessitent un accès aux référentiels de données de l’entreprise pour fonctionner. Les contrôles centrés sur la donnée créent un pont sécurisé entre la charge de travail et la donnée, en appliquant des règles d’accès zero trust limitant la charge de travail aux classifications de données nécessaires à sa fonction. La charge de travail fonctionne à la vitesse machine. Les contrôles d’accès opèrent à la même vitesse.

Les systèmes IA agentiques — agents autonomes capables d’exécuter des processus complexes, d’interagir avec des API et de prendre des décisions opérationnelles — présentent le risque de surdotation le plus élevé car ils agissent sur la donnée, et ne se contentent pas de l’analyser. Chaque agent crée une identité non humaine nécessitant authentification, autorisation et surveillance continue. Les contrôles centrés sur la donnée garantissent que l’IA agentique hérite des autorisations de son responsable humain et ne peut pas outrepasser ces limites.

La communication machine à machine et le ChatOps créent des canaux d’échange de données sans supervision humaine directe à chaque interaction. Les contrôles centrés sur la donnée garantissent que ces canaux respectent les règles d’accès aux données, quelle que soit la vitesse ou le volume des requêtes. Lorsqu’un bot Slack ou Teams accède à des données d’entreprise pour le compte d’un utilisateur, la prise en compte du contexte utilisateur garantit que le bot hérite des autorisations de cet utilisateur — et non de l’accès large du compte de service du bot.

L’automatisation de la conformité et la détection d’incidents sont les cas d’usage où la surdotation est le plus souvent justifiée à tort. L’argument avancé : ces systèmes ont besoin d’un accès large pour fonctionner efficacement. En réalité, ils ont besoin d’accéder aux métadonnées des journaux d’audit, aux métriques agrégées et aux journaux système — pas aux données sensibles sous-jacentes. Un outil d’automatisation de la conformité peut analyser les schémas d’accès aux données sans lire les dossiers patients concernés. Un système de détection d’incident peut repérer des comportements anormaux sans télécharger les données financières impliquées.

Le problème des identifiants statiques est un problème de données

Le rapport Teleport identifie les identifiants statiques — mots de passe, clés API, jetons longue durée — comme principal facteur de surdotation des IA. Les organisations qui s’appuient fortement sur ces identifiants affichent un taux d’incident de 67 %. Le rapport recommande de réduire cette dépendance comme mesure clé.

Cette recommandation est juste, mais incomplète. Remplacer les identifiants statiques par des identifiants dynamiques et de courte durée règle le problème d’authentification à l’infrastructure. Cela oblige les agents IA à prouver leur identité plus fréquemment et garantit que les identifiants expirent avant d’être détournés. Mais les identifiants dynamiques seuls ne règlent pas le problème d’accès aux données. Un agent IA muni d’un jeton d’infrastructure fraîchement délivré et bien ciblé peut toujours accéder à tous les enregistrements auxquels ce jeton donne accès.

La solution complète consiste à superposer des contrôles centrés sur la donnée à une gestion améliorée des identifiants. Les identifiants dynamiques gèrent l’accès à l’infrastructure. La classification des données et le « purpose binding » déterminent quelles données l’IA peut atteindre dans cette infrastructure. La vérification continue garantit l’application des règles d’accès à chaque requête. Les journaux d’audit documentent toute la chaîne — de la délivrance de l’identifiant à l’accès à l’infrastructure, jusqu’à la récupération des données — pour offrir la visibilité nécessaire à la détection et à l’investigation des incidents.

Cette approche en couches — gestion des identités d’infrastructure plus contrôles d’accès centrés sur la donnée — permet de réduire le multiplicateur d’incidents de 4,5 fois. Aucun des deux niveaux n’est suffisant seul. L’identité d’infrastructure sans contrôle sur la donnée laisse la faille de surdotation ouverte au niveau des données. Les contrôles sur la donnée sans gestion d’identité laissent la faille d’authentification ouverte au niveau du système. La défense en profondeur exige les deux.

Ce que les responsables sécurité doivent faire dès maintenant

Appliquer le principe du moindre privilège pour l’accès aux données de chaque système d’IA déjà déployé. Auditez les données auxquelles chaque agent IA a accès aujourd’hui. Comparez cet accès à ce dont l’agent a réellement besoin pour sa fonction. Limitez l’accès aux seules classifications de données nécessaires. Cette action cible le facteur le plus prédictif d’incidents identifié dans le rapport.

Déployer des contrôles d’accès centrés sur la donnée, indépendants de l’identité d’infrastructure. Même si les agents IA disposent d’identifiants d’infrastructure valides, les contrôles centrés sur la donnée doivent imposer les données accessibles, le but et les conditions d’accès. Le « purpose binding », le contrôle d’accès basé sur les attributs et la vérification continue au niveau de la donnée comblent la faille que la gestion des identités d’infrastructure ne peut traiter seule.

Remplacer les identifiants statiques par des identifiants dynamiques de courte durée — et superposer des contrôles sur la donnée. Éliminez les mots de passe, clés API longue durée et jetons persistants pour les systèmes d’IA. Passez à la délivrance d’identifiants dynamiques à expiration automatique. Mais gardez à l’esprit que la réforme des identifiants ne règle pas à elle seule le problème d’accès aux données. Superposez classification des données, « purpose binding » et vérification continue pour gouverner ce que l’IA fait avec les accès fournis par ses identifiants.

Mettre en place des cadres de gouvernance avant le prochain déploiement d’IA en production. 64 % des organisations n’ont aucun contrôle de gouvernance formel pour l’infrastructure IA. Chaque nouveau déploiement d’IA sans gouvernance élargit la faille de surdotation. Élaborez des règles claires pour l’accès aux données par l’IA, définissez les voies d’escalade en cas d’incident lié à l’IA et attribuez explicitement la responsabilité de la gestion des risques IA. Le cadre de gouvernance doit être en place avant que le système d’IA ne reçoive son premier identifiant.

Déployer la détection d’anomalies et des kill switches pour l’accès aux données par l’IA. Surveillez en continu le comportement des agents IA par rapport aux habitudes établies. Lorsque les schémas d’accès dévient — volumes inhabituels, nouvelles catégories de données, activité hors horaires — déclenchez une alerte automatique et révoquez immédiatement l’accès aux données. Le multiplicateur d’incidents de 4,5 fois signifie que détecter tôt un comportement d’IA surdotée vaut mieux que n’importe quel autre contrôle.

Construire des journaux d’audit retraçant toute la chaîne d’accès aux données par l’IA. Chaque interaction de l’IA avec les données d’entreprise doit être consignée avec l’identité de l’agent IA, le responsable humain autorisant, la classification des données consultées, l’horodatage et l’action menée. Ces journaux facilitent l’investigation rapide des incidents et une meilleure documentation, identifiées comme des bénéfices clés de l’IA dans le rapport — tout en fournissant la preuve forensique nécessaire en cas d’incident et la documentation de conformité exigée par les régulateurs.

Le multiplicateur 4,5x est un choix, pas une fatalité

Le rapport Teleport livre un constat aussi inconfortable qu’éclairant : les organisations qui subissent le plus d’incidents de sécurité liés à l’IA ne sont pas celles qui en déploient le plus. Ce sont celles qui déploient l’IA avec le plus d’accès. Le risque, c’est la surdotation, pas l’adoption.

Autrement dit, le multiplicateur d’incidents de 4,5 fois est un choix. Les organisations qui appliquent le principe du moindre privilège, déploient des contrôles centrés sur la donnée en complément de la gestion des identités d’infrastructure, remplacent les identifiants statiques, mettent en place des cadres de gouvernance et surveillent en continu le comportement de l’IA, évolueront dans la zone des 17 % d’incidents. Celles qui déploient l’IA avec des accès larges, des identifiants statiques et sans gouvernance resteront à 76 %.

Les gains de productivité sont réels. Investigation d’incident plus rapide. Meilleure documentation. Production technique améliorée. Aucune organisation ne devrait s’en priver. Le Réseau de données privé Kiteworks apporte la couche de gouvernance centrée sur la donnée — purpose binding, vérification continue, journaux d’audit immuables et détection d’anomalies — que les plateformes d’identité d’infrastructure ne peuvent fournir seules. Mais pour en bénéficier sans accepter un taux d’incident 4,5 fois supérieur, il faut repenser l’accès à l’IA : passer du niveau infrastructure au niveau donnée, des identifiants statiques à la vérification continue, et de la gouvernance en option à la gouvernance en prérequis.

L’IA n’est pas dangereuse. C’est l’accès que vous lui donnez qui l’est. Corrigez l’accès, et vous corrigez le risque.

Pour découvrir comment Kiteworks peut vous accompagner, réservez votre démo personnalisée dès maintenant.

Ressources complémentaires

• Article de blog Architecture Zero Trust : Ne jamais faire confiance, toujours vérifier
• Vidéo Microsoft GCC High : Les inconvénients qui poussent les sous-traitants de la défense vers des solutions plus intelligentes
• Article de blog Comment sécuriser les données classifiées après leur détection par DSPM
• Article de blog Instaurer la confiance dans l’IA générative grâce à une approche Zero Trust
• Vidéo Guide ultime pour le stockage sécurisé des données sensibles à destination des responsables IT