Data / IA
Copilot Studio piraté : Tenable éclaire la faille structurelle des agents IA !
Par Laurent Delattre, publié le 16 décembre 2025
Le no-code promet des agents qui travaillent pour vous ; il peut aussi leur donner les clés du magasin. Tenable démontre à nouveau qu’un prompt bien tourné, et l’agent IA confond données et consignes puis agit de façon imprévue. La démonstration de Tenable sur Copilot Studio rappelle que la prompt injection est un risque structurel qui exige gouvernance et contrôles à l’exécution. Les outils de défense commencent à apparaître, mais il faudra les implémenter avant de libérer les agents IA en production.
Depuis que les « agents IA » sortent du mode conversationnel pour planifier et agir (navigation web, lecture d’e-mails, exécution d’API, accès à des dépôts Git, etc.), leur surface d’attaque s’élargit brutalement.
Là où un chatbot se contente de produire du texte, un agent est un acteur logiciel : il ingère des contenus non fiables, arbitre ce qui est une instruction ou une donnée, puis déclenche des actions au nom de l’utilisateur. C’est précisément ce chaînage « compréhension → décision → action » qui rend aujourd’hui le détournement des agents IA beaucoup plus simple qu’on ne l’imagine, comme l’ont démontré cette semaine les chercheurs de Tenable.
La fragilité la plus critique, d’ailleurs exploitée par Tenable mais confirmée par plusieurs autres travaux et retours de terrain ces derniers mois, est que la prompt injection (et surtout sa variante “indirecte”) n’est pas un bug marginal : c’est un problème structurel commun aux LLM et aux agents IA.
Le NCSC britannique alerte sur le fait que ces attaques doivent être considérées comme un risque à gérer par conception et exploitation, plutôt qu’un défaut qu’un “produit” viendrait corriger une fois pour toutes et introduit la notion de « confused deputy », un système privilégié manipulé pour servir l’attaquant.
L’injection indirecte : quand le contenu devient la commande
L’attaque indirecte consiste à cacher des instructions dans une source que l’agent va consulter (e-mail, page web, document, ticket, issue GitHub, sources de données…). L’agent, en “groundant” sa réponse avec ce contenu, peut interpréter ces instructions comme prioritaires et exécuter des actions non voulues.
Tout modèle IA exposé à du contenu web non fiable est « intrinsèquement vulnérable » à l’injection indirecte. Autrement dit, il peut interpréter du contenu comme une instruction qui lui est destinée et décider de s’y conformer.
L’exemple le plus célèbre est celui dit de la vulnérabilité EchoLeak (CVE-2025-32711) découverte cette année : une injection “zero-click” dans un email permettait l’exfiltration de données, sans action de la victime, en profitant justement des ponts entre contenus externes et contexte interne dans Microsoft 365 Copilot.
Une expérience agentique beaucoup trop parlante
L’ère de l’IA agentique d’une manière générale, et l’outil no-Code très populaire de Microsoft « Copilot Studio », vendent une promesse simple aux métiers : automatiser des workflows entiers sans écrire une ligne de code, en branchant un “agent IA” sur des sources de connaissance et des connecteurs capables d’agir dans le SI.
Tenable Research vient de rappeler cette semaine, avec une expérimentation menée sur Microsoft Copilot Studio, que cette promesse a un corollaire direct : dès qu’un agent reçoit des droits d’accès et des capacités d’action, il devient une surface d’attaque à part entière. Et, pour l’instant, c’est bien trop souvent une surface d’attaque “invisible” pour les dispositifs de gouvernance traditionnels.
Une expérimentation volontairement banale, donc très crédible
Le scénario choisi par Tenable est précisément celui qu’on retrouve dans beaucoup de POC : un agent de voyage conçu dans Copilot Studio, chargé de gérer des réservations clients de manière automatisée.
L’agent s’appuie sur un fichier SharePoint contenant des données fictives (noms de clients, détails de réservation, informations de paiement simulées) et il dispose d’actions lui permettant de créer, lire et modifier des enregistrements via les actions SharePoint “create item”, “get item” et “update item”.
Autrement dit, rien d’exotique : voilà un agent conversationnel agentique s’appuyant sur une base de “connaissance” et des connecteurs standard. Dans la vie réelle, ce type d’assemblage se retrouve dans des cas d’usage de service client, de support interne, de gestion RH ou d’automatisation de processus métiers, avec des données bien moins “innocentes” que celles d’un lab.
L’agent respecte l’intention… jusqu’à ce qu’un prompt la redéfinisse
L’attaque décrite par Tenable repose sur cette technique désormais classique et évoquée plus haut : l’injection de prompt.
L’intérêt de l’expérience n’est pas dans la « prompt injection » elle-même mais dans ce qu’elle révèle sur l’architecture agentique et sa fragilité « intrinsèque » : l’agent doit interpréter du langage naturel et prendre des décisions d’outillage (quels connecteurs, quelles actions, quels paramètres), ce qui ouvre mécaniquement une brèche entre l’intention du concepteur et le comportement effectif au runtime.
Dans la démonstration, les chercheurs commencent par pousser l’agent à révéler ses capacités (les actions disponibles). Puis ils exploitent deux propriétés très opérationnelles :
D’abord, une ambiguïté fonctionnelle : l’agent avait été conçu pour consulter une réservation à la fois via “get item”, mais Tenable montre qu’en demandant plusieurs identifiants de réservation dans une même requête, l’agent enchaîne plusieurs exécutions de “get item” et renvoie plusieurs dossiers clients, dont des informations de carte bancaire. « Ce pas du hack », insiste Tenable : juste un prompt suffisamment direct pour déclencher un comportement que l’interface no-code vient masquer.
Ensuite, une faiblesse de logique métier et de contrôle d’accès : l’agent avait des droits de modification pour permettre l’édition de réservations, mais ces droits s’appliquaient aussi à un champ critique, le prix. Résultat : un prompt suffit à faire passer une réservation de 1 000 dollars à 0 dollar, c’est-à-dire à transformer un flux conversationnel en fraude “métier”.
Ce n’est pas un détail : on sort ici du paradigme “fuite de données” pour entrer dans celui – encore plus critique – du détournement transactionnel.
Dans un SI modernisé, chaque agent IA est une sorte d’orchestrateur qui lit et écrit dans des systèmes. Le risque, dès 2026, n’est donc plus seulement l’exfiltration, mais la modification non autorisée de référentiels, de commandes, de droits, de paramètres financiers, ou de validations.
Pourquoi cette expérience est représentative
Alors oui, bien sûr, l’expérience de Tenable sort du cadre des bonnes pratiques. Mais elle démontre en réalité le risque inhérent à tous les outils de développements d’IA no-code qui émergent sur le marché et visent à permettre à tous de créer leur propre agent d’automatisation des tâches qui les enquiquinent.
Si la démonstration de Tenable a une force particulière, c’est parce qu’elle met en scène des erreurs “probables”, pas des erreurs “rares”.
Des erreurs que tout utilisateur de tels outils no-code sont susceptibles de probablement reproduire :
D’abord, la confusion entre garde-fous conversationnels et contrôles de sécurité : demander à un agent de “vérifier l’identité” via des instructions en langage naturel n’est pas un véritable contrôle d’autorisation. Il ne se suffit pas à lui-même.
Ensuite, le piège des permissions : pour que l’agent “fasse des choses”, on lui donne des capacités d’écriture, et on découvre ensuite que la granularité (champ, valeur, portée) n’a pas été pensée comme une politique de sécurité. Du coup, les agents IA se retrouvent avec des capacités d’action qui dépassent leurs besoins de départ.
Enfin, et c’est sans doute le point le plus critique pour les DSI, l’effet d’échelle : Copilot Studio et les plateformes similaires mettent la création d’agents à portée de populations non techniques. C’est un accélérateur de productivité, mais aussi un accélérateur de dette de sécurité, car la conception d’un agent devient un acte de “développement applicatif” sans les réflexes d’AppSec, de threat modeling ou de revue de droits.
Les travaux antérieurs de Zenity Labs sur Copilot Studio allaient déjà dans ce sens : ils décrivaient comment une phase de “discovery” permet à un attaquant d’obtenir des détails d’implémentation (sources de connaissance, outils) puis de pousser l’agent à exfiltrer massivement des données. Les chercheurs expliquaient au passage qu’un filtrage par listes noires de prompts ne pouvait être une réponse durable, car les formulations d’injection de prompts sont quasi infinies.
Passer du “prompt safe” au “runtime controlled”
Pour Tenable, la réponse à ce type de risque ne peut pas être uniquement « écrire de meilleures instructions ». Il faut traiter l’agent IA comme un composant applicatif privilégié, avec une gouvernance et des contrôles à l’exécution.
Microsoft documente plusieurs briques de gouvernance et de sécurité dans Copilot Studio : politiques de données dans le Power Platform admin center (pour encadrer connecteurs, actions, sources de connaissance, publication, triggers), audit logs via Purview et intégration possible côté Sentinel, usage de labels de sensibilité pour des sources SharePoint, et possibilité de configurer l’exécution d’outils avec les credentials de l’utilisateur plutôt qu’un contexte sur-privilégié. Déployer Copilot Studio et en donner l’accès à tous sans déployer toutes ces briques conduit aux vulnérabilités démontrées par Tenable. C’est une leçon que les DSI doivent avoir en tête désormais.
Le second axe est le runtime protection, parce que c’est là que se joue l’écart entre l’intention et l’action. Microsoft a introduit une “advanced real-time protection” (preview) où Copilot Studio envoie le plan d’action de l’agent à un système externe (Microsoft Defender ou un tiers) qui peut autoriser ou bloquer l’exécution. Typiquement, Microsoft distingue les attaques d’injection “directes” (UPIA) et “cross/indirectes” (XPIA) et a ajouté de la visibilité côté SOC via Microsoft Defender pour détecter et corréler ces tentatives dans le contexte XDR.
Le mécanisme est intéressant car il installe un modèle “bring your own protection” et vise explicitement les injections de prompts (UPIA/XPIA). Il a aussi ses implications : le plan transmis inclut le prompt, l’historique de chat, les paramètres d’outils et des métadonnées, et la décision doit revenir très vite (Microsoft évoque une fenêtre d’environ une seconde, avec poursuite par défaut en cas d’absence de réponse). Dit autrement, l’éditeur a bien conscience du problème et de la nécessité de proposer de nouvelles solutions adéquates. Mais tout ceci est encore extrêmement immature.
Enfin, Microsoft Defender for Cloud Apps positionne une protection “AI agent” avec inventaire, collecte de logs, threat hunting et capacité de blocage en temps réel, ce qui est crucial pour industrialiser la détection d’abus et sortir du pilotage artisanal.
Dans le cas précis de l’agent de Tenable, les leçons à en tirer, les bonnes pratiques qui émergent et les leviers les plus structurants sont donc :
1/ cartographier précisément ce que l’agent peut atteindre avant sa mise en prod,
2/ scinder les stores de données pour éviter qu’un connecteur “utile” devienne un connecteur “catastrophique”,
3/ limiter drastiquement les droits d’écriture et, quand l’écriture est nécessaire, verrouiller la granularité (champs et valeurs),
4/ surveiller en continu les prompts déclenchant des actions et les actions réellement exécutées.
Tenable explicite très directement ces 4 points dans ses recommandations.
2026 : l’agentique va déplacer le centre de gravité de la cyber
La leçon de fond de tout ceci est simple : l’agentique transforme des attaques textuelles en effets réels dans le SI.
C’est une bascule comparable à l’arrivée des API, puis de l’automatisation et des RPA, mais avec un facteur aggravant : l’agent décide dynamiquement de l’enchaînement des actions en fonction d’un contexte conversationnel manipulable.
OWASP a formalisé cette bascule avec un nouveau Top 10 dédié aux applications agentiques (édition 2026) : on n’y parle plus seulement d’empoisonnement de contexte, mais de détournement d’objectif de l’agent, de mauvais usage d’outils, d’abus d’identité et de privilèges, et de vulnérabilités de supply chain agentique.
Autrement dit : l’agent IA doit être perçu comme un “utilisateur privilégié automatisé”, avec tout ce que cela implique en termes de mouvements latéraux et d’exfiltration.
Le message commun à l’expérience Tenable et autres études qui l’ont précédée c’est que la “bonne” question n’est pas “comment empêcher 100% des injections”, mais comment faire en sorte qu’une injection ne puisse pas se transformer en action dommageable. Concrètement, cela revient à traiter l’agent IA comme une application critique : moindre privilège (tokens scoppés, droits minimaux, compartimentation), outils gouvernés par des politiques déterministes (garde-fous hors-LLM), validation explicite sur les étapes sensibles, journalisation exhaustive et intégration SOC, et red teaming continu sur vos cas d’usage réels.
Pour les DSI, 2026 sera moins une question de « faut-il des agents ? » (cette question est ‘has been’, elle date de 2024) que de savoir « combien d’agents tournent déjà, avec quels droits, sur quelles données, avec quelles chaînes d’exécution ? ».
Le SOC va très rapidement devoir intégrer un nouveau type de signaux (prompts, plans d’action, connecteurs invoqués, écarts de logique métier), et l’IAM devra considérer les agents comme des identités non humaines capables d’agir, pas seulement de lire (d’où l’arrivée chez Microsoft de Agent 365).
La dynamique la plus dangereuse restera celle du déploiement diffus : des agents créés au plus près des métiers, parfois hors radar, parfois activés “par défaut” via l’arrivée de nouvelles fonctionnalités selon le phénomène déjà identifié de “shadow AI”.
Dans un tel contexte, la maturité d’une entreprise en matière de sécurisation de l’IA Agentique ne se mesurera pas au nombre de garde-fous dans les prompts, mais à la capacité à rendre l’agentique observable, gouvernable et “stoppable” au runtime, comme n’importe quel composant critique. Tout un programme pour occuper RSSI et DSI en 2026 et au-delà…
À LIRE AUSSI :
À LIRE AUSSI :
À LIRE AUSSI :
