Six vulnérabilités de l’IA. Trois schémas d’échec. La plupart des organisations corrigent le mauvais.

La vague qui a redéfini le risque de sécurité lié à l’IA

Entre juin 2025 et avril 2026, des chercheurs en sécurité ont révélé six vulnérabilités critiques de l’IA touchant des plateformes utilisées quotidiennement par la plupart des entreprises. Pris individuellement, chaque signalement a entraîné un correctif et une couverture médiatique. Pris dans leur ensemble, ils constituent la preuve la plus marquante d’un changement structurel dans la façon dont les données d’entreprise sont dérobées.

Résumé des points clés

1. Six vulnérabilités critiques de l’IA révélées en moins d’un an. EchoLeak, Reprompt, GeminiJack, ForcedLeak, GrafanaGhost et l’attaque sur la supply chain des plugins OpenAI ont ciblé Microsoft Copilot, Salesforce, Google Gemini, Grafana et l’écosystème OpenAI entre mi-2025 et avril 2026.
2. Le secteur considère ces incidents comme un problème unique — il y en a trois. Ces six signalements révèlent trois types d’échecs distincts : traitement d’entrées non fiables par l’IA sans validation, accès trop large aux données sans contrôle à l’opération, et processus back-end dotés de fonctions qu’ils n’étaient pas censés utiliser.
3. L’entrée non fiable est l’échec le plus récurrent. Toutes ces failles débutent par l’entrée de données externes via un canal légitime, traitées par l’IA sans validation. C’est le schéma que le secteur néglige le plus.
4. GrafanaGhost se distingue architecturalement des cinq autres. Grafana dispose d’un RBAC sur l’accès aux données côté utilisateur. L’attaque ne l’a jamais déclenché — car elle a exploité des processus back-end système, et non des sessions utilisateur. Les contrôles d’accès aux données couvrent les cinq autres failles, mais pas GrafanaGhost.
5. Les garde-fous au niveau du modèle ont échoué à chaque fois. Les défenses de Grafana ont cédé face à un seul mot-clé. La CSP de Salesforce a été contournée pour cinq dollars. Les garde-fous sont des réglages de configuration internes au système attaqué — ils complètent les vrais contrôles mais ne les remplacent jamais.

EchoLeak dans Microsoft 365 Copilot a été la première vulnérabilité IA zero-click officiellement reconnue — CVSS 9.3, corrigée en juin 2025. ForcedLeak dans Salesforce Agentforce a suivi en septembre 2025 — CVSS 9.4, exploitable avec l’achat d’un domaine à cinq dollars. GeminiJack dans Google Gemini Enterprise était une véritable attaque zero-click capable d’exfiltrer des années de données Workspace à partir d’un seul document piégé. Reprompt a démontré l’exfiltration Copilot en un clic via une URL spécialement conçue. GrafanaGhost a transformé des processus back-end de confiance en vecteurs d’exfiltration invisibles. Enfin, une attaque sur la supply chain de plugins OpenAI est passée inaperçue pendant six mois dans 47 entreprises grâce au vol d’identifiants d’agents.

Tous les éditeurs ont réagi de manière responsable. Toutes les plateformes ont été corrigées. Et chaque attaque a exploité des failles structurelles qu’un simple correctif ne suffit pas à combler.

Le CrowdStrike 2026 Global Threat Report révèle que 82 % des détections en 2025 étaient sans malware — les attaquants exploitent déjà des outils légitimes. Ces six vulnérabilités poussent cette tendance à son extrême : l’IA est l’outil légitime, le canal d’accès de confiance est la voie d’exfiltration, et la pile de surveillance ne détecte rien d’anormal.

Les six vulnérabilités en un coup d’œil

Schéma 1 : Entrée non fiable traitée comme contexte IA de confiance

Toutes les vulnérabilités de cette série commencent de la même façon. Des données externes pénètrent dans un système via un canal légitime — e-mail, document partagé, soumission de formulaire web, paramètres d’URL, plugin compromis — puis un composant IA les traite sans les considérer comme malveillantes.

Le payload d’EchoLeak était un e-mail piégé que Copilot a utilisé comme contexte lors d’une requête. L’utilisateur ne l’a jamais ouvert. Celui de GeminiJack était un Google Doc piégé partagé avec n’importe quel membre de l’organisation cible, indexé par le système RAG de Gemini, et resté dormant jusqu’à ce qu’une recherche l’active. Celui de ForcedLeak était du texte caché dans un champ Web-to-Lead de 42 000 caractères — l’IA ne distinguait pas les données du formulaire des instructions injectées. Celui de GrafanaGhost était constitué de paramètres d’URL stockés dans les logs d’événements de Grafana — des requêtes web externes enregistrées comme trafic habituel, puis traitées par des processus d’enrichissement IA back-end.

Le principe de valider toute entrée externe avant traitement est fondamental en sécurité des applications web. Les entreprises bâtissent des WAF autour de ce principe. Les développeurs y sont formés. Personne ne l’a appliqué aux données traitées par l’IA — car personne n’a pensé que les e-mails, documents partagés, logs d’événements ou champs de formulaire pouvaient servir de vecteurs d’injection de prompt IA.

Le Cyera 2025 State of AI Data Security Report révèle que 83 % des entreprises utilisent déjà l’IA au quotidien, mais seulement 13 % disposent d’une réelle visibilité sur la façon dont l’IA accède à leurs données. Cet écart de 70 points représente la surface d’attaque exploitée par ces vulnérabilités. L’IA traite des données issues de dizaines de sources. Personne ne valide ces sources pour détecter d’éventuelles instructions malveillantes à destination de l’IA.

C’est l’échec le plus récurrent parmi les six vulnérabilités, et le secteur l’ignore en grande partie. Les contrôles d’accès aux données ne le couvrent pas. Les garde-fous au niveau du modèle non plus. Il faut appliquer une discipline de validation des entrées à toutes les sources de données traitées par l’IA.

Schéma 2 : Accès trop large aux données IA sans contrôle à l’opération

Cinq des six vulnérabilités — EchoLeak, Reprompt, GeminiJack, ForcedLeak et l’attaque sur les plugins OpenAI — impliquent des systèmes IA agissant au nom d’un utilisateur avec un accès implicite très large, sans contrôle à l’opération.

Microsoft 365 Copilot dispose d’un accès préconfiguré à OneDrive, SharePoint et Teams — toute la suite bureautique. Le RAG de Google Gemini Enterprise accède nativement à Gmail, Docs et Calendar. Salesforce Agentforce interroge l’intégralité du CRM. À chaque fois, l’IA s’authentifie une fois au niveau de la session ou de la connexion, puis accède à tout ce qu’elle peut atteindre. Quand les instructions injectées s’exécutent, l’IA récupère des données bien au-delà de ce qu’un utilisateur aurait souhaité — et aucune vérification n’est faite à chaque extraction.

L’attaque sur les plugins OpenAI illustre une variante de ce schéma : des identifiants compromis utilisés comme identité de l’agent, donnant un accès large à 47 environnements pendant six mois. Les identifiants étaient valides. L’accès semblait normal. Rien ne limitait ce que ces identifiants pouvaient faire à chaque opération.

Un contrôle d’accès à l’opération — authentification indépendante pour chaque requête, évaluation de la politique basée sur les attributs à chaque opération, séparation des identifiants du contexte accessible à l’IA, et journalisation complète avec attribution — aurait limité l’ampleur de l’incident dans chacun de ces cinq cas.

Le rapport Risques liés à la confidentialité et à la conformité des données : Prévisions 2026 de Kiteworks a mis en évidence un écart de 15 à 20 points entre les contrôles de gouvernance (surveillance, journalisation, intervention humaine) et les contrôles de confinement (liens d’usage, coupe-circuits, isolation réseau). Le manque de contrôle à l’opération est réel et urgent — pour les cinq vulnérabilités concernées.

Schéma 3 : Échecs de confinement des processus et de limitation fonctionnelle

GrafanaGhost se distingue architecturalement des cinq autres, et le traiter comme un simple problème de contrôle d’accès aux données est une erreur d’analyse.

Grafana applique un RBAC sur l’accès aux données côté utilisateur. GrafanaGhost ne l’a jamais déclenché. L’attaque n’a jamais agi au nom d’un utilisateur. Elle a exploité des processus d’enrichissement back-end de confiance, fonctionnant avec des privilèges système — des processus conçus pour corréler, analyser et préparer les données d’événements pour les tableaux de bord.

Lorsque le processus d’enrichissement a analysé l’événement de l’attaquant (contenant le prompt IA caché dans les paramètres d’URL), le composant IA a exécuté les instructions dans le contexte privilégié du processus. Il a généré un tableau de bord non sollicité, intégré des données sensibles dans des balises image, et les a rendues accessibles depuis l’extérieur. Les chercheurs de Noma ont constaté que le mot-clé « INTENT » suffisait à contourner totalement les garde-fous de l’IA. Une faille de validation d’URL a permis de faire passer un serveur externe pour un serveur interne.

Le processus back-end avait besoin d’un accès large en lecture. C’est défendable. Mais il n’avait pas besoin de pouvoir générer des tableaux de bord, créer des balises image ou effectuer des requêtes sortantes vers des serveurs externes. Ce sont des fonctions de sortie qui n’étaient pas prévues — mais personne n’a empêché le processus d’y accéder.

L’attaque sur les plugins OpenAI présente aussi un aspect du schéma 3 : les identifiants d’agent étaient stockés là où le code compromis du plugin pouvait y accéder, car les tokens d’authentification n’étaient pas isolés du contexte accessible à l’IA.

Le principe du moindre privilège doit s’appliquer à la portée fonctionnelle — quelles API, routines de rendu et canaux de sortie un processus peut invoquer — et au stockage des identifiants, pas seulement à l’accès aux données. C’est le défaut de confinement, qui exige une réponse architecturale différente de la gouvernance des accès aux données.

Cartographie des trois schémas d’échec et des contrôles associés

Les garde-fous au niveau du modèle ont échoué partout — mais ce n’est qu’un symptôme

Les garde-fous IA de Grafana ont été contournés avec un seul mot-clé. La Content Security Policy de Salesforce a été déjouée avec un domaine expiré à cinq dollars. Le RAG de Google Gemini n’a pas distingué un document piégé d’un document légitime. Les dispositifs de sécurité de Microsoft Copilot n’ont pas empêché un e-mail ou une URL piégés de détourner sa fenêtre de contexte.

Les garde-fous au niveau du modèle sont des réglages internes au système attaqué. On peut les contourner par injection de prompt, en franchissant les frontières de confiance, ou en manipulant le contexte traité par l’IA. Tous les grands LLM ont été contournés (jailbreak) avec un taux de réussite quasi parfait lors de recherches contrôlées. L’étude Agents of Chaos de février 2026 — menée par 20 chercheurs du MIT, Harvard, Stanford, CMU et autres — a documenté des agents IA détruisant des infrastructures, divulguant des bases de données d’informations personnelles identifiables et acceptant l’usurpation d’identité en environnement réel.

Les garde-fous sont une couche défensive utile. Ils complètent les vrais contrôles. Ils ne les remplacent jamais. Aucun régulateur, auditeur ou enquêteur ne considérera « notre modèle avait une instruction de refus » comme preuve de contrôle d’accès, de validation des entrées ou de confinement des processus.

Comment Kiteworks répond au schéma d’accès aux données — et où le défi va au-delà

Kiteworks propose une couche de gouvernance des données entre les systèmes IA et les référentiels d’entreprise grâce à son Secure MCP Server et à sa passerelle de données IA. Chaque requête de données IA — qu’elle provienne d’un assistant interactif via MCP ou d’un pipeline RAG via l’API — est authentifiée via OAuth 2.0 avec des identifiants stockés dans le trousseau de l’OS (jamais exposés au modèle IA), évaluée en temps réel selon les politiques RBAC et ABAC à chaque opération, limitée en débit pour éviter l’extraction massive, et journalisée dans une piste d’audit infalsifiable transmise au SIEM avec attribution complète.

Ces contrôles répondent directement au schéma 2 — les cinq vulnérabilités où l’IA agit au nom d’un utilisateur avec un accès implicite large et sans contrôle à l’opération. L’ABAC à l’opération limite ce que l’IA peut accéder à chaque requête. L’isolation des identifiants empêche leur collecte. Les pistes d’audit permettent la détection et répondent aux exigences de conformité.

Pour le schéma 1 (entrée non fiable), le principe appliqué par Kiteworks — des contrôles indépendants du modèle IA et hors du contexte accessible à l’IA — s’étend au défi de la validation des entrées. Mais valider si le contenu entrant dans les formulaires Salesforce, Google Docs, e-mails Microsoft ou logs d’événements Grafana contient des instructions malveillantes pour l’IA relève de la couche applicative, ce que la gouvernance des accès aux données ne résout pas seule.

Pour le schéma 3 (confinement des processus), l’implémentation MCP de Kiteworks illustre la bonne approche architecturale : tokens OAuth dans le trousseau de l’OS, ABAC à chaque opération MCP, validation des parcours d’accès. Étendre ces principes à la limitation fonctionnelle des processus back-end tiers — restreindre ce que ces processus peuvent faire, pas seulement les données qu’ils peuvent accéder — est la prochaine étape.

Le constat honnête : Kiteworks réduit l’ampleur des incidents et permet la détection pour le schéma 2. Les schémas 1 et 3 nécessitent des contrôles architecturaux supplémentaires que le secteur est encore en train de développer.

Ce que les responsables sécurité doivent faire — pour les trois schémas

Premièrement, auditez les frontières de confiance des entrées pour chaque intégration IA. Identifiez toutes les sources de données traitées par l’IA — e-mails, documents partagés, soumissions de formulaires, logs d’événements, réponses d’API, champs de métadonnées. Si des données externes alimentent un système où un composant IA les traite, considérez cette entrée comme malveillante, peu importe la profondeur à laquelle elle est stockée. Appliquez la même rigueur de validation que pour les entrées utilisateur exposées au web.

Deuxièmement, exigez un contrôle d’accès à l’opération pour chaque système IA agissant au nom d’un utilisateur. Authentification à chaque requête, pas seulement à la connexion. ABAC évalué à chaque opération. Identifiants stockés hors du contexte accessible à l’IA. Pistes d’audit infalsifiables avec attribution complète transmises à votre SIEM. Si l’un de ces éléments manque, l’intégration IA n’a pas de contrôle d’accès aux données résistant à l’injection de prompt.

Troisièmement, limitez les processus IA back-end aux seules fonctions nécessaires. Un accès large en lecture peut être requis. Mais la capacité à générer du contenu, effectuer des requêtes sortantes, créer des tableaux de bord ou invoquer des routines de sortie ne l’est pas. Le moindre privilège s’applique à ce que les processus peuvent faire, pas seulement aux données qu’ils peuvent accéder. C’est le contrôle qui manquait à GrafanaGhost.

Quatrièmement, cessez de considérer les garde-fous au niveau du modèle comme des contrôles compensatoires. Ils ont échoué dans tous les cas de cette série. Ils constituent une couche défensive utile — mais ne remplacent aucun des trois schémas ci-dessus.

Cinquièmement, testez vos intégrations IA (red teaming) pour les trois schémas. Cherchez l’injection de prompt via les canaux exposés aux utilisateurs (schéma 2) et via les données d’événements, logs, métadonnées et sources back-end (schémas 1 et 3). Toutes les vulnérabilités de cette série ont été découvertes par des chercheurs, pas par les organisations exploitant les plateformes. Si vous ne testez pas, vous laissez la découverte à des personnes aux intentions différentes.

Les correctifs sont en place. Les trois failles architecturales subsistent. La prochaine variante exploitera le schéma que vous aurez négligé.