Le différend sur la confidentialité de Meta Muse met à l’épreuve ses promesses de permissions

Meta a contesté un rapport selon lequel Muse aurait lu des Messages privés sans autorisation, transformant le débat sur la confidentialité de Meta Muse en un affrontement entre récits techniques divergents.

Le chroniqueur d’Inc. Jason Aten affirme que Muse a fait remonter des détails issus de conversations privées après qu’il a refusé de donner à l’agent l’accès à Messages. Meta affirme que cette séquence est impossible avec l’architecture produit qu’elle a conçue.

Le désaccord est particulièrement net. Aten affirme que Muse a accédé à des données de messages alors que Full Disk Access semblait désactivé. Meta affirme que cette permission macOS ainsi qu’un connecteur Muse distinct doivent être activés avant que l’agent puisse lire Messages.

Aucun des deux récits n’a été reproduit de façon indépendante dans un test contrôlé. Les utilisateurs sont donc confrontés à davantage qu’un simple signalement de bug logiciel. Ils doivent décider si un agent mérite un accès étendu alors que son développeur et un utilisateur ne s’accordent pas sur ce qui s’est produit.

Le différend est également survenu peu après que Meta a présenté Muse comme un agent personnel conçu pour fonctionner avec des applications, fichiers, communications et services web. Son utilité dépend de son accès à des informations que les chatbots ordinaires ne peuvent pas voir.

Ce même accès place les limites du consentement au cœur du produit. Un agent personnel devient plus utile à mesure qu’il acquiert du contexte, mais chaque connecteur supplémentaire élargit les conséquences d’un état de permission ambigu.

Les affirmations de Meta Muse sur la confidentialité se heurtent au récit contradictoire d’un utilisateur

Le fait central n’est pas qu’un accès non autorisé ait été prouvé, mais que Meta et Aten décrivent des états de permission incompatibles.

Selon le litige initial, Aten a remarqué que Muse faisait référence à une conversation avec son coanimateur de podcast au sujet de nouveaux iPhones. L’agent aurait également signalé un message de son rédacteur concernant l’approche d’une échéance de chronique.

Aten a déclaré ne pas avoir demandé à Muse de surveiller ces conversations. Plus important encore, il se souvenait avoir explicitement refusé l’accès à Messages, à son calendrier et à d’autres informations personnelles lors de la configuration.

Interrogé, Muse aurait indiqué avoir reçu du texte provenant de bannières de notifications entrantes plutôt que d’avoir lu l’historique des messages sous-jacent. Aten a ensuite rejeté cette explication après avoir examiné les réglages et l’état de synchronisation de l’agent.

Il a rapporté avoir constaté que le connecteur Messages s’était synchronisé jusqu’à la ligne 187,462 de sa base de données Messages locale. Une ligne de base de données ne correspond pas nécessairement à un message complet ; ce chiffre ne doit donc pas être présenté comme 187,462 messages.

Ce chiffre reste néanmoins important. Il suggère une synchronisation de la base de données plutôt que la visibilité limitée et temporaire qu’impliquent les aperçus de notifications.

Andy Stone, responsable des communications de Meta, a contesté ce récit. Il a déclaré que l’intégration de Muse à Messages sur Mac est entièrement facultative et exige des utilisateurs qu’ils activent deux contrôles distincts.

Le premier est Full Disk Access, une permission macOS qui permet à un logiciel approuvé d’accéder à des informations protégées appartenant à d’autres applications. Le second est le connecteur Messages dans Muse.

David Singleton, dirigeant de Meta Superintelligence Labs, a apporté une réponse plus technique. Il a décrit trois étapes distinctes d’autorisation au niveau de l’application et du système d’exploitation, dont une confirmation manuelle dans macOS System Settings.

Meta affirme que les utilisateurs doivent d’abord accorder Full Disk Access. Ils peuvent ensuite choisir un niveau d’accès à Messages dans Muse, les choix indisponibles restant désactivés lorsque la permission système est coupée.

Modifier le contrôle système redémarre également l’application Muse, selon Singleton. Meta soutient que ces étapes rendent une activation accidentelle peu probable et empêchent l’application de contourner la limite imposée par le système d’exploitation.

Aten maintient que Full Disk Access était désactivé lorsqu’il a vérifié le réglage. Cela soulève la question non résolue au cœur du différend : quel état de permission existait lorsque la synchronisation a commencé, et non seulement lorsqu’il a été observé ultérieurement ?

Les éléments de preuve publics actuels ne répondent pas à cette question. Des captures d’écran peuvent documenter un état ultérieur, tandis que des journaux pourraient établir à quel moment les permissions ont changé, quel processus a accédé à la base de données et quelles données ont quitté l’appareil.

Meta a également contesté l’explication de Muse au sujet de la synchronisation des notifications. Singleton a déclaré que l’agent était confus et avait généré un récit incorrect de son propre comportement.

Cette réponse peut résoudre une affirmation précise, mais elle révèle une autre faiblesse. Un agent incapable d’expliquer avec exactitude la source de ses données fournit aux utilisateurs des éléments insuffisants pour évaluer un comportement inattendu.

Pourquoi l’accès de Muse à Messages exige plus qu’une capture d’écran des réglages

Le différend ne peut pas être tranché en considérant un seul interrupteur visible comme un historique complet des accès passés.

Apple décrit Full Disk Access comme une permission permettant à une application d’accéder aux fichiers sur un Mac, y compris aux données de Mail, Messages, Safari et d’autres applications. Les utilisateurs le gèrent via les contrôles de confidentialité de Mac.

Cette protection système étaye l’argument de Meta. Une application Mac conventionnelle ne devrait pas pouvoir lire la base de données Messages protégée simplement parce qu’elle demande l’accès.

Apple indique également que les applications demandant un accès complet au stockage doivent être ajoutées explicitement dans System Settings. Cette action crée une limite au niveau du système d’exploitation, en dehors de l’interface propre à Muse.

Cependant, un écran de réglages actuel ne prouve pas automatiquement tous les états antérieurs. La permission a pu être activée temporairement, modifiée durant la configuration, retirée après l’accès ou associée à un autre processus auxiliaire.

Il s’agit d’hypothèses, et non de constats concernant l’appareil d’Aten. Pour établir l’une d’elles, il faudrait des enregistrements horodatés du système d’exploitation, des journaux d’application, des identifiants de processus et des enregistrements de synchronisation côté serveur.

La distinction entre autorisation et activation importe également. Un utilisateur peut approuver une permission système étendue tout en pensant qu’un choix plus limité dans l’application restreint la manière dont le logiciel l’utilise.

À l’inverse, une application peut afficher un connecteur comme activé sans disposer de la permission système requise pour récupérer ses données sources. L’interface devrait rendre ce décalage visible et expliquer si des données déjà synchronisées restent disponibles.

Le récit de Meta suggère un consentement à plusieurs niveaux. L’utilisateur approuve l’accès au système d’exploitation, sélectionne un connecteur, choisit son niveau d’accès et redémarre l’application avant que les données deviennent lisibles.

Cette superposition peut réduire les accès accidentels, mais seulement si chaque couche reflète le même état effectif. Si les libellés sont ambigus, obsolètes ou mal synchronisés, davantage de contrôles peuvent créer davantage d’incertitude au lieu d’un consentement plus solide.

La position rapportée dans la base de données soulève une autre question technique. Il n’est pas clair si cette valeur représentait un téléversement terminé, un curseur de synchronisation local, un point de contrôle d’indexation ou un autre marqueur interne.

Cette distinction ne doit pas être devinée. Un index local peut indiquer un traitement sans prouver que chaque enregistrement référencé a atteint un modèle distant ou un serveur Meta.

La page produit de Muse indique que les utilisateurs contrôlent les permissions et approuvent certaines actions. Elle précise également que Muse peut se connecter à des applications, fonctionner en arrière-plan et continuer après la fermeture de l’application par l’utilisateur.

Ces capacités exigent des enregistrements durables de ce à quoi l’agent peut accéder et de ce qu’il a déjà collecté. Un audit des permissions doit donc couvrir à la fois l’accès actuel et les copies conservées.

La révocation d’un connecteur devrait répondre clairement à plusieurs questions. Muse peut-il encore rechercher dans du contenu précédemment synchronisé ? Le contenu mis en cache est-il supprimé, dissocié des tâches futures ou conservé selon une autre politique ?

Le désaccord public n’a pas résolu ces questions de conservation. Pourtant, elles sont essentielles pour comprendre la signification pratique de la désactivation d’une permission.

Une enquête technique utile reconstruirait la séquence depuis l’installation jusqu’à la première suggestion inattendue. Elle identifierait chaque demande de permission, transition d’état, lecture de base de données, transfert réseau et récupération par l’agent.

Sans cet enregistrement, Meta peut expliquer comment le système est conçu, tandis qu’Aten peut documenter ce qu’il a vécu. Aucune de ces formes de preuve ne permet, à elle seule, d’établir pleinement le mécanisme.

Le véritable conflit oppose la conception des permissions à l’expérience utilisateur

L’architecture de Meta peut fonctionner comme prévu alors que l’expérience globale de consentement échoue malgré tout pour un utilisateur.

C’est la tension principale du différend sur la confidentialité de Meta Muse. Meta décrit plusieurs garde-fous censés bloquer l’accès. Aten décrit un résultat produit qui semblait contrevenir à son choix explicite.

Ces positions ne constituent ni une preuve de faute, ni une preuve d’erreur de l’utilisateur. Elles montrent que les systèmes de permissions nécessitent des comportements observables, et pas seulement des contrôles internes.

Pour une application ordinaire, les utilisateurs tolèrent souvent l’incertitude quant à l’origine d’une suggestion. Un agent modifie ce calcul, car il peut combiner des informations personnelles, lancer des tâches et continuer à travailler en dehors d’une conversation active.

Muse est conçu pour dépasser le modèle requête-réponse d’un chatbot. Il peut se connecter à des services, surveiller des objectifs en cours, naviguer, préparer des documents et agir à travers plusieurs étapes.

Cela signifie que le produit doit distinguer au moins quatre opérations : voir des données, copier des données, raisonner sur des données et agir avec des données. Un seul libellé de permission risque de ne pas communiquer les quatre.

« Lire » peut signifier récupérer un seul message sur demande. Cela peut aussi vouloir dire indexer des années de conversations afin que l’agent puisse ensuite formuler des suggestions non sollicitées.

Un utilisateur peut accepter le premier comportement et refuser le second. Si l’interface n’exprime pas cette différence, un consentement techniquement valide peut malgré tout ne pas refléter l’attente de l’utilisateur.

L’explication rapportée de l’agent aggrave cette lacune. Aten affirme que Muse a attribué sa connaissance aux aperçus de notifications, tandis que Meta affirme que cette réponse était une erreur de l’IA.

Les grands modèles de langage génèrent du texte probable plutôt que d’interroger un registre interne garanti de chaque événement système. À moins que le produit ne relie les explications à des journaux faisant autorité, les utilisateurs peuvent recevoir des réponses assurées mais inexactes sur les accès.

Cette limite devrait façonner l’interface. Des questions telles que « Où as-tu obtenu cela ? » devraient renvoyer un enregistrement de provenance structuré plutôt qu’une reconstruction conversationnelle.

Une réponse utile indiquerait le connecteur, l’élément source, l’heure de récupération, l’autorisation accordée et la tâche ayant utilisé les données. Elle devrait également préciser si le contenu provenait d’un appareil local ou d’une copie distante.

C’est ici que les agents grand public diffèrent des outils de connaissance ordinaires. Dans une base de connaissances personnelle conventionnelle, les utilisateurs s’attendent généralement à ce que les éléments ajoutés délibérément deviennent consultables.

Un agent proactif peut déduire à quel moment une information pourrait être utile et la faire remonter sans demande directe. Ce comportement soulève une question de consentement plus difficile : l’utilisateur a-t-il autorisé le simple accès, ou également l’interprétation continue ?

Meta présente Muse comme un produit qui comprend les objectifs et fait progresser le travail en arrière-plan. La proactivité n’est donc pas une fonctionnalité accessoire. Elle fait partie de la proposition de valeur.

Pourtant, une suggestion proactive fondée sur une conversation privée peut sembler intrusive même lorsque l’accès était techniquement autorisé. L’agent a franchi une limite contextuelle en introduisant une communication dans un autre flux de travail.

Le défi des autorisations dépasse donc la simple question de savoir si un interrupteur était activé. Meta doit démontrer que les utilisateurs peuvent prévoir ce qu’un connecteur activé amènera l’agent à faire.

Si l’enquête établit qu’Aten a brièvement activé l’accès, Meta devra tout de même expliquer pourquoi l’interface et l’historique d’activité n’ont pas rendu la synchronisation qui en a résulté évidente.

Si elle conclut qu’aucune autorisation requise n’existait, le problème deviendrait une défaillance directe de sécurité ou d’implémentation. Les éléments actuellement disponibles ne permettent pas de trancher entre ces deux issues.

L’historique de Meta en matière de confiance accroît le coût de l’ambiguïté

Un événement d’accès contesté est plus difficile à contenir lorsque le développeur traîne déjà un long passé de controverses sur la vie privée.

Meta est entrée sur le marché des agents avec un déficit de confiance. Les utilisateurs n’évaluent pas Muse comme le produit isolé d’une start-up sans historique d’entreprise.

L’entreprise fait l’objet depuis des années d’un examen réglementaire, de contentieux et de critiques sur la manière dont Facebook et les services associés ont traité les informations personnelles. Cet historique ne prouve pas l’allégation d’Aten.

Il modifie toutefois le niveau de preuve requis. Un démenti catégorique peut satisfaire les personnes qui se concentrent sur l’architecture documentée des autorisations, tandis que d’autres exigeront les journaux de l’appareil et des serveurs.

Muse a été lancé aux États-Unis le 8 septembre 2026 en tant qu’agent personnel destiné aux adultes. Meta a mis en avant la confidentialité et la sécurité, tout en décrivant une machine virtuelle dédiée pour l’agent de chaque utilisateur.

La couverture du lancement de l’époque indiquait que Muse pouvait gérer des tâches allant des agendas et des achats aux e-mails et aux voyages. L’étendue du produit fait de la confiance une condition de son adoption.

Meta a également publié une application Mac capable de fonctionner avec les fichiers locaux, Messages, Calendrier et Notes lorsque les utilisateurs lui accordent l’autorisation. L’accès au poste de travail donne à Muse un contexte qu’un assistant uniquement web ne peut pas obtenir.

Cet avantage place Meta en concurrence avec d’autres créateurs d’agents qui développent le contrôle du navigateur, l’utilisation de l’ordinateur, le contexte local et la mémoire persistante. Le secteur comprend des produits d’OpenAI, Anthropic, Google et de plus petits développeurs d’agents.

La comparaison pertinente ne porte pas sur l’entreprise qui crée le chatbot le plus capable. Elle porte sur le fournisseur capable de rendre un accès étendu compréhensible, réversible et auditable.

Une préoccupation distincte en matière de sécurité est apparue peu après le lancement de Muse. Le chercheur en sécurité Patrick Wardle a signalé une vulnérabilité impliquant du matériel d’authentification dans l’application Mac, que Meta a corrigée.

Le zero-day signalé impliquait un logiciel malveillant déjà exécuté sous le compte d’un utilisateur, et non le mécanisme allégué par Aten. Il ne doit pas être présenté comme une preuve d’un accès non autorisé à Messages.

Il renforce néanmoins le besoin de visibilité. Les équipes de sécurité et les utilisateurs doivent savoir quelles ressources un agent peut atteindre, quels identifiants il détient et quelles actions ont eu lieu.

Un autre utilisateur, le YouTubeur Matt Robb, a affirmé séparément que Muse avait mal géré une tâche Facebook Marketplace et partagé son adresse avec un acheteur. Meta aurait examiné cet épisode.

Là encore, cette affirmation concerne une action sortante plutôt que l’accès aux Messages d’Aten. Réunir ces événements en un schéma avéré surestimerait les éléments disponibles.

Ensemble, ils illustrent deux aspects du risque lié aux agents. Un agent peut récupérer davantage d’informations que prévu, ou utiliser des informations autorisées dans le cadre d’une action inattendue.

Les autorisations traditionnelles ont été conçues pour les applications ouvrant des fichiers ou utilisant du matériel. Les agents ajoutent la planification, l’inférence, la mémoire et l’exécution interservices après l’octroi de l’accès.

Cela rend la conception selon le principe du moindre privilège plus difficile. Un agent de calendrier peut avoir besoin des titres d’événements, mais pas des pièces jointes. Un agent d’achat peut avoir besoin d’une ville de livraison, mais pas d’une adresse complète avant le paiement.

Muse a besoin de contrôles correspondant à ces distinctions au niveau des tâches. Les connecteurs étendus sont plus simples à construire et à expliquer, mais ils transfèrent davantage de responsabilité d’interprétation aux utilisateurs.

La réputation de Meta signifie que chaque résultat inexpliqué sera interprété à l’aune de défaillances passées. L’entreprise ne peut réduire cette pression qu’avec des éléments que les utilisateurs et les chercheurs indépendants peuvent examiner.

Ce que les autorisations de Meta Muse doivent démontrer

La réponse la plus solide serait un compte rendu reproductible de l’incident et une modification du produit qui facilite la résolution de litiges similaires.

L’explication actuelle de Meta se concentre sur ce que l’application Mac est censée exiger. L’étape suivante consiste à montrer ce qui s’est produit sur l’appareil concerné.

Cela pourrait inclure une chronologie examinée conjointement à partir des journaux de l’application, des enregistrements d’autorisations macOS, de l’historique des connecteurs et des événements de synchronisation côté serveur. Le contenu sensible des messages n’aurait pas besoin d’être rendu public.

L’examen devrait déterminer si et quand l’accès complet au disque a été accordé, ainsi que l’exécutable qui l’a reçu. Il devrait identifier le moment où l’état du connecteur Messages a changé et l’action de l’utilisateur qui a provoqué ce changement.

Il devrait également expliquer la ligne 187,462. Si ce nombre correspondait à un curseur local plutôt qu’à un enregistrement de contenu téléversé, Meta devrait décrire la différence en langage clair.

Si des données de messages ont atteint les systèmes de Meta, l’entreprise devrait expliquer leur périmètre, leur conservation et leur statut de suppression. Si elles n’ont jamais quitté le Mac, elle devrait montrer comment Muse a généré les suggestions.

L’entreprise devrait éviter de s’appuyer sur l’explication fournie par l’agent lui-même. Meta a déjà indiqué que Muse était confus lorsqu’il décrivait la synchronisation des notifications, ce qui rend cette réponse peu fiable comme élément de preuve.

Un registre d’activité offrirait une meilleure réponse. Chaque suggestion pourrait inclure un contrôle « Pourquoi est-ce que je vois cela ? » relié à des enregistrements système immuables.

Le registre devrait distinguer la récupération de l’action. Lire un message pour répondre à une demande directe est différent de l’indexation continue de conversations ou de l’envoi d’informations vers un autre service.

Les écrans d’autorisation devraient également présenter les conséquences avant l’activation. « Lire Messages » est moins informatif que « synchroniser l’historique des messages et l’utiliser pour des suggestions proactives ».

Les utilisateurs ont besoin d’un choix distinct pour la synchronisation historique, la surveillance continue et la récupération propre à une tâche. Ces contrôles permettraient d’accorder l’accès sans accepter toutes les formes de proactivité.

La révocation doit être tout aussi claire. Lorsqu’un utilisateur désactive l’accès, Muse devrait indiquer s’il a supprimé les données mises en cache, cessé toute nouvelle collecte ou simplement déconnecté la source active.

Pour les acheteurs en entreprise, les administrateurs exigeront probablement des enregistrements d’audit exportables et des politiques de connecteurs. Les consommateurs méritent une version lisible de cette même responsabilité.

Un compte rendu indépendant a résumé les positions concurrentes sans les résoudre. Aten affirme que la base de données s’est synchronisée alors que l’accès était désactivé, tandis que Meta affirme que les protections requises ne peuvent pas être contournées.

Cet écart de vérification est le sujet. Présenter l’une ou l’autre affirmation comme une conclusion technique établie irait au-delà des éléments disponibles.

Meta pourrait réduire cet écart en publiant une analyse détaillée après incident. Le document devrait couvrir le comportement observé, la méthode d’enquête, les conclusions, les limites et toute mesure corrective.

Si l’entreprise conclut que les actions de l’utilisateur ont activé le connecteur, elle devrait démontrer ces actions par des enregistrements plutôt que par insinuation. Les utilisateurs oublient leurs réglages, mais les logiciels devraient conserver une piste d’audit.

Si elle découvre un problème d’interface ou de gestion d’état, reconnaître ce problème ne validerait pas nécessairement chaque allégation. Cela montrerait que l’entreprise traite les signalements d’accès inattendu comme des éléments d’ingénierie.

Un programme de bug bounty est utile pour les vulnérabilités, mais cet incident peut se situer à la frontière entre la sécurité, la conception du produit et le comportement du modèle. Cette frontière exige une gestion des incidents plus large que la seule divulgation d’exploits.

La norme plus large devrait être simple : les utilisateurs ne devraient pas avoir à faire confiance ni à l’explication d’un agent ni au schéma d’architecture d’une entreprise. Ils devraient pouvoir examiner ce qui s’est passé.

Trois signaux détermineront le débat sur la confidentialité de Meta Muse

La phase suivante devrait être évaluée selon les preuves techniques, la refonte des autorisations et les témoignages d’autres utilisateurs, dans cet ordre.

Le premier signal est une reconstitution documentée du cas d’Aten. Un compte rendu crédible établirait la chronologie des autorisations, identifierait le processus ayant accédé aux données et préciserait si elles ont atteint une infrastructure distante.

Ces éléments renforceraient la position de Meta s’ils montraient une autorisation explicite suivie d’une synchronisation attendue. Ils affaibliraient le démenti de l’entreprise si l’accès s’était produit sans l’approbation requise du système d’exploitation.

Le constat que les enregistrements sont insuffisants serait également important. Un agent qui traite des communications privées devrait conserver suffisamment de métadonnées pour enquêter sur un événement d’accès contesté sans exposer le contenu des messages.

Le deuxième signal est une modification des contrôles d’autorisation et de provenance. Meta peut conclure que son architecture a fonctionné correctement tout en décidant que les utilisateurs ont besoin de choix plus clairs.

Surveillez l’apparition de contrôles distincts régissant les importations historiques, la surveillance en direct, les suggestions proactives, la conservation et les actions sortantes. Surveillez également les explications au niveau des sources reliées aux journaux d’audit.

De tels changements indiqueraient que Meta reconnaît la différence entre une autorisation formelle et des attentes éclairées. L’absence de changement laisserait la même ambiguïté en place pour de futurs litiges.

Le troisième signal est de savoir si des utilisateurs ou chercheurs indépendants reproduisent le comportement. Un seul témoignage peut révéler un problème sérieux, mais des résultats répétés dans des conditions documentées établiraient un schéma technique plus solide.

Les chercheurs devraient consigner la version de macOS, la version de Muse, le chemin d’installation, les processus auxiliaires, l’état du connecteur et la séquence exacte des choix d’autorisation. Sans ces détails, des signalements apparemment similaires peuvent impliquer des mécanismes différents.

L’absence d’autres signalements ne prouverait pas qu’Aten s’est trompé. Elle réduirait les éléments en faveur d’un défaut généralisé tout en laissant son expérience individuelle non résolue.

Meta devrait également publier des notes de version propres à chaque version pour tout correctif pertinent. Des modifications discrètes rendraient plus difficile la détermination de la question de savoir si des tests ultérieurs évaluent le même logiciel qu’Aten a utilisé.

Pour les utilisateurs qui envisagent Muse aujourd’hui, la réponse pratique n’est ni la panique ni une confiance aveugle. Vérifiez l’accès complet au disque de macOS ainsi que chaque connecteur dans Muse avant d’ajouter des données privées.

Utilisez un profil de test ou un appareil distinct lorsque vous évaluez le comportement d’un nouvel agent. Commencez avec des sources limitées, inspectez son activité et n’élargissez l’accès qu’après avoir vérifié que ses suggestions correspondent à vos attentes.

Pour les développeurs et les acheteurs en entreprise, la leçon va au-delà de Meta. Les autorisations des agents doivent être observables au moment de l’accès et explicables après coup.

Le différend sur la confidentialité de Meta Muse reste non résolu, car les éléments publics documentent un conflit, et non un mécanisme vérifié. Meta a décrit des garde-fous, et Aten a décrit un résultat que ces garde-fous devraient empêcher.

Qu’est-ce qui gagnerait votre confiance : une nouvelle assurance catégorique, ou une piste d’audit montrant exactement quand un agent a accédé à vos données, pourquoi il l’a fait et ce qui s’est passé ensuite ?