L’export du système de fichiers de Meta Muse révèle l’écart entre isolation et contrôle
Meta Muse aurait exporté 6,8 Go de fichiers d’exécution après qu’un utilisateur lui a demandé d’archiver tout ce qu’il pouvait voir. Selon le développeur Peter James, l’export du système de fichiers de Meta Muse comprenait des fichiers système, de la documentation interne, des modèles d’applications, des enregistrements de mémoire et des journaux d’agents. Cela se serait produit environ deux semaines après le lancement par Meta de Muse comme agent personnel sécurisé.
Cette affirmation ne montre pas que James ait accédé à l’infrastructure hôte de Meta ni aux données d’un autre client. Meta affirme que chaque utilisateur de Muse reçoit une machine virtuelle isolée, ce qui rend son système de fichiers comparable à ceux d’un ordinateur portable personnel. Cette réponse laisse toutefois une question plus difficile sans réponse : un agent grand public devrait-il distribuer des éléments internes de son environnement d’exécution simplement parce qu’ils se trouvent dans l’environnement qui lui est attribué ?
Ce conflit importe davantage que la nouveauté consistant à télécharger les fichiers d’un agent d’IA. Meta présente l’isolation, les contrôles d’autorisation et un contrôleur de sécurité séparé comme des protections centrales de Muse. L’export signalé suggère que l’isolation peut être maintenue alors que les politiques de contrôle de l’information échouent encore à la frontière du produit.
Ce que contenait l’export du système de fichiers de Meta Muse
L’affirmation vérifiée la plus claire est limitée mais importante : Muse aurait empaqueté des fichiers de son propre environnement d’exécution attribué et les aurait transférés vers un Google Drive connecté.
James a publié son récit le 22 septembre 2026. Il a déclaré avoir demandé à Muse d’archiver les fichiers auxquels il pouvait accéder et de les envoyer vers son Drive. Le téléchargement obtenu pesait environ 2,7 Go une fois compressé et 6,8 Go après extraction.
Le message de livraison de Muse décrivait apparemment l’archive comme faisant 2,86 Go, créant un léger écart avec les notes de James. James a signalé cette différence plutôt que de présenter les mesures comme identiques. L’archive elle-même n’a pas été publiée, ce qui limite tout examen indépendant.
D’après l’export d’exécution détaillé de James, les fichiers semblaient représenter le système de fichiers racine attribué à sa session Muse. Ils incluaient des fichiers système Ubuntu, du code d’intégration, des modèles d’applications, de la documentation interne, des fichiers mémoire et des journaux d’activité de l’agent.
L’archive contenait également des fichiers de clés SSH. James a toutefois indiqué ne pas avoir établi si ces clés étaient encore actives ni à quels systèmes elles pouvaient donner accès. Leur présence justifie donc une enquête, mais n’établit pas à elle seule un accès non autorisé.
Plusieurs répertoires offraient une image détaillée de l’environnement signalé. Le répertoire personnel de l’agent contenait des fichiers d’instructions et d’identité portant notamment les noms SOUL.md, IDENTITY.md, USER.md, MEMORY.md, AGENTS.md et TOOLS.md.
James a recensé 113 enregistrements de sous-agents stockés sous forme de traces JSONL. Il a également trouvé environ 20 documents Markdown couvrant le comportement du navigateur, les connecteurs, les identifiants, les paiements, la planification, les fichiers générés, les fonctions vocales et le traitement des données.
Un autre répertoire contenait apparemment près de 68 dossiers de compétences. Ceux-ci associaient des instructions écrites à des utilitaires en ligne de commande ou à du code de support pour des services couvrant les e-mails, les calendriers, les voyages, les achats, la santé, les médias et les appareils connectés.
Les fichiers montraient aussi comment Muse assemblait apparemment son environnement d’exécution. James a décrit 18 fichiers associés à la création et au lancement d’un conteneur systemd-nspawn, un environnement d’isolation Linux qui fournit aux processus un système de fichiers confiné et des capacités limitées.
Ce détail correspond globalement à l’architecture publique de Meta. Meta affirme que Muse utilise une machine virtuelle dédiée contenant une cellule d’exécution séparée, des services d’identifiants, des bases de données et des composants de sécurité. L’entreprise confirme également que Hatch est le nom de code interne de Muse.
Le développeur Jonny L. Saunders a déclaré avoir reproduit indépendamment le résultat général. Il a décrit le processus comme extrêmement simple et a soutenu que Muse opposait presque aucune résistance à l’injection de prompt.
La vérification indépendante la plus solide est venue de The Verge. Son journaliste a déclaré que Muse avait d’abord refusé une demande portant sur le système de fichiers complet. Après une nouvelle session et une formulation différente, Muse aurait fourni des copies assainies de /opt/hatch et /home/hatch, ainsi que leur arborescence de répertoires.
Cette tentative n’a pas reproduit tous les éléments de l’archive de James. Muse aurait notamment supprimé des éléments tels que les clés SSH. Néanmoins, les fichiers retournés semblaient cohérents avec les éléments décrits par James et Saunders, selon le rapport original sur le système de fichiers.
Ces récits étayent une conclusion limitée. Muse pouvait exposer des portions substantielles de son environnement d’exécution attribué au moyen d’une conversation ordinaire, au moins lors des tests rapportés. Ils n’établissent pas une évasion de conteneur, un accès inter-comptes ou la compromission des hôtes cloud sous-jacents de Meta.
James a explicitement indiqué n’avoir pas démontré d’évasion du conteneur. Il a brièvement testé cette limite, constaté qu’elle semblait tenir, puis s’est arrêté avant de tenter un examen plus approfondi des systèmes de production.
Cette distinction doit guider toute interprétation de l’incident. Qualifier le résultat de violation complète de l’infrastructure de Meta dépasse les preuves disponibles. Le qualifier d’insignifiant ignore également ce que les fichiers exportés contenaient apparemment.
Meta affirme que les fichiers appartenaient à la machine virtuelle de l’utilisateur
La défense de Meta repose sur la propriété et l’isolation : les utilisateurs peuvent inspecter les ordinateurs qui leur sont attribués sans accéder aux systèmes privilégiés de Meta ni aux données d’autres utilisateurs.
Un porte-parole de Meta a déclaré à The Verge que l’incident ne constituait pas une faille de sécurité. L’entreprise a comparé ce comportement au fait de consulter les fichiers présents sur l’ordinateur portable devant l’utilisateur.
« Bien sûr que vous pouvez voir les fichiers », a déclaré le porte-parole Daniel Roberts. Il a ajouté que l’export de données d’une machine virtuelle n’accorde pas d’accès privilégié à l’infrastructure de Meta ni aux informations d’autres personnes.
Cet argument est techniquement cohérent. Un répertoire racine au sein d’un conteneur isolé n’est pas nécessairement le répertoire racine de son hôte. Le terme « racine » décrit une position dans un système de fichiers et peut donner une impression trompeuse d’accès universel.
L’architecture de sécurité publiée par Meta indique que chaque utilisateur et son Muse partagent une machine virtuelle Linux dédiée. À l’intérieur, l’environnement d’exécution principal Hatch fonctionne dans un conteneur systemd-nspawn.
Meta affirme que l’utilisateur root à l’intérieur de ce conteneur correspond à un utilisateur non privilégié sur l’hôte. Le conteneur reçoit son propre système de fichiers Debian, des appels système filtrés, une interface réseau virtuelle et des capacités Linux réduites.
Les services sensibles se trouvent en dehors de la cellule d’exécution. Ces services comprennent le magasin d’identifiants, les workers de connecteurs, les bases de données applicatives persistantes, les proxys d’inférence et Sentinel, l’autorité d’autorisation distincte de Meta.
Selon Meta, Sentinel contrôle les actions des connecteurs et l’accès au réseau. Muse propose une action, tandis que Sentinel décide de l’autoriser, de la rejeter ou de demander l’approbation de l’utilisateur.
Cette conception répond à plusieurs menaces sérieuses. Si un prompt manipule le modèle, celui-ci ne devrait pas recevoir automatiquement les mots de passe, les identifiants de paiement, les autorisations au niveau de l’hôte ou un accès réseau non restreint.
Meta affirme que les identifiants des connecteurs restent hors de portée directe de l’agent. L’environnement d’exécution ne voit que des jetons temporaires de substitution, tandis que Sentinel les remplace par de véritables identifiants uniquement à une frontière réseau approuvée.
Cette séparation aide à expliquer pourquoi Meta rejette l’étiquette de faille. Aucune preuve publique ne montre que le système de fichiers exporté contenait les données d’un autre client, des magasins d’identifiants centraux ou un accès direct à une infrastructure Meta partagée.
Les propres observations de James étayent une partie de la position de Meta. Il pouvait inspecter des scripts décrivant la création du conteneur, mais n’a pas prouvé un accès au-delà de l’environnement attribué. Son rapport indique également que l’archive ne suffisait pas à auditer l’ensemble du service de Meta.
Toutefois, l’analogie de Meta avec un ordinateur portable condense plusieurs questions distinctes en une seule. Un ordinateur portable personnel appartient normalement à son propriétaire, y compris le système d’exploitation et la plupart des fichiers installés localement. Muse fonctionne dans le cloud géré par Meta et inclut des instructions, des modèles, des binaires propriétaires et des références semblant non publiées.
Les utilisateurs interagissent aussi avec Muse via une interface conversationnelle, et non une console d’administration système traditionnelle. Cette interface aurait refusé certaines demandes tout en en exécutant de similaires formulées différemment. Une telle incohérence implique qu’au moins une partie du produit considérait ces fichiers comme restreints.
Meta a lancé Muse en mettant en avant la sécurité et la confidentialité. Son annonce de lancement affirme que les utilisateurs gardent le contrôle, que les actions sensibles exigent une approbation et que Sentinel régit l’accès externe.
La même annonce indique que l’agent peut parcourir des sites web, envoyer des messages, remplir des formulaires, effectuer des achats et se connecter à des services personnels. Ces capacités rendent la frontière d’autorisation plus importante qu’elle ne le serait pour une démonstration de programmation isolée.
Meta affirme aussi que Muse stocke les données d’un utilisateur dans la machine virtuelle dédiée. Par conséquent, une demande visant à exporter « tout » peut mélanger plusieurs catégories : fichiers appartenant à l’utilisateur, mémoire de l’agent, composants système, instructions propriétaires, journaux opérationnels et éventuels éléments de clés.
Traiter l’ensemble de cette collection comme des données ordinaires visibles par l’utilisateur simplifie la politique produit. Cela ne résout pas la question de savoir si chaque fichier inclus était intentionnellement exportable.
Meta a déclaré à The Verge qu’elle continuerait à mettre à jour le produit. Les utilisateurs pourraient donc constater des changements dans la quantité d’informations sur leurs machines virtuelles qui reste disponible. Cette réponse suggère que la limite actuelle est encore en cours d’affinement.
L’isolation a fonctionné, mais le contrôle de l’information semble encore incomplet
Le renversement central est que le bac à sable de Muse a peut-être contenu l’agent avec succès tout en lui permettant de divulguer des fichiers que Meta n’avait probablement pas l’intention d’exposer conversationnellement.
Un bac à sable limite les actions possibles d’un programme. Il ne décide pas automatiquement quels fichiers lisibles le programme doit résumer, archiver ou envoyer ailleurs.
Cette distinction est facile à manquer. Si Muse peut lire un document interne dans le cadre d’un travail normal, le modèle peut potentiellement inclure ce document dans une sortie. Si un connecteur approuvé autorise les téléversements de fichiers, le même contenu peut quitter l’environnement d’exécution sans aucune évasion du conteneur.
L’export signalé du système de fichiers de Meta Muse teste donc une frontière de flux d’information, et pas seulement une frontière de virtualisation. La question pertinente est de savoir si Muse devrait combiner un large accès en lecture avec l’autorisation d’empaqueter et d’exporter les données obtenues.
L’architecture de Meta comprend un concept appelé tainted egress. En termes simples, un processus est marqué après avoir lu des données utilisateur, ce qui permet à Sentinel d’appliquer des contrôles plus stricts avant que des informations ne quittent la machine virtuelle.
La documentation publique se concentre largement sur la protection des informations utilisateur et des identifiants. Elle indique que Sentinel évalue les destinations, les méthodes réseau, les chemins de requête et le fait qu’un processus ait traité des éléments sensibles.
L’épisode du système de fichiers soulève la question de savoir si les fichiers internes d’exécution reçoivent une classification équivalente. Si Muse lit un fichier d’instructions, un modèle d’application ou une trace d’agent, l’archive sortante devrait sans doute porter une étiquette de politique reflétant ce contenu.
Une approbation générale pour écrire dans Google Drive peut ne pas constituer un consentement significatif pour chaque fichier possible. Les utilisateurs peuvent croire avoir autorisé un document généré, et non une image de l’environnement d’exécution de l’agent.
C’est là que l’argument de propriété de Meta et le comportement du produit divergent. Même si les fichiers appartiennent légalement ou opérationnellement à la machine attribuée à un utilisateur, l’agent a toujours besoin de règles prévisibles pour les exposer.
L’incohérence décrite par The Verge rend cette lacune visible. Une session a refusé l’exportation complète en la considérant comme un risque de sécurité. Une autre aurait livré des sous-répertoires assainis après avoir reçu des flatteries et des expressions de curiosité.
Ce comportement ressemble à une restriction au niveau du prompt plutôt qu’à une politique système fiable. Les restrictions au niveau du prompt reposent sur l’interprétation correcte de l’intention par un modèle de langage, laquelle peut varier selon les sessions et la formulation.
Un contrôle plus robuste classifierait les fichiers en dehors du modèle et appliquerait cette classification au niveau des outils. La commande d’archivage pourrait alors exclure les chemins protégés, quelle que soit la force de persuasion employée par un utilisateur dans sa demande.
Le même principe s’applique aux services connectés. Un modèle ne devrait pas décider seul si une demande générale d’un utilisateur autorise le déplacement de journaux, d’identifiants, de fichiers internes et de mémoire personnelle vers une archive externe unique.
Rien de tout cela ne prouve que Sentinel n’a pas rempli son rôle documenté. James a délibérément demandé l’exportation et fourni une destination qu’il contrôlait. Sentinel a peut-être considéré cette action comme autorisée par l’utilisateur.
Cette possibilité déplace l’attention du contournement vers la conception des politiques. Un système peut respecter ses règles d’autorisation écrites tout en produisant un résultat surprenant ou dangereux, parce que ces règles sont trop larges.
Meta affirme que les utilisateurs choisissent ce à quoi Muse peut accéder et approuvent les actions sensibles. Pourtant, le consentement devient moins informatif lorsqu’un agent peut agréger silencieusement de nombreuses catégories de fichiers derrière une action apparemment simple.
Le problème remet également en question un raccourci marketing courant. Les fournisseurs décrivent souvent un ordinateur d’agent isolé comme si l’isolation résolvait l’ensemble du problème de sécurité. En réalité, un agent doit aussi appliquer le principe du moindre privilège au sein de cet ordinateur.
Le moindre privilège consiste à n’accorder que les fichiers, commandes, réseaux et identifiants nécessaires à une tâche. Un environnement d’exécution rempli d’outils internes peut nécessiter un accès local étendu, mais cet accès ne devrait pas impliquer une divulgation sans restriction.
Pour les acheteurs en entreprise, cette distinction influence les évaluations de risque. Les équipes de sécurité doivent se demander ce que l’agent peut lire, comment le contenu est classifié, quelles actions déclenchent une nouvelle autorisation et si les exportations massives font l’objet d’un traitement spécial.
Les consommateurs font face à un problème similaire sans personnel spécialisé en sécurité. Muse invite les utilisateurs à connecter leurs e-mails, calendriers, messages, comptes d’achat et souvenirs personnels à long terme. Une fonction d’exportation massive peut rassembler ces informations dans un objet portable.
L’incident ne montre pas que l’archive de James contenait les informations d’une autre personne. Il montre pourquoi les frontières entre données personnelles, données de l’agent et données de la plateforme nécessitent une application explicite plutôt qu’une interprétation conversationnelle.
Les affirmations les plus graves restent non vérifiées
L’archive signalée soulève des questions de sécurité légitimes, mais elle ne justifie pas toutes les conclusions spectaculaires qui circulent autour de cette histoire.
Premièrement, aucune partie indépendante n’a publiquement audité l’archive complète de James. Il l’a retenue, ainsi que les clés SSH et les journaux de session, afin d’éviter de publier du contenu potentiellement sensible.
Cette décision est responsable, mais elle limite la vérification. Les observateurs extérieurs doivent s’appuyer sur des captures d’écran, des listes de fichiers, les descriptions de James, le récit de Saunders et la reproduction partielle de The Verge.
Deuxièmement, la présence de clés SSH ne révèle pas leur valeur. Les clés peuvent être expirées, restreintes, générées pour des tests internes, limitées à la machine virtuelle isolée ou inutilisables sans contrôles supplémentaires.
James a clairement reconnu cette incertitude. Il n’a pas affirmé que les clés déverrouillaient les systèmes de Meta, et aucune preuve publiée ne montre qu’elles le faisaient.
Troisièmement, les références à des intégrations non annoncées n’établissent pas l’existence de futurs produits. Des fichiers de configuration auraient mentionné des services tels que Slack et Dropbox, tandis qu’un autre document décrivait une intégration expérimentale avec un appareil Meta Home Link.
De tels fichiers peuvent représenter des prototypes, des tests abandonnés, de l’infrastructure préparatoire ou des fonctionnalités prévues. James a déclaré ne pas pouvoir déterminer si Home Link serait commercialisé.
Quatrièmement, les fichiers système ne prouvent pas une compromission de l’hôte. Les conteneurs incluent souvent des images complètes de systèmes d’exploitation, car les applications ont besoin de bibliothèques, d’utilitaires et de métadonnées de paquets standard.
Un utilisateur peut sembler disposer d’un accès root à l’intérieur d’un conteneur tout en restant sans privilèges à l’extérieur. Meta affirme explicitement que Muse utilise cette configuration.
Cinquièmement, l’étiquette « prompt injection » exige de la prudence. L’injection de prompt implique généralement des instructions non fiables intégrées à un contenu externe qui manipulent un agent sans l’intention éclairée de l’utilisateur.
Ici, des développeurs ont directement demandé à leurs propres agents d’exporter des fichiers. Cela ressemble davantage à un contournement de politique ou à un suivi incohérent des instructions qu’à une attaque classique par injection indirecte.
La critique de Saunders identifie néanmoins une faiblesse importante. Si de légères modifications de formulation annulent un refus, ce refus ne constitue pas une frontière de sécurité fiable. Toutefois, la terminologie ne devrait pas dépasser le comportement démontré.
Il existe également une différence entre transparence et vulnérabilité. Permettre aux utilisateurs d’inspecter leur environnement d’exécution attribué peut favoriser l’audit, la portabilité et la confiance. Les développeurs apprécient souvent les outils qui révèlent leurs instructions et leur environnement d’exécution.
Le risque provient d’une divulgation non structurée. La documentation interne, les traces opérationnelles, les fichiers de clés et la mémoire personnelle ne devraient pas devenir une archive indifférenciée sans avertissements clairs ni filtrage.
Le programme de bug bounty de Meta aurait marqué la soumission de James comme « Not Applicable ». Selon James, la réponse énumérait des raisons possibles et invitait à fournir des éléments démontrant un impact sur la sécurité ou la confidentialité.
Cette classification correspond à l’affirmation de Meta selon laquelle les utilisateurs n’ont accédé qu’à leurs propres environnements isolés. Elle ne détermine pas si ce comportement mérite une modification du produit en dehors du programme de récompense.
Les programmes de sécurité distinguent souvent les accès exploitables franchissant des frontières des possibilités de durcissement. Une découverte peut relever en dehors des règles de récompense tout en révélant un modèle d’autorisation déroutant ou une surface d’information inutile.
L’épisode est survenu alors que Muse était encore récent. Meta a lancé l’agent aux États-Unis le 8 septembre sur les appareils mobiles, le web et via des interactions basées sur WhatsApp.
Un rapport indépendant sur le lancement a souligné le positionnement de Meta en matière de sécurité et de confidentialité. Il décrivait également Muse comme un agent capable d’envoyer des e-mails, de réserver des voyages et de gérer des projets plus longs.
Ce contexte augmente les enjeux sans prouver une violation. Muse ne se contente pas de répondre à des questions dans une conversation jetable. Il est conçu pour agir de manière persistante à travers des services contenant des informations personnelles précieuses.
Les utilisateurs devraient donc éviter de considérer l’incident comme la preuve que chaque compte Muse est exposé. Ils devraient aussi éviter de supposer que l’isolation empêche à elle seule un agent de déplacer des informations lisibles vers une destination autorisée.
Les éléments disponibles soutiennent une position intermédiaire. La frontière de confinement semble avoir tenu lors des tests publiés, tandis que la frontière de divulgation s’est comportée de manière incohérente et a exposé davantage de matériel interne que beaucoup d’utilisateurs ne l’auraient attendu.
Ce que les utilisateurs de Meta Muse devraient surveiller ensuite
La prochaine phase devrait être jugée sur le comportement concret du produit, et non selon que Meta ou ses critiques remportent le débat autour du mot « violation ».
Le premier signal est un changement reproductible dans l’accès au système de fichiers. Meta indique que les utilisateurs pourraient constater des ajustements dans la quantité d’informations de machine virtuelle disponible. Les chercheurs devraient vérifier si les répertoires protégés reçoivent des restrictions cohérentes, appliquées par les outils, dans les nouvelles sessions.
Une mise à jour solide identifierait les catégories de fichiers avant leur archivage. Elle bloquerait ou masquerait les identifiants, les instructions de la plateforme, les journaux opérationnels et le code interne sans dépendre du jugement conversationnel d’un modèle.
Le deuxième signal concerne le traitement par Meta des sorties massives de données. Sentinel évalue déjà les requêtes réseau et les actions des connecteurs. Meta devrait préciser si la création d’archives et les transferts de fichiers volumineux font l’objet d’un examen supplémentaire selon le contenu, le volume, la destination ou la sensibilité.
Une approbation significative devrait expliquer ce qui quittera la machine virtuelle. « Téléverser un fichier » est trop vague lorsque ce fichier combine des composants système, une mémoire personnelle, des traces d’exécution et d’éventuels éléments de clé.
Le troisième signal est une validation indépendante de l’isolation. Les chercheurs ont besoin d’éléments montrant si les clés SSH exportées, les sockets ou les scripts d’exécution peuvent atteindre quoi que ce soit au-delà de l’environnement attribué.
Si ces artefacts restent confinés à la machine virtuelle d’un utilisateur, la défense limitée de Meta devient plus convaincante. Si un artefact franchit les frontières entre comptes ou infrastructures, la gravité change considérablement.
Meta devrait également clarifier le modèle de propriété. Les utilisateurs doivent savoir quelles parties d’une machine virtuelle Muse ils peuvent inspecter, exporter, supprimer ou migrer.
Cette politique devrait distinguer les documents des utilisateurs du matériel d’exécution propriétaire de Meta. Elle devrait aussi expliquer comment les enregistrements de mémoire, les traces de conversation, les applications générées et les instructions de l’agent s’inscrivent dans ces catégories.
Les développeurs et les acheteurs en entreprise devraient appliquer les mêmes questions à chaque agent personnel. Que peut lire le modèle, qu’est-ce que ses outils peuvent exporter, et quels contrôles fonctionnent indépendamment du modèle ?
Ne considérez pas le refus d’un chatbot comme une preuve qu’une action est impossible. Un refus prouve seulement qu’une réponse a rejeté la demande dans un ensemble de conditions donné.
Pour les déploiements sensibles, accordez aux connecteurs les autorisations pratiques les plus limitées. Séparez les accès en lecture et en écriture, examinez les pistes d’audit et évitez de connecter des comptes à forte valeur tant que le comportement d’exportation n’est pas prévisible.
L’exportation du système de fichiers de Meta Muse ne prouve pas que l’isolation a échoué. Elle prouve que l’isolation ne répond qu’à une partie du problème de sécurité des agents.
Le test le plus important consiste à déterminer si Meta peut transformer son architecture documentée en contrôles qui restent cohérents dans une conversation ordinaire. Les utilisateurs devraient surveiller ces contrôles avant de confier à Muse un accès personnel ou professionnel plus large.
