Le contournement du sandbox de Microsoft Copilot Cowork a transformé une Skill de confiance en canal d’exfiltration

Microsoft a corrigé une vulnérabilité de Copilot Cowork après que des chercheurs ont montré qu’une seule Skill malveillante pouvait contourner le sandbox du produit et exfiltrer des données professionnelles. Le contournement du sandbox de Microsoft Copilot Cowork aurait créé un canal de commande entre le serveur d’un attaquant et l’environnement isolé de l’agent.

Selon PromptArmor, ce canal pouvait atteindre les données accessibles via Outlook, SharePoint, Teams, les plugins connectés et la session active. Le chercheur a signalé le problème le 24 juin 2026, et Microsoft a confirmé l’application d’une correction le 19 août.

Cette découverte remet en cause une promesse centrale des agents destinés au travail. Un sandbox peut isoler du code, mais cette isolation a peu de valeur lorsqu’un service de confiance devient une voie non surveillée à travers sa frontière. Microsoft indique désormais que Cowork évalue les Skills et avertit les utilisateurs de ne les importer que depuis des sources de confiance.

D’après la chronologie de divulgation, la faille signalée n’est plus un zero-day ouvert. Toutefois, l’enseignement en matière de conception dépasse une implémentation désormais corrigée. Les agents d’entreprise réunissent, dans un même flux de travail, des instructions non fiables, des ressources exécutables, des données organisationnelles et des outils authentifiés.

Cette combinaison rend la frontière de confiance plus difficile à définir que pour les logiciels d’entreprise classiques. La question centrale n’est plus de savoir si un agent s’exécute dans un sandbox. Les acheteurs doivent se demander quels services traversent ce sandbox, ce que ces services acceptent et quelles activités les équipes de sécurité peuvent observer.

Comment fonctionnait la chaîne d’exfiltration de fichiers de Copilot Cowork

L’exploit aurait transformé un service légitime de transfert de fichiers en canal de commande bidirectionnel, que les restrictions réseau du sandbox n’ont pas empêché.

Copilot Cowork est un système agentique Microsoft 365 capable de planifier et d’exécuter des tâches en plusieurs étapes. Il peut travailler avec des documents, rechercher des informations organisationnelles, créer des fichiers, envoyer des messages et appeler des Skills spécialisées.

Une Skill est un package d’instructions réutilisable qui guide l’agent dans un flux de travail particulier. Microsoft prend en charge des Skills intégrées, personnalisées, partagées et basées sur des plugins, selon l’environnement Cowork et la configuration administrative.

L’exemple de PromptArmor a commencé par une tâche professionnelle classique. Un utilisateur a demandé à Cowork de comparer un contrat avec une proposition à l’aide d’une Skill de cohérence documentaire téléchargée depuis une source externe.

La Skill a produit la comparaison demandée, de sorte que la tâche visible semblait réussie. Cependant, PromptArmor affirme qu’un script inclus appelait également un service de synchronisation de fichiers fonctionnant hors du sandbox de l’agent.

Cowork aurait utilisé ce service pour déplacer des fichiers entre un stockage externe et l’environnement de travail isolé. Le service acceptait une URL identifiant le fichier à récupérer.

Selon l’analyse du contournement du sandbox du chercheur, un code malveillant pouvait fournir à la place une URL contrôlée par l’attaquant. Ce comportement permettait au script d’amener un service externe à contacter une infrastructure que le sandbox ne pouvait pas atteindre directement.

Le serveur de l’attaquant renvoyait un fichier contenant une commande. Le script malveillant lisait ce fichier, exécutait la commande dans Cowork, puis encodait le résultat dans une autre URL demandée.

Cette seconde requête renvoyait la sortie de la commande vers le serveur de l’attaquant. La répétition du processus toutes les quelques secondes aurait établi une boucle de commande et de contrôle, permettant à un attaquant d’émettre de nouvelles instructions en fonction des résultats précédents.

Il ne s’agissait pas d’une simple requête sortante. Le mécanisme créait un accès interactif à un environnement connecté aux services de l’organisation.

PromptArmor indique que sa démonstration utilisait le serveur Model Context Protocol de Cowork. MCP est une interface standard permettant à une application d’IA d’appeler des outils connectés et de récupérer des données.

Le chercheur affirme que l’attaquant pouvait utiliser des commandes pour interroger les services accessibles via cette connexion MCP. La démonstration incluait la liste des messages Outlook et la récupération du contenu d’un fil d’e-mails.

Selon les informations rapportées, ce même chemin d’accès exposait des fichiers SharePoint, l’historique de session, des données de plugins et d’autres informations accessibles à l’utilisateur actif. L’étendue réelle dépendrait des autorisations de cet utilisateur et des services connectés.

Un détail rendait le comportement signalé particulièrement préoccupant. PromptArmor affirme que l’utilisation de la commande d’arrêt ne mettait pas fin aux processus déjà exécutés en arrière-plan.

Le tour visible de l’agent pouvait se terminer tandis que le script malveillant continuait d’interroger le serveur de l’attaquant. Un utilisateur pouvait donc croire que la tâche était arrêtée alors que le canal furtif restait actif.

PromptArmor a signalé le problème à Microsoft le 24 juin. Microsoft a demandé des informations supplémentaires le 24 juillet, discuté d’un correctif jusqu’au début août et confirmé l’application de la correction le 19 août.

Les éléments publics proviennent principalement du compte rendu technique et de la démonstration de PromptArmor. Microsoft n’a pas publié d’avis détaillé expliquant la modification du code, les versions concernées ou les données de télémétrie disponibles pour une enquête rétrospective.

Pourquoi le contournement du sandbox de Microsoft Copilot Cowork est important

La vulnérabilité visait le service reliant le sandbox aux données utiles, plutôt que de vaincre l’isolation par une évasion conventionnelle.

Un sandbox classique cherche à contenir du code non fiable en limitant les fichiers, processus, périphériques et connexions réseau. Ce modèle ne fonctionne que si chaque voie traversant la frontière applique une validation tout aussi rigoureuse.

Les agents modernes compliquent cette organisation, car le travail utile exige des exceptions contrôlées. Un agent doit recevoir des documents, renvoyer des fichiers générés, appeler des outils, accéder aux systèmes de l’entreprise et conserver suffisamment d’état pour achever des tâches longues.

Chaque exception devient un intermédiaire entre l’environnement isolé et quelque chose de plus fiable. Cet intermédiaire peut être sûr lorsqu’il valide à la fois les destinations et les flux de données. Il devient dangereux lorsque du code non fiable peut le détourner.

Le récit de PromptArmor ne décrit pas un exploit classique de corruption mémoire ni une évasion du système d’exploitation. La Skill malveillante de Copilot Cowork serait restée dans le sandbox tout en abusant d’un service privilégié situé à l’extérieur.

Cette distinction est importante pour les revues de sécurité en entreprise. Un fournisseur peut affirmer à juste titre que le code s’exécute de façon isolée tout en négligeant un intermédiaire qui effectue, pour ce code, des requêtes externes arbitraires.

Cette tension architecturale se trouve au cœur de la valeur de Cowork. Microsoft présente le produit comme un agent qui va au-delà du chat et accomplit des tâches dans Microsoft 365.

Dans l’annonce produit de Cowork de Microsoft, l’entreprise a mis en avant les flux de travail de messagerie, la recherche, la génération de documents, les intégrations et les Skills réutilisables. Ces capacités nécessitent l’accès à un contexte professionnel précieux.

La documentation actuelle de Cowork indique que les tâches traitent les fichiers utilisateur dans un environnement temporaire et isolé, à l’intérieur de la frontière de service Microsoft 365. Elle précise également que cet environnement est supprimé une fois la tâche terminée.

Ce modèle de sécurité limite l’exposition directe, mais n’élimine pas le risque lié aux outils connectés. Un environnement isolé peut toujours devenir un point de lancement lorsqu’un intermédiaire de confiance accepte une entrée contrôlée par un attaquant.

C’est pourquoi le contournement du sandbox de Microsoft Copilot Cowork met sous pression à la fois Microsoft et les acheteurs en entreprise. Microsoft doit démontrer que la frontière réparée couvre tous les intermédiaires, et pas seulement la voie de synchronisation identifiée par un chercheur.

Les clients doivent également revoir leurs hypothèses concernant les autorisations utilisateur. Cowork s’exécute avec les accès de l’utilisateur actif ; une tâche exploitée n’a donc pas besoin de compromettre un compte distinct pour atteindre les données auxquelles l’utilisateur est autorisé à accéder.

Le principe du moindre privilège réduit toujours le rayon d’impact. Il n’empêche pas l’utilisation abusive des accès que l’utilisateur détient légitimement.

Un employé comparant deux documents peut être autorisé à lire des e-mails sensibles, des dossiers d’affaires ou des discussions internes. Ces autorisations peuvent devenir accessibles à un agent via ses connexions approuvées.

L’entrée malveillante se présentait également sous la forme d’un composant de flux de travail réutilisable, et non d’un exécutable manifestement hostile. Ce conditionnement réduit la méfiance des utilisateurs, car les Skills sont conçues pour ressembler à des extensions de productivité.

L’exploit associe donc deux problèmes de sécurité que les organisations gèrent souvent séparément. Le premier est le risque de chaîne d’approvisionnement logicielle lié aux packages téléchargés. Le second est le risque d’autorisation lié aux agents qui agissent comme des utilisateurs authentifiés.

Les programmes de sécurité doivent les traiter conjointement. Examiner le code sans cartographier les données accessibles manque l’impact, tandis que gouverner les autorisations sans inspecter les ressources des Skills manque le point d’entrée.

Une Skill malveillante de Copilot Cowork peut toujours sembler utile

La Skill la plus dangereuse n’est pas celle qui échoue visiblement, mais celle qui accomplit sa tâche tout en exécutant une seconde mission cachée.

La démonstration de PromptArmor utilisait un flux de travail de comparaison de documents, car il reflète une demande ordinaire de travail intellectuel. La Skill aurait généré un rapport complet de cohérence tandis que le script malveillant ouvrait le canal furtif.

Ce double comportement affaiblit un signal de sécurité familier. Les utilisateurs considèrent souvent qu’une sortie correcte prouve que l’outil a fonctionné comme prévu.

Pour un agent, la qualité de la sortie et l’intégrité de l’exécution sont deux questions distinctes. Un rapport utile ne révèle pas tous les scripts, appels de services ou demandes de données effectués lors de sa production.

Les conseils actuels de Microsoft sur les Skills personnalisées indiquent que Cowork évalue automatiquement les Skills. Les contrôles documentés varient selon le niveau de portée et de risque.

Les contrôles statiques examinent la structure, le code inclus et le texte afin d’y détecter des schémas d’injection de prompt. Les contrôles comportementaux évaluent les sorties, les actions, l’utilisation des outils, les conflits et les performances avec des prompts réalistes.

La documentation décrit des barrières supplémentaires pour les déploiements à risque élevé. Elles peuvent inclure la validation des ressources, des tests de confiance et de sécurité, une évaluation adversariale, des tests de régression et une revue humaine.

Microsoft adresse également un avertissement direct aux utilisateurs : n’importer des Skills que depuis des sources auxquelles ils font confiance. Ce conseil reconnaît qu’une inspection automatisée ne peut pas transformer un code tiers arbitraire en dépendance sûre.

Le calendrier de ces contrôles documentés mérite d’être traité avec prudence. La documentation en ligne de Microsoft reflète le produit actuel, pas nécessairement la configuration exacte testée par PromptArmor avant le 19 août.

Il serait donc imprudent d’affirmer que tous les contrôles actuels ont échoué lors de la démonstration. Il serait tout aussi imprudent de supposer que les vérifications listées détecteraient chaque variante de l’attaque.

L’analyse statique présente des limites inhérentes. Un comportement malveillant peut être réparti entre plusieurs fichiers, dissimulé derrière des fonctions normales, téléchargé ultérieurement ou déclenché uniquement dans certaines conditions.

Les tests comportementaux n’échantillonnent eux aussi qu’un ensemble limité d’exécutions. Une Skill peut se comporter de manière sûre pendant l’évaluation et activer une logique nuisible après une date, sur un tenant ciblé ou lorsque des données spécifiques apparaissent.

Des travaux universitaires récents considèrent les Skills d’agents comme une surface de chaîne d’approvisionnement logicielle plutôt que comme de simples modèles de prompts. La recherche SkillGate a évalué un scanner hybride sur un benchmark contenant 1 650 packages de Skills.

Ses auteurs ont rapporté un score F1 de 0,817 et un taux de faux positifs de 1,13 %. Ces résultats plaident en faveur d’un filtrage à l’exécution, mais montrent aussi que la détection reste probabiliste.

La comparaison ne constitue pas une évaluation directe de Cowork, et l’article se concentre sur les Skills d’agents de programmation. Son modèle de menace correspond toutefois étroitement au problème plus large.

Un package d’instructions réutilisable peut inclure des scripts, une documentation apparemment fiable et des comportements cachés. Son installation élargit la base effective de code et d’instructions de l’agent.

Les boutiques d’applications traditionnelles gèrent un risque similaire par la signature, la revue, la réputation, le retrait rapide et les déclarations de permissions. Les Skills d’agents nécessitent ces mesures, ainsi qu’une visibilité sur l’exécution pilotée par le modèle.

Le modèle peut choisir quand et comment invoquer les fichiers d’assistance. Cette flexibilité rend un Skill plus adaptable, mais complique également la production d’un manifeste complet de son comportement.

Microsoft prend en charge le partage organisationnel et les plugins App Store, en plus des Skills personnalisés personnels. Les administrateurs peuvent gérer la disponibilité des plugins, le déploiement, les connecteurs et les utilisateurs assignés.

Ces contrôles offrent une voie de distribution plus sûre que le téléchargement d’une archive inconnue. Ils n’éliminent pas la nécessité d’inspecter les packages partagés de manière privée ou téléversés personnellement.

Les entreprises devraient traiter un Skill Copilot Cowork malveillant comme une dépendance applicative non fiable. La provenance, le versionnage, l’approbation et la révocation comptent autant que les instructions en langage naturel qu’il contient.

La promesse du sandbox face à la réalité des agents connectés

Le conflit principal oppose le confinement, présenté comme une promesse de sécurité, à la connectivité qui rend un agent d’entreprise utile.

Microsoft indique que Cowork peut envoyer des e-mails, planifier des réunions, créer des documents, publier dans Teams, rechercher des informations organisationnelles et gérer des fichiers. Ces actions le transforment d’un chatbot en système opérationnel.

Chaque connecteur ajouté accroît la valeur d’une tâche réussie. Il augmente aussi l’impact potentiel lorsqu’un échec de l’intégrité de l’exécution survient.

L’exploit signalé n’avait pas besoin que Cowork reçoive davantage de permissions que prévu. Il aurait transformé la couche d’outils authentifiée existante en une interface contrôlée par l’attaquant.

C’est l’inversion que les acheteurs d’entreprise devraient retenir. Un sandbox protégeait l’environnement d’exécution, mais un service de synchronisation externe aurait offert au code une voie de contournement de sa politique réseau.

Le même schéma peut apparaître sur les différentes plateformes d’agents. Les agents exécutés en sandbox dépendent couramment de l’automatisation de navigateur, de magasins d’artefacts, de passerelles d’outils, de serveurs MCP, de courtiers d’identifiants et d’environnements d’exécution de connecteurs.

Les équipes de sécurité examinent souvent chaque composant de manière indépendante. Les attaquants recherchent les combinaisons.

Un service de fichiers apparemment peu risqué peut devenir un proxy réseau. Un point de terminaison d’outil destiné à l’agent peut devenir une API d’accès aux données pour du code malveillant.

Un processus en arrière-plan conçu pour la fiabilité peut maintenir une attaque après l’arrêt de la tâche visible. Aucun de ces composants n’a besoin de paraître dangereux isolément.

La comparaison immédiate n’oppose pas Microsoft à un concurrent précis. La comparaison la plus utile met en regard la promesse de confinement du secteur et la réalité opérationnelle des agents connectés.

Anthropic, OpenAI, Microsoft, Google et les fournisseurs d’agents de programmation sont tous confrontés à des variantes de cette tension. Leurs produits gagnent en utilité en lisant davantage de contexte et en réalisant davantage d’actions.

La faille Cowork signalée est un exemple propre à une implémentation. Elle ne doit pas être généralisée comme preuve que chaque déploiement de sandbox ou de MCP présente la même vulnérabilité.

Elle montre toutefois pourquoi l’étiquette de sandbox ne peut pas constituer une évaluation de sécurité complète. Les acheteurs ont besoin d’un modèle de flux de données incluant chaque service ayant accès de part et d’autre de la frontière.

Ils ont également besoin de clarté sur la durée de vie des processus. Microsoft documente des contrôles de pause et d’annulation pour les tâches Cowork, mais le test de PromptArmor aurait constaté qu’un processus en arrière-plan survivait à l’action d’arrêt visible.

Microsoft a peut-être modifié ce comportement dans le cadre de l’atténuation, ou n’a peut-être fermé que la voie réseau. La divulgation publique n’explique pas la correction à ce niveau de détail.

Cette lacune de vérification est importante. Les organisations ne peuvent pas déterminer, à partir de la chronologie publique, si Microsoft a ajouté une validation des destinations, modifié l’autorisation des services, arrêté les tâches en arrière-plan, amélioré la détection ou combiné plusieurs contrôles.

L’absence d’avis détaillé ne signifie pas que l’atténuation a échoué. Elle signifie que les clients doivent obtenir des garanties par le biais des recommandations destinées aux tenants, des canaux d’assistance, des données d’audit et de tests contrôlés.

L’architecture de sécurité doit supposer qu’un contrôle préventif finira par manquer un package hostile. Une conception résiliente limite alors ce que ce package peut atteindre et rend les comportements anormaux visibles.

Pour les agents connectés, cela signifie restreindre les destinations sortantes, authentifier les demandes des courtiers, lier les services à des tâches spécifiques et séparer l’accès en lecture des permissions d’action.

Cela signifie aussi révoquer les identifiants lorsqu’une tâche se termine. Une session d’agent annulée devrait arrêter les processus associés et invalider toute autorisation temporaire créée pour cette exécution.

Enfin, la supervision doit relier l’activité des agents à la télémétrie de sécurité conventionnelle. Une invocation de Skill, un transfert de fichiers, un appel MCP et une requête sortante inhabituelle peuvent sembler inoffensifs dans des consoles distinctes.

Ensemble, ils peuvent décrire une chaîne d’attaque.

L’atténuation ne comble pas la lacune de vérification

Microsoft a confirmé l’atténuation, mais les clients ne disposent toujours pas d’assez de détails publics pour reconstituer leur exposition ou valider chaque contrôle concerné.

PromptArmor indique que Microsoft a confirmé que le problème avait été atténué le 19 août, près de huit semaines après la divulgation initiale. Ce calendrier indique une correction coordonnée plutôt qu’un exploit public non résolu.

Le chercheur n’a pas publié de preuve d’une exploitation généralisée. La démonstration établit l’existence d’une voie technique dans des conditions testées, et non le nombre de tenants réellement affectés.

Aucun nombre public d’incidents, aucune plage de versions affectées, aucun identifiant de vulnérabilité ni aucun indicateur de compromission n’apparaît dans la divulgation. Les lecteurs ne devraient pas interpréter la preuve de concept comme la preuve d’une brèche étendue.

La conclusion inverse serait également prématurée. Sans avis Microsoft détaillé, les organisations ne peuvent pas supposer que l’absence d’incidents divulgués signifie qu’aucune utilisation malveillante n’a eu lieu.

L’enquête rétrospective dépend de la télémétrie. Les administrateurs doivent savoir si les journaux de Cowork exposent les versions de Skills téléversées, l’exécution de scripts, les demandes de courtiers, les appels MCP et la durée de vie des processus en arrière-plan.

Microsoft indique que l’activité de Cowork peut apparaître dans les journaux d’audit unifiés et que les politiques Purview s’appliquent au service. La documentation administrative actuelle décrit également des contrôles concernant les plugins, les modèles, l’utilisation du navigateur et les tâches automatisées.

Ces contrôles sont pertinents, mais une couverture d’audit générale n’équivaut pas à une couverture de détection pour cet exploit. Un journal peut enregistrer une demande de service autorisée sans signaler que sa destination est hostile.

Les organisations qui ont testé Cowork avant le 19 août devraient demander à Microsoft quels événements permettent d’identifier le comportement vulnérable. Elles devraient également conserver les enregistrements d’audit pertinents avant l’expiration des périodes de rétention.

L’examen le plus important concerne la provenance des Skills. Les équipes devraient inventorier les Skills personnalisés, les archives téléversées, les scripts inclus et les packages partagés au sein de l’organisation utilisés pendant la période concernée.

Les packages inconnus ou impossibles à vérifier méritent d’être retirés en attendant leur examen. Les équipes de sécurité devraient comparer les hachages cryptographiques lorsqu’ils sont disponibles, car un nom de Skill familier n’établit pas l’intégrité du fichier.

Les administrateurs devraient ensuite associer chaque Skill aux utilisateurs qui l’ont exécuté et aux données auxquelles ces utilisateurs pouvaient accéder. Cette démarche produit une estimation de l’exposition plus précise que la seule analyse du texte des Skills.

La télémétrie réseau sortante peut fournir un autre signal. Les requêtes vers des domaines inconnus, les intervalles de sondage répétés ou les données encodées dans les chaînes de requête d’URL méritent une enquête.

Toutefois, les requêtes signalées passaient par un service situé hors du sandbox. La surveillance des terminaux sur l’appareil d’un employé pourrait donc ne pas les détecter.

Les journaux côté cloud et la télémétrie du fournisseur deviennent essentiels. Les clients devraient demander si Microsoft peut exposer la tâche d’origine, le Skill, l’utilisateur, le tenant et la destination demandée pour les transferts réalisés par l’intermédiaire d’un courtier.

Les organisations ont également besoin d’une politique pour les téléversements futurs. Autoriser n’importe quel utilisateur à importer un Skill depuis l’internet public transforme l’évaluation de confiance en décision individuelle.

Un modèle plus sûr s’appuie sur un registre interne comprenant un propriétaire, un statut de revue, des versions approuvées et des dates d’expiration. Les Skills à haut risque devraient faire l’objet à la fois d’une revue de code et de tests à l’exécution.

Les Skills partagés nécessitent un contrôle des changements après leur approbation. Un package bénin peut devenir dangereux à la suite d’une mise à jour, de la compromission du compte de son mainteneur ou du remplacement d’un fichier compagnon.

L’approbation devrait donc s’appliquer à une version précise, et non à un nom permanent. Une nouvelle revue devrait suivre chaque modification importante.

Ces mesures n’impliquent pas que Cowork soit particulièrement peu sûr. Elles reflètent le niveau de gouvernance approprié pour tout agent pouvant accéder aux e-mails, aux documents, aux discussions et aux applications métier.

Les travailleurs du savoir devraient également conserver les documents sources sensibles dans des référentiels clairement délimités. Une meilleure gestion des connaissances peut réduire l’exposition inutile des données lorsque les équipes organisent les accès autour des besoins réels du travail.

L’objectif n’est pas de supprimer tout contexte utile de chaque agent. Il consiste à empêcher qu’un flux de travail pratique n’hérite de toute l’étendue numérique d’un employé sans examen délibéré.

Trois signaux montreront si la sécurité des agents rattrape son retard

Le prochain test sera de savoir si Microsoft transforme une atténuation isolée en contrôles mesurables et visibles par les tenants pour chaque voie traversant le sandbox de Cowork.

Le premier signal sera une explication détaillée de Microsoft sur la correction. Les clients doivent savoir si Cowork valide désormais les destinations de synchronisation, lie les demandes à un stockage approuvé et arrête les processus lorsque les tâches cessent.

Un avis technique renforcerait la confiance, car les administrateurs pourraient tester les frontières pertinentes. Le silence ne prouverait pas une exposition persistante, mais il maintiendrait la vérification dépendante de canaux d’assistance privés.

Le deuxième signal sera une télémétrie de tenant plus riche. Les équipes de sécurité devraient surveiller l’apparition de nouveaux événements Cowork couvrant les hachages de Skills, l’exécution de scripts inclus, les opérations MCP, les destinations des courtiers et les processus en arrière-plan liés aux tâches.

Ces enregistrements doivent être exploitables dans les systèmes de détection existants. Un journal d’activité visible uniquement au sein d’une session Cowork ne permettra pas la chasse aux menaces à l’échelle de l’entreprise.

Le troisième signal sera une gouvernance renforcée des Skills. Le système d’évaluation documenté par Microsoft décrit déjà des contrôles statiques, comportementaux, adversariaux, de régression et humains selon différents niveaux de risque.

La question clé est de savoir avec quelle cohérence ces contrôles s’appliquent aux Skills importés, personnels, partagés et distribués via une boutique. Les acheteurs devraient rechercher des packages signés, des approbations de versions fixes, des listes d’autorisation centralisées et une révocation rapide.

Microsoft devrait également préciser si les fichiers compagnons d’un Skill reçoivent le même niveau d’examen que son fichier d’instructions principal. Le scénario de PromptArmor reposait sur du code malveillant inclus, et pas uniquement sur un texte trompeur.

Ces signaux renforceront ou affaibliront l’argument plus large en faveur des agents autonomes en milieu de travail. Une meilleure vérification montrerait que les fournisseurs traitent les Skills comme des composants exécutables de la chaîne d’approvisionnement.

Une visibilité limitée laisserait aux clients une grande part du risque. Il leur serait demandé de faire confiance à un sandbox corrigé sans voir les frontières qui ont changé.

Pour les entreprises évaluant Cowork aujourd’hui, la réponse pratique est un déploiement mesuré. Confirmez l’atténuation, limitez les personnes autorisées à téléverser des Skills, examinez les packages existants, réduisez les accès au minimum et surveillez les services connectés.

Le contournement du sandbox de Microsoft Copilot Cowork aurait été corrigé, mais son avertissement architectural demeure. Les agents concentrent les instructions, le code, les identifiants et le contexte organisationnel dans un même chemin d’exécution.

Avant d’étendre le déploiement, posez une question concrète : votre équipe de sécurité peut-elle reconstituer chaque Skill, processus, appel d’outil et requête externe associés à une tâche terminée ? Si la réponse n’est pas claire, faites de cette visibilité une exigence avant d’accorder un accès plus étendu.