GrafanaGhost révèle trois failles de sécurité de l’IA — pas une seule

L’URL d’un attaquant, un processus back-end et vos données financières sur un serveur externe

Le 7 avril 2026, des chercheurs de Noma Security ont révélé GrafanaGhost — une attaque qui a transformé les processus internes de confiance de Grafana en un pipeline d’exfiltration de données à leur insu. Le secteur a présenté cela comme une défaillance du contrôle d’accès aux données par l’IA. Cette explication est incomplète — et cette nuance a des conséquences pour toutes les organisations qui déploient des outils dopés à l’IA.

Résumé des points clés

1. L’attaque a dissimulé des prompts dans les données de surveillance des événements. Les attaquants ont créé des URLs dont les paramètres de requête se retrouvaient dans les journaux d’entrée de Grafana. Des processus d’enrichissement back-end, dotés de privilèges système, ont ensuite exécuté les instructions IA cachées — générant un tableau de bord non sollicité et intégrant des données sensibles dans des balises d’image sortantes.
2. Grafana applique la RBAC à l’accès aux données côté utilisateur. L’attaque n’a jamais déclenché ce contrôle. GrafanaGhost a opéré via des processus back-end au niveau système, et non via des sessions utilisateur. Les contrôles d’accès au niveau utilisateur étaient donc inopérants, car l’attaque contournait totalement cette couche.
3. Il s’agit de trois schémas d’échec, et non d’un seul. Défaillance de la frontière de confiance des entrées (données externes traitées sans validation), échec du cloisonnement des processus (processus back-end doté d’un périmètre fonctionnel qu’il n’aurait jamais dû avoir), et défaillance des garde-fous au niveau du modèle (contournés par un simple mot-clé). Chacun nécessite une correction différente.
4. La même défaillance de confiance dans les entrées est présente dans toutes les grandes failles IA de l’année écoulée. EchoLeak, GeminiJack, ForcedLeak, Reprompt et GrafanaGhost débutent tous par l’entrée de données externes non fiables dans un système, traitées par l’IA sans validation.
5. La gouvernance de l’accès aux données ne traite qu’un schéma. La validation des entrées et le cloisonnement des processus traitent les deux autres. Les confondre garantit qu’en corrigeant l’un, les autres restent exposés.

Un attaquant a envoyé des requêtes web forgées à une instance Grafana. Ces requêtes semblaient anodines — mais les paramètres de requête de l’URL cachaient des instructions IA. La surveillance des événements de Grafana a enregistré ces requêtes comme du trafic entrant classique. La charge malveillante se retrouvait alors stockée au cœur du système, indiscernable des données opérationnelles légitimes.

Grafana occupe une place centrale dans l’observabilité des entreprises, connecté à des bases de données, des infrastructures cloud, des systèmes financiers et des backends clients. Ce qui s’est passé ensuite explique pourquoi GrafanaGhost est significatif sur le plan architectural.

Comment l’attaque a réellement fonctionné

Des processus d’enrichissement back-end de confiance se sont exécutés — ceux conçus pour corréler, analyser et préparer les données d’événements pour les tableaux de bord et les alertes. Ces processus disposent de privilèges système car ils doivent accéder à presque toutes les données. Ils lisent depuis plusieurs sources et réécrivent les informations enrichies dans la base de données. Ils ne sont pas conçus pour servir des données aux utilisateurs. Ils ne sont pas soumis à la RBAC au niveau utilisateur.

Lorsque le processus d’enrichissement a analysé l’événement de l’attaquant, il a rencontré le prompt IA caché et l’a exécuté. Le composant IA — opérant dans le contexte privilégié du processus back-end — a généré un tableau de bord non sollicité, intégré des données sensibles (indicateurs financiers, télémétrie d’infrastructure, dossiers clients) dans des balises d’image, et rendu ces images accessibles depuis l’extérieur.

Les chercheurs de Noma ont découvert que le mot-clé « INTENT » suffisait à faire tomber les garde-fous de l’IA. Une autre faille de validation d’URL — des URLs relatives au protocole au format //attacker.com — a trompé les protections côté client, qui ont classé un domaine externe comme interne. Les données sont ainsi sorties sous forme de paramètres d’URL lors du rendu d’une image.

Chaque SIEM, outil DLP et agent endpoint a vu un processus back-end faire ce que font les processus back-end. Rien n’a été déclenché.

Trois schémas d’échec, pas un seul

Le secteur a regroupé GrafanaGhost avec d’autres vulnérabilités IA sous le même récit « l’IA a besoin de meilleurs garde-fous ». Cette simplification est dangereuse. GrafanaGhost — comme toute la série de vulnérabilités IA révélées cette année — met en lumière trois schémas d’échec distincts. Chacun demande une réponse architecturale différente.

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

Des données externes sont entrées dans le système via un canal légitime, puis un composant IA les a traitées sans validation. Dans GrafanaGhost, il s’agissait des paramètres de requête d’URL stockés dans les journaux d’événements. Le processus d’enrichissement back-end a considéré ces données comme internes et fiables.

C’est la même défaillance derrière toutes les grandes failles IA de l’année passée. Le payload d’EchoLeak était un e-mail forgé ingéré comme contexte par Copilot. Celui de GeminiJack était un Google Doc piégé indexé par RAG. Celui de ForcedLeak était un texte caché dans un champ de formulaire Web-to-Lead de 42 000 caractères. À chaque fois, le principe selon lequel toute entrée externe doit être validée avant d’être traitée par un système — principe à la base du contrôle des entrées des applications web et des WAF — n’a pas été appliqué aux données traitées par l’IA.

Le fait qu’une donnée du monde extérieur soit stockée en interne ne la rend pas fiable. Il s’agit d’un problème de validation des entrées en mode zéro trust, qui requiert des solutions au niveau applicatif et architectural IA — et non des contrôles d’accès aux données.

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

Cinq vulnérabilités révélées cette année — EchoLeak, Reprompt, GeminiJack, ForcedLeak, et une attaque supply chain sur l’écosystème de plugins OpenAI — impliquent des systèmes IA opérant pour le compte d’un utilisateur avec un accès implicite large aux données, sans contrôle de politique à chaque opération. L’IA s’authentifiait une fois au niveau de la session, puis accédait à tout ce qu’elle pouvait atteindre.

Un contrôle d’accès à chaque opération — évaluer chaque demande de données par rapport à la politique — aurait limité l’ampleur des dégâts dans chacun de ces cas. C’est là que la RBAC, l’ABAC, l’isolation des identifiants et les journaux d’audit s’appliquent directement.

GrafanaGhost ne relève pas de ce schéma. L’attaque a opéré via des processus back-end au niveau système, pas via des sessions utilisateur. Grafana applique la RBAC à l’accès aux données côté utilisateur, mais elle n’a jamais été sollicitée. Appliquer les contrôles du schéma 2 à GrafanaGhost revient à traiter la mauvaise faille.

Le rapport prévisionnel 2026 de Kiteworks sur la sécurité des données et les risques de conformité a mis en évidence un écart de 15 à 20 points entre les contrôles de gouvernance et ceux de confinement. Le manque de contrôle opérationnel est réel et urgent — pour les cinq vulnérabilités concernées.

Schéma 3 : Échec du cloisonnement des processus et du périmètre fonctionnel

Le processus d’enrichissement back-end dans GrafanaGhost nécessitait un large accès en lecture aux données. C’est défendable. Mais il n’avait pas besoin de pouvoir appeler des routines de rendu de tableaux de bord, de génération de balises d’image ou d’effectuer des requêtes sortantes vers des serveurs externes. Ce sont des fonctions de sortie que le processus n’était pas censé utiliser — mais rien ne l’en empêchait.

Il s’agit d’un échec de confinement. Le principe du moindre privilège doit s’appliquer au périmètre fonctionnel — c’est-à-dire aux APIs, routines de rendu et canaux de sortie qu’un processus peut invoquer — et pas seulement à l’accès aux données. Un processus d’enrichissement de données qui lit et écrit ne devrait pas pouvoir invoquer des routines qui communiquent avec l’extérieur.

L’attaque supply chain sur les plugins OpenAI relève aussi du schéma 3 : les identifiants d’agent étaient accessibles à du code plugin compromis, car les jetons d’authentification n’étaient pas stockés hors du contexte accessible à l’IA. Six mois d’accès dans 47 entreprises, faute d’isolation des identifiants.

L’effondrement des garde-fous au niveau du modèle — La troisième couche, pas la première

Grafana avait mis en place des défenses contre l’injection de prompts. Un simple mot-clé a suffi à les contourner. Cela rejoint les recherches plus larges — chaque grand LLM a été « jailbreaké » avec un taux de réussite quasi parfait. L’étude Agents of Chaos de février 2026 a documenté des agents IA détruisant des infrastructures et divulguant des informations personnelles identifiables dans des environnements réels.

Les garde-fous au niveau du modèle sont une couche de défense utile. Ils ne remplacent pas la validation des entrées (schéma 1), le contrôle d’accès opérationnel (schéma 2) ou le cloisonnement des processus (schéma 3). Même si les garde-fous avaient tenu, l’architecture sous-jacente de GrafanaGhost — une entrée non fiable atteignant un processus privilégié doté d’un périmètre fonctionnel trop large — restait défaillante.

Le rôle de Kiteworks — et ses limites

Il est essentiel de bien comprendre ce qu’enseigne GrafanaGhost et quels contrôles répondent à quels schémas.

Kiteworks propose une couche de données gouvernée avec enforcement des politiques RBAC et ABAC, authentification OAuth 2.0 avec identifiants stockés dans le trousseau système, limitation du débit et journaux d’audit infalsifiables transmis au SIEM. Pour les systèmes IA qui sollicitent des données via Kiteworks — que ce soit via son Secure MCP Server ou son AI Data Gateway — chaque requête est authentifiée, autorisée et journalisée indépendamment du modèle IA.

Ces contrôles répondent au schéma 2 : accès aux données par l’IA pour le compte d’un utilisateur. Pour les cinq vulnérabilités où un système IA disposait d’un accès implicite large sans contrôle opérationnel — EchoLeak, Reprompt, GeminiJack, ForcedLeak, l’attaque plugin OpenAI — l’ABAC opérationnel, l’isolation des identifiants et les journaux d’audit réduisent directement l’ampleur des dégâts et permettent la détection.

GrafanaGhost relève du schéma 1 et du schéma 3. L’attaque a opéré via des processus back-end au niveau système, et non via des requêtes IA côté utilisateur. Les contrôles d’accès aux données — y compris ceux de Kiteworks — répondent à la question de l’accès aux données. Ils ne traitent pas la défaillance de validation des entrées (données d’événements non fiables traitées sans validation) ni l’échec du cloisonnement fonctionnel (le processus d’enrichissement disposant de capacités de sortie qu’il n’aurait jamais dû avoir).

La contribution de Kiteworks à la leçon GrafanaGhost, c’est le principe d’indépendance : des contrôles de sécurité qui opèrent en dehors du modèle IA, hors de son contexte, et indépendamment des instructions reçues par l’IA. Étendre ce principe à la frontière de confiance des entrées et au cloisonnement fonctionnel des processus, c’est tout l’enjeu architectural défini par GrafanaGhost.

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

Pour le schéma 1 (confiance dans les entrées) : auditez toutes les sources de données traitées par l’IA — journaux d’événements, e-mails, documents partagés, soumissions de formulaires, réponses d’API. Si une entrée externe alimente un système où un composant IA la traite, considérez cette entrée comme potentiellement hostile. Appliquez la même rigueur de validation aux données traitées par l’IA qu’aux entrées utilisateur côté web.

Pour le schéma 2 (périmètre d’accès aux données) : imposez une authentification et une ABAC opérationnelles pour chaque requête de données IA. Stockez les identifiants hors du contexte IA. Produisez des journaux d’audit infalsifiables avec attribution complète, transmis à votre SIEM.

Pour le schéma 3 (cloisonnement des processus) : limitez les processus IA back-end aux seules fonctions dont ils ont besoin. Un accès large en lecture peut être nécessaire. La capacité à rendre du contenu, générer des requêtes sortantes ou créer des tableaux de bord côté utilisateur ne l’est pas. Contraignez ce que les processus peuvent faire, pas seulement les données auxquelles ils peuvent accéder.

Pour les trois : testez vos intégrations IA en conditions réelles (red team). GrafanaGhost a été découvert par des chercheurs, pas par des défenseurs. Testez l’injection de prompts via les données d’événements, les entrées de logs et les métadonnées — pas seulement via les canaux côté utilisateur.

GrafanaGhost est corrigé. Les trois leçons architecturales — valider toute entrée non fiable avant traitement par l’IA, appliquer une politique d’accès aux données à chaque opération, et cloisonner les processus à leur périmètre fonctionnel prévu — ne le sont pas.