L’injection indirecte de prompts devient réalité : pourquoi les garde-fous ne suffisent pas
Points clés à retenir
- L’injection indirecte de prompts est désormais une réalité. Les attaquants dissimulent des instructions dans des pages web, documents et e-mails que les agents IA en production lisent et exécutent, permettant l’exfiltration de données sans phishing ni malware.
- Les outils traditionnels passent à côté de ces attaques. SIEM, DLP et la surveillance des endpoints ne détectent rien d’anormal, car l’IA agit comme prévu tout en suivant les instructions de l’attaquant.
- Les garde-fous au niveau du modèle ne sont pas de la sécurité. Les prompts système et les filtres de sécurité se contournent facilement, des recherches montrant des taux de réussite de jailbreak et d’injection allant jusqu’à 100 % sur les principaux LLMs.
- La gouvernance au niveau des données devient indispensable. Il faut appliquer des contrôles d’accès authentifiés, basés sur des règles, et une journalisation infalsifiable au niveau des données pour répondre aux exigences d’audit et de conformité.
Des chercheurs de Google et Forcepoint ont documenté des attaques d’injection indirecte de prompts ciblant des systèmes IA en production. Les attaquants cachent des instructions dans des pages web, documents et e-mails. Les agents IA qui consultent, résument ou traitent ce contenu lisent ces instructions et les exécutent. Résultat : exfiltration de données, divulgation d’identifiants et requêtes sortantes vers des serveurs contrôlés par l’attaquant — tout cela initié par l’IA elle-même.
Il n’y a aucun lien de phishing à cliquer. Aucun binaire malveillant à déclencher. Aucun login anormal à signaler. L’agent fait ce pour quoi il a été conçu — lire du contenu et agir — et le contenu fait ce que l’attaquant a prévu. Tous les outils de sécurité traditionnels ne détectent rien. À ce moment-là, un risque qui était théorique depuis 2023 devient un problème opérationnel au niveau du conseil d’administration.
5 points clés à retenir
1. L’injection indirecte de prompts n’est plus théorique.
Des chercheurs de Google et Forcepoint ont documenté des attaques réelles où des agents IA sont manipulés via des instructions cachées dans des contenus web, documents et e-mails — déclenchant l’exfiltration de données sans phishing, malware ni intervention humaine. GrafanaGhost, ForcedLeak (Salesforce Agentforce), GeminiJack (Google Gemini) et DockerDash suivent le même schéma. L’écart entre laboratoire et environnement de production a disparu.
2. Les outils de sécurité traditionnels ne voient pas ces attaques.
Quand un agent IA lit les instructions de l’attaquant et agit via ses propres canaux légitimes, SIEM, DLP et la surveillance des endpoints ne détectent rien d’anormal. L’exfiltration ressemble à un comportement IA classique, car du point de vue de la sécurité, l’IA agit comme prévu. Le modèle mental du défenseur — selon lequel l’exfiltration nécessite un endpoint malveillant — ne s’applique plus quand l’IA devient l’outil d’exfiltration.
3. Les garde-fous au niveau du modèle sont des réglages, pas de la sécurité.
On peut outrepasser les prompts système. Les filtres de sécurité se contournent. Des recherches publiées à NeurIPS montrent des taux de jailbreak proches de 100 % sur les principaux LLMs. Le benchmark InjecAgent a révélé que les agents GPT-4 sont vulnérables à l’injection indirecte de prompts dans 24 % des cas en configuration de base — les attaques avancées font grimper ce taux à 47 %. Les contrôles au niveau du modèle sont des paramètres de configuration qui ne suffisent pas pour un audit.
4. Le problème d’audit devient urgent.
Un auditeur HIPAA, CMMC, PCI ou SOX n’acceptera pas « le modèle a reçu l’instruction de ne pas faire » comme preuve de contrôle d’accès. Les auditeurs valident les décisions d’application, pas la configuration. La première fois qu’un régulateur exige une preuve qu’un agent IA a été empêché d’accéder à un jeu de données, il faut fournir une décision d’application consignée, liée à une règle et à un autorisateur humain — pas un prompt système.
5. La correction architecturale passe par la gouvernance au niveau des données.
Il faut déplacer l’application des contrôles hors du modèle et vers la couche données. Authentifiez chaque requête IA, évaluez-la en temps réel selon des contrôles d’accès basés sur des attributs, et journalisez-la avec attribution complète avant tout retour de données. Ce mécanisme reste efficace même si le modèle est compromis, si le prompt est manipulé ou si un nouveau jailbreak apparaît. L’agent ne peut pas exfiltrer des données qu’il n’a jamais été autorisé à lire.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Pourquoi GrafanaGhost était un avertissement, pas une exception
La divulgation de GrafanaGhost par Noma Security en avril 2026 a mis en lumière une vulnérabilité zero-click qui a transformé l’assistant IA de Grafana en canal d’exfiltration silencieux. Les chercheurs ont placé des instructions dans les paramètres d’URL, qui se sont retrouvées dans les logs de Grafana. L’IA a traité ces logs, suivi les instructions et envoyé des métriques financières, de la télémétrie d’infrastructure et des données clients vers un serveur contrôlé par l’attaquant en les intégrant dans des requêtes de rendu d’image. Un simple mot-clé a suffi à contourner les filtres de sécurité du modèle.
GrafanaGhost est corrigé. Mais la classe d’attaque ne l’est pas. ForcedLeak (Salesforce Agentforce), GeminiJack (Google Gemini) et DockerDash ont tous suivi le même scénario : une fonctionnalité IA ajoutée à une plateforme existante, du contenu non fiable transmis au modèle, le modèle exécutant les instructions de l’attaquant, et des outils de sécurité aveugles. Toute fonctionnalité IA ajoutée à un outil d’entreprise ces 18 derniers mois est un potentiel GrafanaGhost en attente d’être découvert — plateformes d’observabilité, systèmes de tickets, CRM, éditeurs de code, suites collaboratives, automatisation marketing.
Ce que la littérature scientifique tente de nous dire
La recherche académique est unanime depuis 2023. Le papier NeurIPS de Wei, Haghtalab et Steinhardt Jailbroken: How Does LLM Safety Training Fail? montre que pour tout prompt malveillant donné, au moins un jailbreak testé réussit quasiment 100 % du temps. L’équipe de la CMU et du Center for AI Safety, dans Universal and Transferable Adversarial Attacks, a démontré un taux de réussite de 88 % sur Vicuna-7B et 87,9 % sur GPT-3.5, avec un transfert fiable entre architectures. La conclusion structurelle : la montée en puissance seule ne résout pas ces failles. L’entraînement défensif ne suffit pas.
Les résultats spécifiques aux agents sont encore pires. Le benchmark InjecAgent a montré que les agents GPT-4 utilisant le framework ReAct sont vulnérables à l’injection indirecte de prompts dans 24 % des cas de base — les attaques avancées font grimper ce taux à 47 %. Le benchmark AgentDojo, utilisé par les AI Safety Institutes américains et britanniques, a révélé que les défenses qui réduisent le taux de réussite des attaques dégradent aussi fortement l’utilité du modèle. Le compromis sécurité-utilité est fondamental : des défenses efficaces rendent les agents inutilisables, et préserver l’utilité laisse la surface d’attaque ouverte. Ce qui a changé en avril 2026, c’est que l’écart entre laboratoire et production a disparu.
Pourquoi « Nous avons des garde-fous » n’est plus une défense
La plupart des entreprises qui encadrent aujourd’hui leurs agents IA s’appuient sur trois éléments : des prompts système pour dicter le comportement du modèle, des filtres de sécurité pour bloquer les sorties dangereuses, et une revue humaine pour les actions à risque. Aucun de ces éléments n’est un contrôle de sécurité au sens strict. Ce sont des réglages de configuration.
Le rapport prévisionnel Kiteworks 2026, basé sur une enquête auprès de 225 organisations, révèle que 41 % à 44 % n’ont pas mis en place de contrôles de gouvernance de base comme la supervision humaine, le monitoring ou la minimisation des données pour leurs agents IA. La situation est pire pour le confinement : 55 % à 63 % n’ont ni restriction d’usage, ni kill switch, ni isolation réseau. Les organisations investissent dans la surveillance des agents IA, mais pas dans leur blocage.
Il existe un problème plus profond : les approches basées sur les garde-fous du modèle ne suffisent pas pour un audit. Un auditeur HIPAA, CMMC, PCI ou SOX n’acceptera pas « le modèle a reçu l’instruction de ne pas accéder à ces données » comme preuve de contrôle d’accès. Les auditeurs valident l’application des règles, pas la configuration. La première fois qu’un régulateur demande la preuve qu’un agent IA a été empêché d’accéder à un jeu de données, il faut fournir une décision d’application consignée — pas un prompt système.
La correction architecturale : déplacer l’application des contrôles vers la couche données
Cessez de gouverner le comportement de l’IA au niveau du modèle et commencez à contrôler l’accès de l’IA au niveau des données. Chaque requête IA — qu’elle vienne d’un assistant interactif, d’un pipeline RAG ou d’un agent autonome — doit être authentifiée, évaluée en temps réel selon une politique d’accès basée sur des attributs, et journalisée avec attribution complète avant tout retour de données. La décision d’application se situe entre l’agent et la donnée, pas dans le modèle.
La gouvernance au niveau des données présente quatre atouts que les garde-fous au niveau du modèle ne peuvent offrir :
Identité authentifiée. Chaque identité d’agent est liée cryptographiquement à l’auteur humain ayant délégué le workflow, sans que les identifiants ne soient jamais exposés au contexte du modèle. La chaîne de délégation est conservée dans l’audit — ce qui limite directement l’exfiltration de secrets par injection de prompt.
Accès régi par des règles. L’autorisation évalue l’identité de l’agent, la classification de la donnée et le contexte de la requête à chaque opération, et non seulement au début de la session. Les contrôles d’accès basés sur des attributs gèrent la logique multidimensionnelle que les approches basées sur les rôles ne peuvent pas encoder.
Chiffrement validé. Les données au repos et en transit sont protégées par des modules cryptographiques certifiés FIPS 140-3 — et non par un simple TLS. Cela répond aux exigences des secteurs réglementés pour l’accès aux données, qu’il soit humain ou IA.
Journalisation d’audit infalsifiable. Chaque interaction IA génère une entrée d’audit normalisée, transmise en temps réel au SIEM. Quand un régulateur demande une preuve, il obtient un reporting, pas une enquête. L’agent hérite des autorisations de l’utilisateur et ne peut pas les dépasser, peu importe les instructions reçues via du contenu compromis.
Comment Kiteworks met en œuvre la gouvernance au niveau des données pour les agents IA
Le serveur Kiteworks Secure MCP et la passerelle de données IA s’intercalent entre les systèmes IA et les données de l’entreprise, appliquant la gouvernance au niveau des données, quel que soit le modèle, le framework ou la couche d’orchestration à l’origine de la requête.
Le serveur Secure MCP permet aux applications LLM comme Claude ou Microsoft Copilot d’interagir avec les données de l’entreprise via le protocole standard Model Context Protocol. Chaque opération est régie par une authentification OAuth 2.0, avec des identifiants stockés dans les trousseaux système et jamais exposés au contexte LLM — une protection directe contre l’exfiltration de secrets par injection de prompt. Les politiques ABAC évaluent chaque opération sur fichier, dossier ou formulaire en temps réel. Le rate limiting empêche l’extraction massive. La validation TLS, le blocage des traversées de chemin et l’audit intégré fournissent les preuves exigées par les régulateurs.
La passerelle de données IA propose un équivalent programmatique pour les pipelines RAG et les workflows automatisés. Chaque requête de récupération est authentifiée, autorisée selon une politique ABAC, et journalisée avant tout retour de contenu — sur n’importe quelle plateforme IA, sans dépendance fournisseur. Les mêmes contrôles de gouvernance s’appliquent aux utilisateurs humains, comptes de service et agents IA.
Le Réseau de données privé Kiteworks étend cette architecture à tous les canaux d’échange de données — messagerie électronique, partage de fichiers, SFTP, MFT, formulaires web, API — sous un moteur de règles unique et un journal d’audit consolidé. Avec 51 % des organisations exploitant des agents IA en production et 55 % à 63 % dépourvues de contrôles de confinement selon le rapport prévisionnel Kiteworks 2026, l’écart entre la rapidité de déploiement et la maturité de la gouvernance IA représente le plus grand risque non maîtrisé du portefeuille IA d’entreprise. La gouvernance au niveau des données permet de le combler.
Ce que les organisations doivent faire avant la prochaine divulgation
Première étape : recensez toutes les intégrations IA qui accèdent à des données sensibles. Tout outil doté d’une fonctionnalité IA lisant des contenus non fiables et accédant à des données réglementées doit être inventorié. Commencez par les plateformes ayant ajouté des fonctions IA ces 18 derniers mois — elles sont les plus susceptibles d’avoir été intégrées sans analyse de risques.
Deuxième étape : cessez de considérer les garde-fous au niveau du modèle comme preuve de conformité. Selon le NIST AI Risk Management Framework et l’OWASP Top 10 for LLM Applications, les contrôles au niveau du modèle sont nécessaires mais insuffisants. Exigez une application des règles au niveau des données pour chaque système IA traitant des données réglementées.
Troisième étape : comblez le déficit de confinement. La restriction d’usage garantit qu’un agent autorisé pour une tâche ne peut pas en exécuter une autre. Les kill switches permettent aux équipes de sécurité de désactiver immédiatement un agent défaillant. L’isolation réseau limite les destinations possibles des données. Le rapport prévisionnel Kiteworks 2026 révèle que 55 % à 63 % des organisations n’ont pas ces contrôles de base — chacun peut être mis en place en un trimestre et élimine une classe de risques.
Quatrième étape : exigez une identité cryptographique pour chaque agent IA. Les comptes de service statiques et les tokens OAuth partagés ne suffisent pas pour des acteurs autonomes. Chaque agent doit disposer d’une identité vérifiée, liée cryptographiquement à l’auteur humain ayant délégué le workflow. La traçabilité exigée par HIPAA (personnes autorisées) et CMMC (contrôles d’accès) ne peut s’arrêter à un simple nom de compte de service.
Cinquième étape : testez vos intégrations IA face à l’injection indirecte de prompts en utilisant les schémas connus de l’OWASP Top 10 for LLM Applications et du benchmark AgentDojo. GrafanaGhost a été découvert par des chercheurs, pas par l’équipe sécurité de Grafana. Si votre organisation ne teste pas activement ses intégrations IA pour ce type de vulnérabilité, vous laissez la découverte au prochain venu.
Le rythme des divulgations s’accélère. Que la protection de vos données réglementées dépende du bon comportement du modèle — ou de contrôles qui restent efficaces même en cas de défaillance — c’est la décision architecturale la plus lourde de conséquences pour votre programme de sécurité en 2026.
Pour en savoir plus sur la gouvernance des données IA et la protection de vos données les plus sensibles, réservez votre démo personnalisée sans attendre.
Foire aux questions
L’injection indirecte de prompts permet aux attaquants de dissimuler des instructions dans des pages web, des PDF ou des e-mails. Lorsque vos agents lisent ce contenu, ils peuvent accéder à des portefeuilles clients, récupérer des données de comptes ou envoyer des dossiers vers des destinations contrôlées par l’attaquant — sans malware ni connexion anormale pour déclencher une alerte. Le rapport prévisionnel Kiteworks 2026 révèle que 55 % à 63 % des organisations n’ont pas de contrôles d’accès ni de confinement pour les agents IA, exposant directement les données réglementées SEC et FINRA à ce type d’attaque.
L’entraînement à la sécurité n’est pas un contrôle effectif. Les recherches NeurIPS montrent des taux de réussite de jailbreak proches de 100 % sur les principaux LLMs, et un simple mot-clé a suffi à contourner les défenses de Grafana dans la divulgation GrafanaGhost. HIPAA exige des décisions d’application consignées et liées aux personnes autorisées — pas une configuration. Un régulateur n’acceptera pas « le modèle a reçu l’instruction de ne pas faire » comme substitut à une décision d’accès consignée.
Un RAG conforme exige une authentification à chaque requête, une évaluation de la politique ABAC selon les autorisations de l’utilisateur authentifié, un chiffrement validé FIPS 140-3 et une journalisation d’audit infalsifiable. La passerelle de données IA de Kiteworks fournit cette architecture — chaque requête IA est gouvernée au niveau des données, indépendamment du modèle, avec attribution complète transmise en temps réel au SIEM.
Les familles de contrôles d’accès CMMC Niveau 2 exigent une autorisation appliquée et un audit pour tout accès aux CUI — y compris par des agents IA. Le rapport prévisionnel Kiteworks 2026 révèle que seuls 46 % des organisations du secteur DIB se considèrent prêtes pour CMMC. La gouvernance au niveau des données avec application ABAC, chiffrement FIPS 140-3 et logs infalsifiables répond simultanément aux familles de contrôles AC, AU et IA pour les accès humains et IA.
Commencez par l’OWASP Top 10 for LLM Applications et le benchmark AgentDojo, tous deux publics. Recensez chaque fonctionnalité IA ajoutée à vos outils ces 18 derniers mois. Si une fonctionnalité IA lit des entrées non fiables, accède à des données sensibles et initie des requêtes sortantes, elle nécessite une gouvernance au niveau des données. Le serveur Secure MCP et la passerelle de données IA fournissent l’architecture d’application — commencez par l’inventaire.
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
L’écart de 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 savoir si vous avez une politique IA. Ils veulent la preuve de son efficacité.
Foire aux questions
Les attaquants dissimulent des instructions dans des pages web, documents et e-mails. Les agents IA qui consultent, résument ou traitent ce contenu lisent ces instructions et les exécutent, entraînant exfiltration de données, divulgation d’identifiants et requêtes sortantes vers des serveurs contrôlés par l’attaquant, sans lien de phishing, malware ni connexion anormale.
Quand un agent IA lit les instructions de l’attaquant et agit via ses canaux légitimes, l’exfiltration ressemble à un comportement IA classique. Du point de vue de la sécurité, l’IA agit comme prévu, donc aucune activité anormale n’est signalée.
Les prompts système peuvent être contournés et les filtres de sécurité dépassés, des recherches évaluées par des pairs montrant des taux de réussite de jailbreak proches de 100 % sur les principaux LLMs. Ces contrôles sont des réglages de configuration, pas des mesures de sécurité opposables lors d’un audit pour HIPAA, CMMC, PCI ou SOX.
Déplacez l’application des contrôles vers la couche données en authentifiant chaque requête IA, en l’évaluant en temps réel selon des contrôles d’accès basés sur des attributs, et en la journalisant avec attribution complète avant tout retour de données. Cela garantit que l’agent ne peut pas exfiltrer de données qu’il n’a jamais été autorisé à lire, même si le modèle est compromis.