Microsoft a identifié 7 méthodes pour pirater vos agents IA. L’une d’elles est déjà exploitée en production.
Lors de Microsoft Build 2026, l’équipe de recherche en sécurité a enrichi sa taxonomie des menaces liées aux agents IA avec sept nouvelles catégories, reflétant les actions des adversaires et les angles morts des défenseurs dans les systèmes agentiques déployés. Le choix des termes est crucial : dire « les agents IA sont risqués » relève d’une posture, alors que nommer sept vecteurs d’attaque distincts avec leurs propres parades constitue un cadre opérationnel.
Compromission de la supply chain agentique. Contrairement aux attaques traditionnelles de la supply chain qui reposent sur du code malveillant, ce vecteur exploite le langage naturel. Le comportement d’un agent peut être influencé par du contenu malveillant inséré dans les prompts, les documents récupérés ou les instructions d’agents en amont — sans aucune injection de code.
Détournement d’objectif. Un adversaire insère des instructions qui semblent cohérentes avec la mission légitime de l’agent tout en redirigeant discrètement son objectif final. Ce scénario est particulièrement dangereux dans les workflows agentiques à étapes multiples où l’agent agit de façon autonome.
Escalade de confiance entre agents. Dans les architectures multi-agents, un agent compromis peut usurper une identité ou revendiquer des autorisations exagérées auprès d’un agent orchestrateur. Ce dernier, sans vérification cryptographique, accepte la demande et accorde des accès injustifiés.
Attaque visuelle sur agent utilisateur d’ordinateur. Les agents opérant via des interfaces graphiques peuvent être manipulés par du contenu malveillant affiché à l’écran — instructions cachées dans des documents, pages web ou éléments d’interface qui redirigent les actions de l’agent via le canal visuel.
Contamination du contexte de session. Un adversaire introduit des données qui biaisent le raisonnement de l’agent lors des étapes suivantes, sans déclencher de contrôle de sécurité à chaque prise de décision. La contamination s’accumule au fil de la session, menant à une conclusion compromise à partir d’entrées en apparence anodines.
Abus du MCP/Plugin. C’est la catégorie à laquelle appartient l’incident Asana. Le Model Context Protocol crée un canal structuré pour l’interaction des agents avec des outils et sources de données externes. Les vulnérabilités de ce canal — failles logiques, autorisations mal configurées ou outils malveillants — peuvent exposer des données auxquelles l’agent ne devrait pas accéder, permettre l’exfiltration ou un pivot entre organisations.
Divulgation des capacités/architecture. Un agent qui révèle des détails internes — contenu du prompt système, fonctions des outils, intégrations disponibles — fournit les renseignements nécessaires pour concevoir des attaques plus ciblées contre lui.
5 points clés à retenir
1. L’abus du MCP/Plugin est déjà un risque en production, pas seulement théorique.
La faille du serveur MCP d’Asana en 2025 a exposé environ 1 000 organisations lorsqu’une erreur de logique a permis de franchir les frontières entre locataires — données de tâches, métadonnées de projets, commentaires et fichiers téléchargés étaient visibles d’une organisation à l’autre. Microsoft a officiellement nommé cette catégorie dans sa taxonomie actualisée des menaces liées aux agents IA. Le serveur MCP sécurisé de Kiteworks y répond en appliquant des règles au niveau du protocole avant que les données n’atteignent l’agent — la couche de gouvernance que l’incident Asana a démontré comme indispensable.
2. La réponse de Microsoft à Build 2026 fournit une infrastructure d’application, pas seulement des recommandations.
L’Execution Container, les Agent Control Specifications et l’outil ASSERT créent une couche de gouvernance à l’exécution que les équipes de sécurité peuvent déployer face à des scénarios de menaces précis. L’Execution Container impose des frontières explicites à l’exécution, sans se fier à l’auto-limitation des agents. Les Agent Control Specifications sont des définitions de règles portables et auditées, versionnables indépendamment de l’agent. ASSERT opérationnalise les sept modes d’échec via des tests adverses. Il s’agit désormais d’une discipline d’ingénierie — avec des vecteurs nommés et des contre-mesures publiées.
3. Les sept modes d’échec offrent aux red teams une checklist concrète.
Compromission de la supply chain agentique, détournement d’objectif, escalade de confiance entre agents, attaque visuelle sur agent utilisateur d’ordinateur, contamination du contexte de session, abus du MCP/Plugin et divulgation des capacités/architecture sont désormais des surfaces d’attaque documentées nécessitant des tests ciblés. Microsoft recommande d’inventorier la supply chain des agents, de vérifier leur identité de façon cryptographique plutôt que déclarative, et d’ajouter ces sept vecteurs aux matrices de couverture des red teams.
4. Les contrôles IAM et DLP classiques ne couvrent pas le comportement agentique.
Les agents IA fonctionnent de façon asynchrone, enchaînent les appels d’outils et agissent pour le compte d’utilisateurs selon des modalités que les contrôles périmétriques et d’identité existants ne sont pas conçus pour gérer. Les outils DLP inspectent les canaux connus ; les agents sollicitent des API externes et traitent du contenu issu de sources hors de ces canaux. Une couche dédiée de gouvernance du contenu IA — qui définit les contenus sensibles que les agents peuvent récupérer, traiter et transmettre — s’impose.
5. Les secteurs réglementés sont exposés à des risques accrus.
Des agents IA accédant à des CUI, des informations médicales protégées (PHI) ou des données ITAR via des intégrations MCP mal configurées génèrent à la fois un incident de sécurité et une violation de conformité. CMMC, HIPAA et RGPD ne s’arrêtent pas parce que l’acteur est un agent IA — les accès doivent être autorisés, tracés et sécurisés selon les mêmes cadres que pour les accès humains aux contenus réglementés.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Abus du MCP/Plugin : de la taxonomie à la faille en production
Asana a lancé l’intégration serveur MCP avec des fonctions LLM le 1er mai 2025. Une faille de logique dans la mise en œuvre a permis à des utilisateurs d’une organisation de voir les données d’une autre instance Asana — informations sur les tâches, métadonnées de projet, détails d’équipe, commentaires, discussions et fichiers téléchargés. L’exposition était limitée au périmètre d’accès de chaque utilisateur, mais il s’agissait bien d’une visibilité croisée entre locataires, via une intégration IA à laquelle les organisations faisaient confiance.
Asana a découvert la faille en juin 2025, environ un mois après la mise en service de la fonction MCP. Près de 1 000 clients ont été touchés. La leçon n’est pas que le MCP est intrinsèquement peu sûr — le protocole n’est qu’une couche de communication. La vraie leçon, c’est que ce protocole nécessite une couche de gouvernance supplémentaire : des règles explicites définissant ce que chaque agent peut consulter, dans quelles conditions et avec quel périmètre. Sans cette couche, l’intégration MCP hérite des autorisations du service sous-jacent — ce qui, dans un environnement SaaS multi-locataires, aboutit exactement au type d’exposition croisée qu’a connue Asana.
Microsoft a désormais officiellement nommé cette catégorie de défaillance et l’a placée aux côtés de six autres vecteurs dans une taxonomie que les équipes de sécurité doivent utiliser pour structurer leurs programmes de red teaming IA. Les défaillances de gouvernance des données IA dans les déploiements MCP ne sont pas des cas marginaux. Elles résultent inévitablement de l’intégration de fonctions puissantes sans contrôle suffisant entre locataires.
La réponse runtime de Microsoft : Execution Container, ASSERT et Agent Control Specifications
Trois composants de Build 2026 forment ensemble le cadre de sécurité des agents IA le plus abouti publié par un grand éditeur.
Le Microsoft Execution Container impose des frontières explicites à l’exécution, sans se fier à l’auto-limitation des agents. Les sorties d’agent, appels de plugins et invocations d’outils sont considérés comme des chemins d’exécution non fiables nécessitant une évaluation des règles avant de poursuivre — on passe d’un modèle « configurer correctement l’agent et espérer » à « imposer des frontières à l’exécution, quel que soit le comportement de l’agent ».
Agent Control Specifications sont des définitions de règles portables décrivant ce qu’un agent est autorisé à faire, quels outils il peut utiliser et quels points externes il peut atteindre. Ces règles sont indépendantes de l’implémentation de l’agent — auditées, versionnables et modifiables sans toucher à l’agent lui-même. On traite ainsi la gouvernance des agents comme un problème de gestion de configuration, et non de code embarqué.
ASSERT (Adversarial Stress and Security Evaluation for Resilient Thinking) opérationnalise les sept modes d’échec via des tests adverses que les équipes de sécurité peuvent exécuter sur les agents déployés pour identifier les vulnérabilités avant qu’elles ne soient exploitées.
Pourquoi les contrôles de sécurité traditionnels sont insuffisants
Un utilisateur qui se connecte à une plateforme SaaS présente ses identifiants, passe l’authentification multifactorielle et agit dans une session définie. Les journaux d’audit enregistrent les fichiers consultés. Un agent IA ne suit pas ce schéma : il fonctionne de façon asynchrone, exécute des centaines d’appels outils sans intervention humaine à chaque étape, enchaîne les requêtes, récupère des données d’une source pour alimenter une autre, et agit pour le compte d’un utilisateur dont la session peut être terminée depuis des heures.
L’architecture Zero trust fournit le bon cadre conceptuel — ne jamais faire confiance, toujours vérifier — mais les mécanismes de vérification conçus pour les humains ne s’appliquent pas directement à des agents asynchrones nécessitant une autorisation continue sur des chaînes d’outils multi-étapes. L’Execution Container et les Agent Control Specifications de Microsoft traitent la couche d’exécution. La couche données — qui définit les contenus sensibles que l’agent peut récupérer, traiter et transmettre — requiert un cadre de gouvernance du contenu pensé pour cet usage, au-delà du simple confinement à l’exécution.
Les enjeux de conformité dans les secteurs réglementés
Les sept modes d’échec identifiés par Microsoft ne sont pas que des menaces de sécurité — ils constituent aussi des risques de non-conformité au regard des cadres qui régissent la gestion de certains contenus sensibles.
Pour les sous-traitants de la défense soumis au CMMC 2.0, un agent IA qui extrait des CUI d’un système de gestion de projet et les transmet via une intégration MCP à un outil externe génère un événement de conformité CMMC. Même logique pour HIPAA : des informations médicales protégées (PHI) transitant via le contexte d’un agent IA sont soumises aux exigences de contrôle d’accès et d’audit, qu’il s’agisse d’un humain ou d’une IA. Le RGPD ajoute la minimisation des données : un agent qui récupère plus de données que nécessaire pour sa tâche enfreint potentiellement l’exigence de minimisation du RGPD par son seul mode de fonctionnement.
Les entreprises des secteurs réglementés ne peuvent pas considérer la gouvernance des agents IA comme un programme distinct de leurs obligations de conformité existantes. Elles doivent étendre la classification des données, les contrôles d’accès, la journalisation et la sécurité des transmissions qui régissent l’accès humain aux contenus réglementés à l’accès des agents IA également.
Construire une couche de gouvernance Zero trust pour les agents IA
Le serveur MCP sécurisé de Kiteworks encadre l’accès des agents IA aux contenus régis par Kiteworks via un point d’application des règles. Plutôt que de laisser les agents extraire du contenu où ils le souhaitent, le serveur MCP sécurisé évalue chaque demande selon des règles d’accès explicites avant que les données ne soient transmises à l’agent — application au niveau du protocole, et non de l’implémentation de l’agent.
La passerelle de données IA de Kiteworks étend ce principe à l’ensemble des workflows IA d’entreprise, en fournissant un canal contrôlé pour les requêtes IA sur des référentiels de contenus sensibles avec des règles d’accès tenant compte de la classification. Les CUI, informations médicales protégées (PHI) et autres contenus réglementés ne sont accessibles qu’aux agents IA explicitement autorisés à les traiter. Chaque interaction est consignée dans un journal d’audit infalsifiable, directement exploitable par les SIEM — la documentation que les auditeurs CMMC, HIPAA et RGPD exigeront lors de l’examen des accès IA aux contenus sensibles.
Le Réseau de données privé Kiteworks étend cette gouvernance à la messagerie électronique, au partage et au transfert de fichiers, à SFTP, aux formulaires web et aux API, sous un moteur de règles unique et un journal d’audit consolidé. Microsoft a nommé les menaces et fourni les outils d’application à l’exécution. Reste à chaque entreprise à s’assurer que sa couche de gouvernance du contenu est à la hauteur du risque.
Pour en savoir plus sur la protection de vos contenus sensibles face aux agents IA compromis, réservez votre démo sans attendre !
Foire aux questions
La taxonomie de Microsoft intègre la compromission de la supply chain agentique, le détournement d’objectif, l’escalade de confiance entre agents, l’attaque visuelle sur agent utilisateur d’ordinateur, la contamination du contexte de session, l’abus du MCP/Plugin et la divulgation des capacités/architecture. Microsoft recommande d’ajouter ces sept vecteurs aux matrices de couverture des red teams, d’inventorier la supply chain des agents et de vérifier leur identité de manière cryptographique. Le serveur MCP sécurisé de Kiteworks cible spécifiquement l’abus du MCP/Plugin en appliquant des règles au niveau du protocole avant que les données n’atteignent l’agent.
En mai 2025, l’intégration serveur MCP d’Asana a permis à des utilisateurs d’une organisation de voir des données de tâches, des métadonnées de projet et des fichiers d’autres organisations — une fuite de données entre locataires, due à l’intégration MCP elle-même, et non à une attaque externe. Environ 1 000 clients ont été touchés avant que le serveur ne soit mis hors ligne en juin 2025. Microsoft a officiellement nommé ce mode de défaillance (abus du MCP/Plugin) comme vecteur d’attaque prioritaire, preuve concrète que la gouvernance des données IA pour les déploiements MCP est un enjeu opérationnel, et non théorique.
L’Execution Container impose des frontières explicites sur l’accès au système de fichiers, les connexions réseau, l’accès aux identifiants et les appels d’outils à l’exécution — indépendamment de la configuration ou des instructions de l’agent. Les Agent Control Specifications fournissent des règles portables et auditées décrivant les comportements autorisés, séparées de l’implémentation de l’agent. Ensemble, ils couvrent la couche d’exécution. La gouvernance du contenu — les règles qui contrôlent les données sensibles que les agents peuvent consulter et traiter — nécessite des contrôles complémentaires comme le serveur MCP sécurisé et la passerelle de données IA.
Les exigences de contrôle d’accès, de journalisation et de sécurité des transmissions du CMMC niveau 2 pour les CUI ne prévoient aucune exception pour les agents IA. Un agent qui extrait des CUI via une intégration MCP et les transmet à un outil externe doit être autorisé, tracé et sécurisé selon les contrôles NIST 800-171 applicables. Même logique pour HIPAA : des informations médicales protégées (PHI) traitées par un agent IA restent des PHI et l’accès doit être documenté. Les organisations doivent étendre leurs programmes de gouvernance du contenu pour couvrir explicitement l’accès des agents IA.
Le serveur MCP sécurisé applique les règles d’accès au niveau du protocole avant que les données ne soient transmises à l’agent demandeur. La passerelle de données IA fournit un canal contrôlé pour les requêtes IA sur des référentiels de contenus sensibles avec application tenant compte de la classification. Les journaux d’audit infalsifiables consignent chaque interaction d’agent avec des contenus réglementés pour répondre aux exigences d’audit CMMC, HIPAA et RGPD — rendant la protection Zero trust des données pour les workflows IA opérationnelle et non plus théorique.
Ressources complémentaires
- Article de blog
Stratégies Zero‑Trust pour une protection abordable de la vie privée face à l’IA - Article de blog
Comment 77 % des organisations échouent à sécuriser les données IA - eBook
AI Governance Gap : 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 des preuves concrètes.