Le problème du facteur 2,5 : comment les tests d’intrusion par l’IA ont redéfini la question de la sécurité des données

Quand votre test de sécurité applicative révèle un taux de failles critiques de 13 %, vous considérez cela comme une journée ordinaire. Mais s’il atteint 32 %, vous stoppez le déploiement. Le rapport Cobalt State of Pentesting 2026 indique que les systèmes basés sur l’IA et les LLM affichent en moyenne un taux de 32 % — soit près de 2,5 fois la densité de failles critiques des applications d’entreprise traditionnelles. Cobalt identifie la cause principale : l’injection de prompts a dépassé toutes les autres catégories et occupe désormais la première place du classement OWASP LLM Top 10.

De nouvelles surfaces d’attaque — outils de modélisation, orchestrateurs de plugins, pipelines de récupération, autorisations des connecteurs — créent des zones d’impact que les outils de sécurité applicative classiques ne mesurent pas. La responsabilité de la remédiation reste floue dans la plupart des organisations, car l’IA se situe à la croisée des équipes sécurité, data et ingénierie plateforme.

Les pentesters tirent une conclusion que le reste du secteur évite : les systèmes d’IA ne constituent pas un simple niveau applicatif supplémentaire. Ils représentent une catégorie structurellement plus risquée, nécessitant leur propre modèle de menace, leur propre SDLC sécurisé et leurs propres contrôles en temps réel.

5 points clés à retenir

1. L’IA présente une densité de failles critiques 2,5 fois supérieure à celle des applications traditionnelles.

Le rapport Cobalt State of Pentesting 2026 révèle que 32 % des failles détectées sur les systèmes IA et LLM sont jugées à haut risque, contre 13 % pour les applications d’entreprise classiques. Ce n’est pas un problème de paramétrage — il s’agit d’une différence structurelle de surface d’attaque qui impose un modèle de menace distinct, un SDLC sécurisé dédié et des contrôles spécifiques à l’exécution. Tester l’IA avec les processus de sécurité applicative existants sous-estime le taux de failles critiques d’un facteur supérieur à deux. La gouvernance de l’IA commence par reconnaître explicitement ce décalage.

2. L’injection de prompts est le nouveau risque numéro un selon l’OWASP LLM.

HackerOne a constaté une hausse de 540 % des signalements d’injection de prompts dans les rapports de bug bounty d’une année sur l’autre, signe que les attaquants ont rattrapé la courbe de déploiement de l’IA. L’injection de prompts domine désormais le Top 10 LLM de l’OWASP, avec de nouvelles surfaces d’attaque — outils de modélisation, orchestrateurs de plugins, pipelines de récupération, autorisations de connecteurs — qui créent des zones d’impact que les outils de sécurité applicative classiques ne mesurent pas.

3. Le vrai manque concerne la capacité de confinement, pas la détection.

63 % des organisations ne peuvent pas imposer de limites d’usage aux agents IA, 60 % ne peuvent pas mettre fin à un agent défaillant, et 55 % ne peuvent pas isoler les systèmes IA de l’accès au réseau étendu. L’écart entre gouvernance et confinement atteint 15 à 20 points : les organisations ont investi dans la surveillance de l’IA, pas dans son arrêt. Même avec des projections optimistes, environ un quart des entreprises finiront 2026 sans confinement basique pour les systèmes IA déjà déployés. Les journaux d’audit sans bouton d’arrêt ne prouvent qu’une chose : une violation a eu lieu, ils ne l’empêchent pas.

4. Les pentests révèlent ce qui est détectable.

L’injection de prompts, l’abus d’appels d’outils et la mauvaise utilisation des connecteurs convergent tous vers la même couche : la donnée. L’exploitation touche le modèle ; le préjudice touche la donnée. La question qui détermine l’ampleur de l’impact n’est pas « le modèle peut-il être trompé » — la hausse de 540 % sur HackerOne prouve que oui — mais « quelles données sont touchées lorsqu’il l’est, et qui peut prouver ce qui s’est passé ? ». Les contrôles applicatifs répondent à la première moitié, mais pas à la seconde. Les contrôles au niveau de la donnée répondent aux deux.

5. La gouvernance au niveau de la donnée est la seule architecture pérenne.

L’application d’ABAC, le chiffrement FIPS 140-3 et des journaux d’audit infalsifiables au niveau de la donnée limitent l’impact, même en cas d’exploitation. Si le modèle est trompé et demande des données auxquelles il ne devrait pas accéder, le moteur de règles refuse — et le journal consigne la tentative. L’exploitation devient alors un refus consigné, et non un incident réglementaire.

Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?

Pour en savoir plus :

Ce que révèlent les données Kiteworks sur l’origine de ce décalage

Le rapport prévisionnel Kiteworks 2026 établit le lien de façon explicite. Le problème de densité des failles détectées lors des pentests découle d’un problème de contrôles, quantifié par l’enquête : les organisations ont investi dans la surveillance de l’IA, pas dans son arrêt. 63 % ne peuvent pas imposer de limites d’usage aux agents IA — l’agent peut faire tout ce que ses connecteurs permettent, indépendamment des règles. 60 % ne peuvent pas mettre fin rapidement à un agent défaillant — il n’existe pas de bouton d’arrêt, il faut revenir sur le déploiement. 55 % ne peuvent pas isoler les systèmes IA du réseau — l’agent qui appelle une API fournisseur peut aussi accéder à vos partages de fichiers.

L’écart entre gouvernance et confinement atteint 15 à 20 points : 59 % disposent d’une supervision humaine, 58 % d’une surveillance continue, 56 % d’une minimisation des données. Même avec des projections optimistes sur les contrôles prévus, environ un quart des organisations finiront 2026 sans confinement basique pour les systèmes IA déjà déployés. Le rapport prévisionnel 2026 désigne ce point comme la principale tension de la sécurité IA agentique — et elle ne se résoudra pas d’elle-même.

Pourquoi il s’agit d’un problème de couche données, et non de sécurité applicative

Analysez chaque schéma d’attaque identifié par Cobalt jusqu’à la source du préjudice. Injection de prompts : le modèle exécute une instruction qu’il n’aurait pas dû suivre et produit un résultat qu’il n’aurait pas dû générer. Abus d’appels d’outils : le modèle invoque une fonction avec des arguments inappropriés. Mauvaise utilisation des connecteurs : le modèle accède à un système auquel il n’aurait pas dû accéder.

Dans tous les cas, l’exploitation touche le modèle. Le préjudice touche la donnée. Cela signifie que la question déterminante n’est pas « le modèle peut-il être trompé » — il le sera, la hausse de 540 % sur HackerOne le prouve — mais « quelles données le modèle manipule-t-il lorsqu’il est trompé, et qui peut prouver ce qui s’est passé ? ». Les contrôles applicatifs répondent à la première partie. Les contrôles au niveau de la donnée répondent aux deux, et fournissent les preuves exigées par les régulateurs.

Ce que signifie concrètement la gouvernance au niveau de la donnée

Trois contrôles font l’essentiel du travail, chacun déplaçant le point de contact entre le modèle et la donnée :

Contrôles d’accès basés sur les attributs (ABAC) pour chaque accès aux données. Chaque requête d’agent IA est évaluée selon les règles ABAC avant tout accès — qui effectue l’appel, quel jeu de données est demandé, dans quel but, et si la politique autorise cette combinaison. Le modèle peut être trompé pour demander. Le moteur de règles répond non.

Chiffrement validé FIPS 140-3 avec clés gérées par le client. Le modèle ne voit jamais de données déchiffrées en masse sans autorisation du moteur de règles. Les clés gérées par le client, hors de portée du fournisseur IA, garantissent qu’un orchestrateur compromis ne pourra pas accéder à la matière première.

Journaux d’audit infalsifiables transmis en temps réel à la SIEM. Chaque interaction du modèle avec des données réglementées produit un enregistrement immuable — identité de l’appelant, jeu de données, évaluation des attributs, décision de la politique, horodatage. Quand le régulateur demande ce qui s’est passé lors d’un incident d’injection de prompts, vous avez la réponse.

L’approche Kiteworks : une gouvernance qui tient quand les prompts échouent

Kiteworks Secure MCP Server et AI Data Gateway étendent la gouvernance au niveau de la donnée aux interactions des agents IA, afin que chaque requête du modèle vers des données réglementées passe par les mêmes contrôles que pour les utilisateurs humains : ABAC à chaque appel, chiffrement FIPS 140-3 validé avec clés gérées par le client, journaux d’audit infalsifiables transmis en temps réel, et isolation à locataire unique pour éliminer les risques d’attaque entre locataires.

L’injection de prompts reste possible. La hausse de 540 % sur HackerOne ne va pas ralentir. Ce qui change, c’est l’ampleur de l’impact. Si le modèle est trompé et demande des données auxquelles il ne devrait pas accéder, le moteur de règles refuse — et le journal d’audit consigne la tentative. L’exploitation devient alors un refus consigné, et non un incident réglementaire. Le Réseau de données privé Kiteworks étend cette architecture à la messagerie électronique, au partage de fichiers, au MFT, au SFTP, aux formulaires web et aux API, sous un même moteur de règles et un journal d’audit consolidé.

Ce que les RSSI doivent faire ce trimestre

Premièrement, considérez les systèmes IA comme une surface d’attaque distincte dans votre modèle de menace. Mettez en place un volet de modélisation des menaces dédié à l’IA, ciblant l’injection de prompts, l’abus d’appels d’outils et les autorisations des connecteurs comme modes d’échec principaux. Votre processus de sécurité applicative actuel sous-estimera le taux de failles critiques d’un facteur supérieur à deux.

Deuxièmement, auditez les contrôles de confinement avant les contrôles de gouvernance. La gouvernance est un investissement plus facile — la journalisation ne nécessite pas de changement d’architecture. Le confinement est plus difficile et plus important. Si vous ne pouvez pas arrêter un agent défaillant, les autres contrôles ne servent à rien.

Troisièmement, déplacez l’application des contrôles d’accès de la couche applicative à la couche données. L’ABAC sur chaque requête du modèle vers des données réglementées, avec chiffrement FIPS 140-3 validé et clés gérées par le client, est la seule architecture qui résiste à l’injection de prompts à grande échelle. Les projections du rapport prévisionnel 2026 — 24 à 36 % des organisations manqueront encore de boutons d’arrêt et de limites d’usage à la fin de l’année — signifient que toute organisation sans contrôle au niveau de la donnée fait partie du groupe à la traîne.

Quatrièmement, entraînez-vous au scénario d’incident d’injection de prompts. Que fait votre SOC lorsqu’un agent IA accède à des données hors de son périmètre autorisé ? Qui est alerté ? Quels journaux sont extraits ? Quel dossier de preuves est transmis au régulateur ? Les exercices de simulation permettent de combler l’écart avant que le régulateur ne le découvre à votre place.

Pour en savoir plus sur la gouvernance des données IA, réservez votre démo personnalisée sans attendre.

Foire aux questions

Oui. Les systèmes IA/LLM présentent un taux de failles critiques de 32 % contre 13 % pour les applications traditionnelles selon Cobalt 2026. Les contrôles de confinement — limitation des usages, boutons d’arrêt, isolation réseau — sont les plus grandes lacunes selon le rapport prévisionnel Kiteworks 2026. Mettez en place un volet de modélisation des menaces IA dédié à l’injection de prompts et à l’abus d’appels d’outils, associé à l’application de l’ABAC au niveau des données et à des journaux d’audit infalsifiables.

L’usage réglementé de l’IA requiert au minimum trois contrôles : ABAC à chaque requête du modèle, chiffrement validé FIPS 140-3 avec clés gérées par le client, et journaux d’audit infalsifiables. PCI DSS impose une séparation démontrable des données de titulaires de carte de tout modèle qui n’en a pas besoin — c’est le moteur de règles, et non le modèle, qui doit faire respecter cette frontière. La norme HIPAA « minimum necessary » exige la même logique au niveau des informations médicales protégées (PHI).

Probablement pas au sens où vous l’entendez. 60 % des organisations ne peuvent pas arrêter rapidement un agent défaillant, et la principale lacune concerne la détection — vous avez peut-être déjà subi un incident sans le savoir. La hausse de 540 % des signalements d’injection de prompts dans les rapports de bug bounty suggère que les attaquants ont rattrapé leur retard. La vraie question n’est pas de savoir si vous avez eu un incident, mais si vos journaux d’audit vous le révéleraient.

Trois chiffres structurent la discussion : densité des failles critiques (32 % contre 13 % selon Cobalt), écart de confinement (63 % ne peuvent pas imposer de limites d’usage, 60 % n’ont pas de bouton d’arrêt, 55 % ne peuvent pas isoler l’IA du réseau selon le rapport prévisionnel Kiteworks 2026), et attaques menées par des adversaires dopés à l’IA (hausse de 89 % d’une année sur l’autre selon CrowdStrike). Ensemble, ils montrent que le risque IA n’est pas un problème pour 2027 — c’est une priorité de conformité pour ce trimestre.

Partiellement. Les offres IA commerciales proposent certains mécanismes de gouvernance — contrôles d’accès, politiques de rétention, journaux d’audit au niveau de la plateforme. Elles n’appliquent pas l’ABAC sur les données d’entreprise sous-jacentes interrogées par le modèle via les connecteurs. Cette frontière — l’interface donnée-modèle — doit être gérée par votre architecture de données, non par le fournisseur IA. L’AI Data Gateway de Kiteworks gère cette couche, quel que soit le fournisseur IA utilisé.

Ressources complémentaires

  • Article de blog
    Stratégies Zero‑Trust pour une protection abordable de la vie privée avec l’IA
  • Article de blog
    Comment 77 % des organisations échouent à sécuriser les données IA
  • eBook
    AI Governance Gap : 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 n’attendent plus que vous ayez une politique IA. Ils veulent la preuve qu’elle fonctionne.

Lancez-vous.

Il est facile de commencer à garantir la conformité réglementaire et à gérer efficacement les risques avec Kiteworks. Rejoignez les milliers d’organisations qui ont confiance dans la manière dont elles échangent des données privées entre personnes, machines et systèmes. Commencez dès aujourd’hui.

Table of Content
Partagez
Tweetez
Partagez
Explore Kiteworks