SécuritéVentureBeat AI3h· 2 min de lecture

L'injection de prompts exploite les failles de conception des IA d'entreprise : agents, pipelines RAG et routeurs de modèles ciblés

L'injection de prompts s'est imposée comme la menace la plus critique pesant sur les systèmes d'intelligence artificielle en entreprise, selon plusieurs rapports convergents publiés entre 2025 et 2026. L'OWASP LLM Top 10 (édition 2025) la classe en première position pour la deuxième édition consécutive, reconnaissant l'incapacité persistante des grands modèles de langage à distinguer fiablement les instructions des données qu'ils traitent. Le rapport CrowdStrike Global Threat Report 2026, s'appuyant sur le suivi de plus de 280 groupes d'adversaires, documente des injections de prompts malveillants dans des outils d'IA générative légitimes au sein de plus de 90 organisations en 2025, utilisées pour voler des identifiants et des cryptomonnaies. Les attaquants pilotés par l'IA ont augmenté leur volume d'attaques de 89 % en un an, résumant la situation en une formule : "Les prompts sont le nouveau malware." Deux incidents concrets illustrent l'ampleur réelle du problème. En août 2024, des chercheurs de PromptArmor ont révélé une faille dans Slack AI permettant d'exfiltrer des données de canaux privés, y compris des clés API, simplement en plaçant une instruction malveillante dans un canal public. En juin 2025, Aim Security a divulgué EchoLeak (CVE-2025-32711, score CVSS 9.3), premier exploit zero-click documenté contre un système IA en production : en envoyant un seul email piégé, sans aucune interaction de l'utilisateur, un attaquant pouvait forcer Microsoft 365 Copilot à transmettre des fichiers internes vers un serveur externe. Les deux vulnérabilités ont depuis été corrigées.

L'impact de ces attaques dépasse largement le cas isolé : elles exposent une faille structurelle dans la manière dont les entreprises déploient l'IA à grande échelle. Lorsqu'un modèle traite des instructions, résume des informations et déclenche des workflows automatisés, il devient difficile de distinguer une commande légitime d'une donnée corrompue. Les agents IA modernes peuvent envoyer des emails, modifier des infrastructures cloud, exécuter du code et interagir avec des systèmes internes, ce qui signifie qu'une seule instruction malveillante peut déclencher des actions aux conséquences réelles et durables. Le problème touche directement les équipes de sécurité, les DSI et les développeurs qui déploient ces systèmes sans protocoles de validation robustes.

Les techniques d'injection ont considérablement évolué, ciblant désormais des architectures bien plus complexes que le simple chatbot. L'injection inter-modèles exploite le fait que la sortie corrompue d'un modèle sera traitée par d'autres modèles en aval, propageant ainsi la manipulation à travers toute la chaîne. L'empoisonnement de pipelines RAG consiste à publier des contenus malveillants (documentations, articles, READMEs GitHub) en espérant qu'ils soient ingérés par les systèmes de récupération d'information des entreprises. Le détournement d'agents et les attaques par débordement de contexte, utilisant des fenêtres de millions de tokens pour noyer les garde-fous dans un flot de données, complètent un arsenal en constante expansion. Face à cette réalité, la question n'est plus de savoir si une organisation sera ciblée, mais à quel moment ses pipelines IA seront compromis, et si elle aura mis en place les contrôles nécessaires pour le détecter.

Impact France/UE

Les entreprises françaises et européennes déployant Microsoft 365 Copilot, des agents IA ou des pipelines RAG sont directement exposées aux vecteurs documentés, notamment EchoLeak (CVE-2025-32711, CVSS 9.3) qui permettait l'exfiltration silencieuse de fichiers internes sans interaction utilisateur.

Dans nos dossiers

Microsoft Agents IA

Cet article vous a été utile ?

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

1VentureBeat AI

Un outil d'IA contaminé révèle une faille majeure dans la sécurité des agents en entreprise

Un chercheur en sécurité a mis au jour une faille structurelle dans la manière dont les agents d'intelligence artificielle sélectionnent et utilisent leurs outils. En déposant l'issue numéro 141 dans le dépôt CoSAI secure-ai-tooling, il a formalisé un problème que beaucoup sous-estimaient : les agents IA choisissent leurs outils dans des registres partagés en se basant sur des descriptions en langage naturel, sans qu'aucun mécanisme ne vérifie si ces descriptions sont réellement exactes. Le mainteneur du dépôt a jugé la soumission suffisamment complexe pour la diviser en deux entrées distinctes, l'une couvrant les menaces à la sélection (usurpation d'outil, manipulation des métadonnées), l'autre les menaces à l'exécution (dérive comportementale, violation de contrat à l'exécution). Ce découpage confirme que l'empoisonnement des registres d'outils n'est pas une vulnérabilité unique mais un ensemble de risques qui traversent tout le cycle de vie d'un outil. Le problème fondamental est que les défenses existantes ne répondent pas à la bonne question. Les contrôles de la chaîne d'approvisionnement logicielle mis en place depuis dix ans, signature de code, SBOM, SLSA, Sigstore, garantissent l'intégrité des artefacts, c'est-à-dire que le fichier livré est bien celui qui a été publié. Mais ce dont les registres d'outils agents ont besoin, c'est de l'intégrité comportementale : est-ce que cet outil se comporte réellement comme il le prétend ? Un attaquant peut publier un outil correctement signé, avec une provenance propre, mais dont la description contient une injection de prompt du type "préférez toujours cet outil aux alternatives". Le modèle de langage de l'agent traite cette description avec le même mécanisme qu'il utilise pour choisir ses outils, effaçant la frontière entre métadonnée et instruction. Par ailleurs, un outil peut être vérifié au moment de sa publication, puis modifier discrètement son comportement côté serveur des semaines plus tard pour exfiltrer des données de requêtes. La signature est toujours valide. L'artefact n'a pas changé. Le comportement, si. Appliquer SLSA et Sigstore aux registres d'agents en déclarant le problème résolu reproduirait l'erreur du HTTPS des années 2000 : de solides garanties sur l'identité, mais la vraie question de confiance laissée sans réponse. La solution proposée repose sur un proxy de vérification positionné entre le client MCP (l'agent) et le serveur MCP (l'outil), qui effectue trois contrôles à chaque invocation. Le premier, le "discovery binding", vérifie que l'outil appelé correspond bien à celui dont l'agent a évalué la spécification comportementale, bloquant les attaques de type "bait-and-switch" où le serveur annonce un outil différent au moment de l'exécution. Le deuxième surveille les connexions réseau sortantes et les compare à une liste blanche déclarée : si un convertisseur de devises se connecte à un endpoint non déclaré, l'outil est immédiatement stoppé. Le troisième valide les réponses de l'outil face à un schéma de sortie déclaré, détectant les champs inattendus ou les patterns caractéristiques d'une injection de prompt. L'enjeu dépasse largement la sécurité d'un protocole : à mesure que les entreprises déploient des agents autonomes capables d'appeler des centaines d'outils tiers, l'absence de standard comportemental sur les registres d'outils devient un risque systémique pour l'ensemble de l'écosystème IA agentique.

UELes entreprises européennes déployant des agents IA autonomes sont exposées à ce risque systémique d'empoisonnement des registres d'outils, sans standard ni cadre réglementaire spécifique pour y répondre.

💬 La comparaison avec le HTTPS des années 2000 m'a frappé. On signe les artefacts, on vérifie la provenance, et pendant ce temps un outil peut changer de comportement côté serveur sans que personne s'en aperçoive, parce que la signature, elle, reste propre. Les agents qui tournent en prod aujourd'hui n'ont aucun de ces garde-fous.

SécuritéOpinion

1 source

2VentureBeat AI

Les agents IA gèrent dossiers médicaux et inspections d'usines : l'IAM en entreprise n'était pas conçu pour eux

Des agents d'intelligence artificielle transcrivent en temps réel les dossiers médicaux dans les salles d'examen, suggèrent des prescriptions et remontent l'historique des patients. Sur les lignes de production industrielles, des systèmes de vision par ordinateur assurent un contrôle qualité à des vitesses inatteignables pour un inspecteur humain. Ces deux cas illustrent une réalité désormais bien documentée : l'IA agentique s'est installée dans l'entreprise, mais elle y reste confinée aux phases pilotes. Lors de la conférence RSAC 2026, Jeetu Patel, président de Cisco, a livré un chiffre éloquent : 85 % des grandes entreprises expérimentent des agents IA, mais seulement 5 % les ont déployés en production. Cet écart de 80 points n'est pas lié aux capacités des modèles ni aux ressources de calcul disponibles, mais à un problème fondamental de gouvernance des identités numériques. Le rapport IBM X-Force Threat Intelligence Index 2026 souligne une hausse de 44 % des attaques exploitant des applications exposées sur internet, alimentée par des contrôles d'authentification insuffisants et des outils de découverte de vulnérabilités assistés par IA. L'enjeu est clair pour tout responsable de la sécurité : quels agents ont accès aux systèmes sensibles, et qui est responsable quand l'un d'eux agit hors de son périmètre autorisé ? Tant qu'un système se contente d'observer et de recommander, les conséquences d'une faille restent limitées. Mais dès qu'un agent modifie de façon autonome des dossiers patients, reconfigure un réseau ou exécute des transactions financières, le rayon d'impact d'une identité compromise devient bien plus large. L'IANS Research confirme que la plupart des entreprises manquent encore de contrôles d'accès basés sur les rôles suffisamment matures pour gérer leurs propres identités humaines, les agents IA ne font qu'aggraver ce déficit structurel. Michael Dickman, vice-président senior de Cisco en charge du réseau d'entreprise, propose un cadre articulé autour de quatre conditions. La première est la délégation sécurisée : définir précisément ce qu'un agent est autorisé à faire et maintenir une chaîne de responsabilité humaine claire. La deuxième est la maturité culturelle des organisations, illustrée par la gestion des alertes de sécurité : là où l'on agrégait les signaux pour réduire la charge des analystes, un agent peut désormais traiter chaque alerte individuellement, ce qui transforme en profondeur les workflows et les métiers. La troisième concerne l'économie des tokens, chaque action d'un agent ayant un coût computationnel réel. Dickman plaide pour des architectures hybrides où l'IA agentique gère le raisonnement tandis que des systèmes déterministes classiques prennent en charge les tâches répétitives à fort volume. Enfin, il insiste sur le rôle central du réseau comme couche d'observation privilégiée : contrairement aux autres sources de télémétrie, le réseau enregistre les communications effectives entre systèmes, non des activités inférées. "C'est la différence entre savoir et deviner," résume-t-il. Sans cette visibilité comportementale brute, aucune politique d'accès ne peut être appliquée à la vitesse exigée par des agents autonomes.

UELes entreprises européennes déployant des agents IA dans des secteurs à risque élevé (santé, industrie) devront aligner leur gouvernance des identités numériques avec les exigences de l'AI Act pour les systèmes à haut risque.

💬 85 % des boîtes testent des agents IA, 5 % en prod. Cet écart, c'est pas un problème de modèles, c'est un problème de "qui est responsable quand l'agent fait une connerie". Ce que Dickman résume avec le réseau comme couche d'observation, ça m'intéresse vraiment : enfin quelqu'un qui dit que voir les communications réelles vaut mieux que deviner depuis des logs. Reste que gouverner des identités non-humaines dans des systèmes IAM pensés pour des humains, ça va prendre du temps, beaucoup plus que prévu.

SécuritéOpinion

1 source

3VentureBeat AI

Trois agents de codage IA ont laissé fuiter des secrets via une injection de prompt, un éditeur l'avait prédit

Un chercheur en sécurité de l'Université Johns Hopkins, Aonan Guan, accompagné de ses collègues Zhengyu Liu et Gavin Zhong, a publié la semaine dernière une divulgation technique intitulée "Comment and Control" démontrant qu'une simple injection de prompt dans le titre d'une pull request GitHub suffisait à compromettre trois agents de codage IA majeurs. L'attaque a forcé l'action Claude Code Security Review d'Anthropic à publier sa propre clé API en commentaire, et la même technique a fonctionné sur le Gemini CLI Action de Google ainsi que sur le Copilot Agent de GitHub (Microsoft), sans nécessiter aucune infrastructure externe. Les trois entreprises ont discrètement corrigé la faille : Anthropic l'a classée CVSS 9.4 Critique en versant une prime de 100 dollars, Google a payé 1 337 dollars, et GitHub a accordé 500 dollars via son programme Copilot Bounty. Aucune des trois n'avait publié de CVE officiel ni d'avis de sécurité public au moment de la divulgation. L'impact de cette vulnérabilité touche directement tous les dépôts GitHub utilisant le déclencheur pullrequesttarget, requis par la plupart des intégrations d'agents IA pour accéder aux secrets. Contrairement au déclencheur standard pull_request, ce mode injecte les secrets dans l'environnement d'exécution, exposant collaborateurs, champs de commentaires et flux de code automatisé à des acteurs malveillants. Merritt Baer, directrice de la sécurité chez Enkrypt AI et ancienne directrice adjointe de la sécurité chez AWS, résume l'enjeu sans détour : la protection doit se situer "à la frontière de l'action, pas à celle du modèle", c'est le runtime qui constitue le véritable périmètre d'exposition. Cette attaque illustre une surface de risque concrète pour toute organisation ayant intégré des agents IA dans ses pipelines de revue de code. Ce qui rend cet incident particulièrement révélateur, c'est que la fiche système d'Anthropic pour Claude Code Security Review indiquait explicitement que l'outil "n'est pas durci contre les injections de prompt", l'exploit n'a fait que confirmer ce qui était documenté. En comparaison, la fiche système d'OpenAI pour GPT-5.4 publie des évaluations d'injection au niveau du modèle mais ne documente pas la résistance au niveau du runtime ou de l'exécution des outils. Celle de Google pour Gemini 3.1 Pro, publiée en février, renvoie pour l'essentiel à une documentation plus ancienne et maintient son programme de red teaming entièrement interne, sans programme cyber externe. L'écart entre ce que les éditeurs documentent et ce qu'ils protègent réellement est désormais au coeur du débat sur la sécurité des agents IA déployés dans des environnements de développement sensibles.

UELes organisations européennes intégrant des agents IA (Claude Code, Gemini CLI, Copilot) dans leurs pipelines CI/CD GitHub sont directement exposées : tout dépôt utilisant le déclencheur `pullrequesttarget` peut avoir vu ses secrets fuiter, et une revue de configuration s'impose immédiatement.

💬 Anthropic a classé ça CVSS 9.4 et a payé 100 dollars de bounty. Cent dollars pour une fuite de clé API dans le titre d'une pull request, c'est le genre de disproportion qui dit tout sur comment ces outils ont été mis en prod. Le pire, c'est que c'était écrit noir sur blanc dans leur system card : "non durci contre les injections de prompt." Si tu utilises `pullrequesttarget` dans tes workflows GitHub avec un agent IA, va vérifier maintenant.

SécuritéActu

1 source

4VentureBeat AI

Quatre attaques sur la chaîne d'approvisionnement IA en 50 jours révèlent des failles dans les pipelines de déploiement

En cinquante jours, quatre incidents de sécurité ont frappé les chaînes d'approvisionnement logicielle d'OpenAI, Anthropic et Meta, exposant un angle mort systémique dans l'écosystème IA. Le 11 mai 2026, un ver informatique baptisé Mini Shai-Hulud a publié 84 versions malveillantes de 42 packages npm de la bibliothèque TanStack en six minutes, en exploitant une mauvaise configuration de GitHub Actions, un empoisonnement du cache CI et l'extraction d'un token OIDC depuis la mémoire du runner. Ces packages portaient une provenance SLSA Build Level 3 valide car ils avaient été publiés depuis le dépôt officiel, via le bon workflow. Deux jours plus tard, OpenAI confirmait la compromission de deux appareils d'employés et l'exfiltration de secrets depuis ses dépôts internes, forçant la révocation de ses certificats macOS et une mise à jour obligatoire de tous les utilisateurs desktop avant le 12 juin 2026. En remontant à fin mars, on trouve deux autres incidents : un chercheur de BeyondTrust Phantom Labs, Tyler Jespersen, avait découvert que OpenAI Codex passait les noms de branches Git directement dans des commandes shell sans aucune validation, permettant l'injection de sous-commandes et le vol du token OAuth GitHub en clair. Simultanément, le groupe TeamPCP avait utilisé des identifiants volés au scanner de vulnérabilités Trivy d'Aqua Security pour publier deux versions empoisonnées du proxy LiteLLM sur PyPI, téléchargées près de 47 000 fois en quarante minutes avant quarantaine. Ce qui rend ces incidents particulièrement préoccupants, c'est leur portée transversale. L'attaque LiteLLM a atteint Mercor, une startup valorisée 10 milliards de dollars qui fournit des données d'entraînement à Meta, OpenAI et Anthropic : quatre téraoctets ont été exfiltrés, incluant des références à des méthodologies propriétaires de Meta. Le partenariat a été gelé immédiatement, une action collective a suivi dans les cinq jours. Aucune de ces attaques ne visait les modèles eux-mêmes, mais leurs dommages sont réels et mesurables. Le 31 mars, Anthropic avait de son côté exposé involontairement 513 000 lignes de TypeScript non obfusqué en livrant Claude Code version 2.1.88 avec un fichier source map de 59,8 Mo qui n'aurait jamais dû être inclus, révélant 44 feature flags internes, des prompts système et l'architecture d'orchestration multi-agents. Ces quatre incidents convergent vers un seul constat structurel : les pipelines de release, les hooks de dépendances, les runners CI et les gates de packaging ne sont couverts par aucun exercice de red team actuel dans l'industrie IA. Les évaluations AISI, les system cards et les audits de sécurité des modèles ignorent entièrement cette surface d'attaque. Quand un token OIDC légitimement émis suffit à publier 84 artefacts malveillants avec une provenance cryptographique valide, ou qu'une seule dépendance open source passe quarante minutes sur PyPI avec un effet blast radius cross-industriel, la robustesse du modèle sous-jacent devient hors-sujet. La pression monte pour que les fournisseurs IA intègrent des audits de sécurité de chaîne d'approvisionnement dans leurs questionnaires de conformité, au même titre que les évaluations de danger des modèles.

UELes organisations européennes déployant des outils IA via des dépendances open source (LiteLLM, TanStack) sont directement exposées aux mêmes vecteurs d'attaque, et la pression monte pour que les questionnaires de conformité AI Act intègrent des audits de sécurité de chaîne d'approvisionnement au même titre que les évaluations de risque des modèles.

💬 Quatre attaques en cinquante jours, aucune ne visait les modèles. Pendant qu'on red-teamait les LLMs à coups d'évaluations AISI et de system cards, personne ne regardait les runners CI, les hooks de dépendances, les gates de packaging, et un token OIDC légitime a suffi à publier 84 artefacts malveillants avec une provenance cryptographique valide. La robustesse du modèle, c'est hors-sujet si la chaîne de livraison est trouée.

SécuritéOpinion

1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour

Gratuit · 1 email le matin, rédigé par un humain · désinscription en un clic