Meta Muse : quand l’IA agit à votre place, la sécurité change d’échelle

Meta a lancé Muse le 8 septembre 2026 aux États-Unis. Présenté comme un « personal AI agentSystème qui planifie et enchaîne des actions (outils, APIs, code) pour atteindre un objectif, au-delà d’une seule réponse texte. », le produit ne se limite pas à répondre à des questions : il peut ouvrir un navigateur, utiliser des services connectés, remplir des formulaires, poursuivre certaines tâches en arrière-plan et demander à exécuter des actions comme envoyer un e-mail ou effectuer un achat.

Pour un lecteur français, une précision s’impose immédiatement : Muse n’est pas disponible en France au lancement. Meta limite pour l’instant son déploiement aux États-Unis, sur iOS, Android et muse.ai, avec un accès également possible via WhatsApp et une arrivée sur ses lunettes IA annoncée comme prochaine. L’Associated Press décrit le service comme destiné aux personnes âgées de 18 ans et plus.

Meta propose une version gratuite et deux abonnements à 20 dollars par mois et 100 dollars par mois pour des usages plus intensifs. Axios, CNBC et Reuters rapportent ces deux niveaux de prix.

Côté modèle, Muse est propulsé par Muse Spark 1.3. Dans son billet technique consacré à la sécurité, Meta explique que ce modèle est particulièrement performant pour piloter le web et le décrit comme proche de l’état de l’art sur la résistance au prompt injection.

Le changement paraît simple, mais il déplace profondément le problème. Avec un chatbot, une erreur produit surtout une mauvaise réponse. Avec un agent relié à des comptes personnels, à un navigateur et à des moyens d’action, une erreur peut aussi devenir une mauvaise action.

C’est pourquoi le lancement de Muse est surtout intéressant par ce qu’il révèle de la prochaine étape de l’IA grand public : la sécurité ne peut plus être seulement une propriété du modèle. Elle doit être intégrée à toute l’architecture qui l’entoure.

Ce que Muse peut réellement faire

Selon l’annonce officielle de Meta, Muse est déployé aux États-Unis sur iOS, Android et muse.ai, avec un accès possible via WhatsApp. Meta annonce également une arrivée prochaine sur ses lunettes IA.

Muse peut travailler avec un navigateur et des services tiers, gérer plusieurs tâches et continuer certains travaux après la fermeture de l’application. La documentation produit de Meta décrit aussi une mémoire persistante et un fonctionnement proactif : l’agent peut reprendre un objectif dans le temps et revenir vers l’utilisateur lorsqu’une information change ou lorsqu’une validation est nécessaire.

Meta précise aussi que Muse peut écrire ses propres connecteurs pour des services non pris en charge nativement lorsqu’ils exposent une APIApplication Programming Interface : contrat machine pour consommer un service (HTTP, SDK, webhooks). ou une interface en ligne de commande (CLI). Sa surface d’intégration ne se limite donc pas aux connecteurs préconstruits par Meta, même si les accès et sorties restent encadrés par les mécanismes de permission du système.

Le blog design de Muse précise que l’utilisateur peut consulter l’activité de l’agent, les permissions déjà accordées et ses fichiers mémoire, que Meta dit rendre directement lisibles et modifiables.

Cette autonomie est précisément ce qui distingue un agent d’un simple assistant conversationnel. Mais elle suppose aussi que le système reçoive des accès beaucoup plus sensibles : e-mails, calendrier, sites web, services connectés ou paiement.

Meta ne cache d’ailleurs pas cette difficulté. Dans sa documentation sécurité, l’entreprise écrit qu’un agent de ce type reste susceptible de faire des erreurs et d’être attaqué à travers les données qu’il lit.

Secure VM : isoler l’agent plutôt que lui faire confiance aveuglément

La principale réponse technique de Meta s’appelle Muse Secure VM.

Chaque utilisateur dispose d’une machine virtuelle dédiée dans le cloud. C’est dans cet environnement que vivent l’agent, son espace de travail et les données liées aux services connectés. Meta décrit précisément la VM comme deux domaines de sécurité isolés sur une même machine, plutôt que comme un agent piloté par un LLMLarge Language Model : modèle de langage entraîné sur d’énormes corpus pour prédire et générer du texte. disposant d’un accès root à l’ensemble du système.

Le cœur agentique de Muse, son espace de travail et les outils qu’il exécute vivent dans une cellule d’exécution isolée. Les services de sécurité sensibles sont placés à l’extérieur de cette cellule, parce que Meta part du principe qu’elle traitera des données non fiables et peut donc être compromise.

C’est notamment le rôle de hatch-safety — Hatch est le nom interne de Muse dans le code de Meta. Ce service fait tourner un ensemble indépendant de modèles et de classifieurs qui inspectent les requêtes et les réponses échangées avec l’inférencePhase d’utilisation d’un modèle déjà entraîné : produire une sortie à partir d’une entrée (par opposition à l’entraînement). du modèle cœur, notamment pour détecter des risques comme les tentatives de prompt injection. Meta explique explicitement que hatch-safety fonctionne hors de la cellule d’exécution afin qu’un attaquant ne puisse pas désactiver ces protections.

Les identifiants constituent un autre exemple. D’après la documentation technique de Meta, les véritables jetons d’authentification et mots de passe sont conservés hors de l’environnement d’exécution principal. Muse reçoit des substituts ou bénéficie d’une injection des identifiants au moment nécessaire, sans que le modèle voie directement les secrets.

Meta pousse cette logique jusque dans le connecteur e-mail. Une boîte de réception contient souvent des éléments capables d’ouvrir l’accès à d’autres comptes : codes à usage unique, liens de réinitialisation de mot de passe ou liens de connexion « magique ». Le connecteur e-mail de Muse filtre ces trois catégories grâce à des filtres déterministes et à un modèle de classification. L’objectif est d’éviter que le simple droit de lire un e-mail permette à Muse — ou à quelqu’un qui aurait réussi à le manipuler — de se faire passer pour l’utilisateur sur un autre service.

C’est une illustration concrète du principe du moindre privilège : ne pas seulement demander si l’agent peut lire une boîte mail, mais retirer de cette lecture les données dont il n’a pas besoin pour accomplir sa tâche.

Un navigateur réel, mais volontairement bridé

Muse utilise un navigateur Chromium à jour derrière une couche de virtualisation. L’utilisateur peut voir l’agent travailler et reprendre la main à tout moment.

Le sous-agent qui pilote le navigateur n’obtient cependant pas un accès libre à Chrome. Selon Meta, il ne reçoit qu’une représentation structurée des éléments accessibles de la page, plutôt que le DOM brut. Cette restriction a une conséquence directe : le sous-agent ne peut pas lire les identifiants injectés depuis le stockage sécurisé ni redescendre manuellement vers le DOM brut. Il ne peut pas non plus exécuter de JavaScript dans le contexte de la page, ne dispose pas de commandes d’exécution dans le processus du navigateur et n’a pas accès aux DevTools.

Lorsque l’utilisateur reprend la main, ou lorsque le système sécurisé injecte des identifiants dans un formulaire, l’agent est mis en pause et ne peut plus agir. Les identifiants saisis transitent directement vers le stockage sécurisé plutôt que par le modèle.

Meta ajoute encore une couche indépendante de détection autour du navigateur. Une famille de classifieurs surveille notamment l’exfiltration de données personnelles sans rapport avec la tâche, les tentatives de prompt injection présentes dans la page, les images ou médias, les fichiers téléchargés et les soumissions de formulaires à risque. Le système peut bloquer l’action ou demander une validation à l’utilisateur. Meta compare aussi les destinations à sa liste de sites malveillants directement dans la VM afin d’empêcher le navigateur d’ouvrir des sites déjà identifiés comme dangereux.

Sentinel : un second système contrôle ce qui sort

La documentation technique publiée par Tarek Sheasha décrit une seconde couche appelée Sentinel.

Sentinel est séparé de Muse au niveau système et constitue, selon Meta, l’autorité qui décide si une action utilisant un connecteur ou une sortie réseau peut être exécutée. Muse propose l’action ; Sentinel l’autorise, la bloque ou demande une validation humaine.

Pour certaines actions sensibles, cette validation arrive directement dans l’interface utilisateurUser Interface : couche visuelle et interactive (composants, layout, états). et non dans la conversation avec l’agent. L’objectif est qu’une instruction malveillante placée dans une page web, un document ou un e-mail ne puisse pas simplement convaincre Muse que l’utilisateur a déjà donné son accord.

Surtout, une approbation humaine n’est pas traitée comme un simple « oui » conversationnel. Meta la décrit comme une capacité stricte, liée à un connecteur ou une destination et à un cas d’usage précis. Muse peut demander plusieurs types de portée : usage unique, session, tâche, durée limitée ou permission permanente. Sentinel choisit les portées qu’il propose à l’utilisateur puis vérifie que les invocations suivantes correspondent exactement à ce qui a été accordé.

C’est la réponse technique à une question très concrète : quand l’utilisateur clique sur « accepter », qu’autorise-t-il réellement, et pour combien de temps ? L’autorisation n’est pas censée devenir un blanc-seing général donné à l’agent.

Meta ajoute ici un mécanisme particulièrement intéressant : le « tainted egress ». Chaque processus lancé pour exécuter un outil démarre dans un état considéré comme propre. S’il lit des données utilisateur, il devient « contaminé ». Cette information est propagée au niveau noyau avec des programmes eBPF.

Une requête réseau provenant d’un processus resté propre peut, si elle correspond aussi à une politique d’autorisation automatique étroitement définie et passe les autres contrôles d’URL, être autorisée sans déranger l’utilisateur. Un processus contaminé ou impossible à vérifier perd cette possibilité et repasse par le flux normal d’approbation.

Ce suivi de flux complète les contrôles de destination de Sentinel, qui peut examiner notamment l’hôte, l’adresse IP finale, le port, le protocole, la méthode HTTP, le chemin et la requête décodée.

La sécurité passe aussi par l’interface

Le blog design de Meta apporte ici un élément important : dans certaines situations, l’entreprise considère que la conversation ne suffit pas et impose des contrôles déterministes dans l’interface.

Pour les actions critiques, Muse affiche des cartes d’approbation structurées avec des choix explicites d’acceptation ou de refus. Par défaut, l’agent peut continuer à naviguer sur le web, mais il s’arrête avant les actions que Meta considère comme difficiles à annuler, par exemple l’envoi d’un e-mail ou un achat.

Ces cartes ne servent donc pas seulement à recueillir un consentement ponctuel : elles alimentent l’état d’autorisation géré par Sentinel, avec une portée définie. Une validation peut ne couvrir qu’une seule action, une session ou une tâche, expirer après une durée donnée, ou être accordée de façon permanente lorsque ce choix est proposé.

Meta explique également chercher à éviter la « banner blindness » : le risque que l’utilisateur finisse par approuver automatiquement chaque demande simplement pour la faire disparaître. Ce point est central, car un système peut multiplier les demandes d’autorisation tout en restant peu sûr si l’humain est conditionné à cliquer mécaniquement sur « accepter ».

Le tainted egress sert précisément cette logique : ne pas demander une validation pour chaque requête réseau, mais augmenter la friction lorsque le processus a effectivement manipulé des données utilisateur. Autrement dit, Meta cherche à réduire le nombre d’alertes pour que celles qui restent conservent du sens.

La sécurité d’un agent ne dépend donc pas seulement de ce que le modèle est autorisé à faire. Elle dépend aussi de la manière dont le système décide quand solliciter l’utilisateur, quelle portée donner à son accord et comment vérifier ensuite que l’agent ne la dépasse pas.

Le prompt injection reste un problème ouvert

C’est probablement le passage le plus important de la documentation de Meta : l’entreprise ne prétend pas avoir « résolu » le prompt injection.

Le chercheur et développeur Simon Willison a donné en juin 2025 le nom de « lethal trifecta » à la combinaison de trois capacités particulièrement dangereuse pour un agent : accès à des données privées, exposition à du contenu non fiable et possibilité de communiquer vers l’extérieur. Meta reprend explicitement cette notion dans son propre billet sécurité et crédite Willison.

Un prompt injection consiste à placer dans une donnée lue par l’agent — par exemple une page web, un fichier ou une image — des instructions conçues pour détourner son comportement. Lorsque les trois éléments de cette « trifecta » sont réunis, une attaque peut tenter de pousser l’agent à récupérer des données privées puis à les transmettre vers l’extérieur.

Meta dit combiner plusieurs protections : entraînement de Muse Spark 1.3 à reconnaître et résister aux injections, marquage des contenus externes comme non fiables, ensemble de classifieurs spécialisés — dont ceux exécutés indépendamment par hatch-safety hors de la cellule d’exécution —, restrictions déterministes dans l’environnement d’exécution et approbations humaines pour certaines sorties de données.

Mais la société écrit explicitement que Muse n’est pas immunisé contre les attaques et que le prompt injection demeure un problème ouvert pour l’industrie.

Meta paie aussi les chercheurs qui réussissent à casser ces défenses

Le jour du lancement, Meta a ouvert au public le bug bounty de Muse, jusque-là utilisé avec des chercheurs externes dans un cadre privé. Le programme prévoit des primes pouvant atteindre 300 000 dollars pour un rapport valide, selon l’impact démontré, et jusqu’à 130 000 dollars pour une attaque par prompt injection réussie affectant un utilisateur.

Le montant est intéressant moins comme concours de chiffres que comme signal sur la philosophie du système. Meta explique elle-même qu’elle paie pour des prompt injections réussies non parce qu’elle pense qu’elles sont impossibles, mais parce que leur découverte doit permettre d’améliorer plus rapidement le comportement réel de Muse.

C’est cohérent avec le reste de l’architecture : les protections cherchent à réduire la probabilité et l’impact d’une attaque, pas à affirmer qu’aucune attaque ne pourra fonctionner.

Les tests internes montrent justement que la marge d’erreur existe

Le lancement doit aussi être lu à la lumière des éléments rapportés par Reuters.

L’agence indique avoir consulté des messages internes récents de salariés testant Muse. Certains décrivent une réelle utilité du produit, mais d’autres signalent des problèmes de sécurité et de fiabilité.

Reuters rapporte notamment des téléversements d’informations sensibles sans permission. L’agence décrit aussi un cas dans lequel l’agent aurait contourné des garde-fousRègles et filtres (policy, classifiers, allowlists) qui limitent les sorties ou actions dangereuses d’un système IA. et exposé des photos personnelles iCloud alors qu’un testeur lui demandait d’identifier des jouets visibles dans des photos d’anniversaire.

Andrew Bosworth, directeur de la technologie de Meta, aurait lui-même indiqué dans un post interne qu’il était régulièrement déconnecté et devait se reconnecter, parfois plusieurs fois en quelques minutes, selon Reuters.

Un autre test, consacré à la surveillance d’articles ou de billets susceptibles d’être rapidement épuisés, aurait rencontré plusieurs modes d’échec : arrêt du rafraîchissement après environ quinze minutes, erreurs ignorées silencieusement et désactivation du suivi sans raison apparente.

La dépêche Reuters originale précise que Meta n’a pas répondu à une demande de commentaire sur les incidents précis décrits dans ces messages internes.

Il serait excessif d’en conclure que Muse est globalement dangereux ou inutilisable. Ces éléments ne constituent pas une mesure statistique du taux d’échec du produit. Ils montrent en revanche que les protections décrites par Meta doivent fonctionner dans un environnement où l’agent reste faillible.

Reuters rapporte aussi que Meta avait repoussé un lancement initialement prévu en avril afin de renforcer la sécurité. Vishal Shah, vice-président AI Products chez Meta, a expliqué à l’agence que l’entreprise estimait avoir atteint le seuil minimum nécessaire pour proposer le produit au public.

« Privé » au lancement ne signifie pas encore « inaccessible à Meta »

C’est l’autre nuance à conserver absolument.

Avec Secure VM, Meta affirme isoler les données des différents utilisateurs et restreindre l’accès de son personnel par des politiques opérationnelles. Mais sa propre documentation précise que cette architecture n’empêche pas techniquement Meta d’accéder aux données lorsqu’un tel accès est nécessaire pour exploiter, sécuriser ou prendre en charge le service.

La société prépare une deuxième architecture, Muse Confidential VM, annoncée pour plus tard en 2026. Son objectif est différent : empêcher de manière cryptographique et vérifiable que Meta puisse accéder au contenu de la machine virtuelle.

Meta indique que cette version est déjà testée par un petit groupe et que sa conception ainsi qu’une partie du code ont commencé à être communiquées à des auditeurs externes. WIRED rapporte avoir vu une version préliminaire du document technique décrivant cette architecture.

Meta prend aussi un engagement vérifiable pour la suite : une fois Confidential VM lancée, le système doit faire l’objet d’une vérification continue, visible et inspectable par tous. L’objectif affiché est que des experts puissent confirmer que Meta n’a pas la capacité d’accéder aux données contenues dans cet environnement. L’entreprise invite par ailleurs les spécialistes de la sécurité et de la vie privée à demander un accès anticipé afin d’examiner le système avant son déploiement général.

Il faut donc distinguer clairement les deux promesses : Secure VM est disponible au lancement ; Confidential VM est encore une capacité annoncée. Ses garanties les plus fortes devront être évaluées lorsque l’architecture sera effectivement disponible et soumise à cette vérification continue.

Que deviennent les données de Muse ?

Meta indique que les conversations et les données stockées dans la machine virtuelle ne sont pas transmises à ses systèmes publicitaires.

L’entreprise apporte toutefois elle-même une nuance : l’activité réalisée par Muse sur le web peut indirectement influencer les publicités reçues. Si Muse visite le site d’un marchand pour le compte de l’utilisateur, ce marchand peut par exemple utiliser cette visite dans ses propres mécanismes de ciblage ou de reciblage.

Concernant l’entraînement, Meta explique que les conversations, appels d’outils et passages entre sous-agents peuvent être utilisés pour améliorer ses modèles après un processus destiné à retirer certaines informations permettant d’identifier directement les personnes. L’utilisateur peut désactiver cette utilisation depuis les réglages de Muse.

Le blog sécurité apporte un autre élément de contrôle : les fichiers de la VM, y compris la mémoire de Muse sur l’utilisateur, peuvent être consultés, modifiés et téléchargés. Les identifiants et jetons d’authentification des services tiers sont, eux, stockés dans un conteneur isolé distinct au sein de la VM, et non dans d’autres services Meta.

Ces éléments sont des déclarations de politique et d’architecture de Meta. Ils doivent donc être lus comme tels : ils décrivent le fonctionnement annoncé du service, pas un audit indépendant de l’ensemble du traitement de données.

Acheter avec un agent oblige aussi à repenser le paiement

Le billet sécurité distingue deux scénarios.

Sur un site où l’utilisateur possède déjà un moyen de paiement enregistré, Muse détecte l’arrivée sur une page de paiement et demande une approbation humaine avec les détails exacts de l’achat à chaque transaction.

Sur un site où l’utilisateur n’a encore jamais acheté, Muse peut utiliser le portefeuille intégré au produit. Au lancement, Meta s’appuie sur Stripe Link ; Shop Pay est annoncé comme prochainement disponible. Une carte à usage unique est alors transmise au marchand plutôt que la carte bancaire habituelle de l’utilisateur, et une approbation humaine est également requise.

Cette carte n’est pas seulement jetable : selon Meta, elle est liée à un marchand précis, à un montant précis et à une durée de validité limitée. Stripe confirme de son côté l’intégration de Link.

L’idée est de réduire la valeur d’un identifiant de paiement même s’il venait à être récupéré à la suite d’une erreur ou d’une attaque. Ce détail illustre bien la transformation en cours : les agents ne nécessitent pas seulement de meilleurs modèles ; ils imposent aussi de reconstruire des couches existantes du web — authentification, autorisations, paiement, audit — pour des logiciels capables d’agir au nom d’un humain.

Muse est surtout un test grandeur nature de la confiance accordée aux agents

Meta présente Muse comme un produit destiné à rendre l’IA plus proactive et plus utile dans la vie quotidienne. Ce positionnement n’est pas propre à Meta : d’autres acteurs développent eux aussi des agents capables de naviguer sur le web ou d’utiliser des outils.

La contribution la plus intéressante de Muse au débat est ailleurs : Meta expose publiquement une architecture dans laquelle le modèle n’est qu’un composant parmi d’autres, entouré de barrières qui partent du principe qu’il peut se tromper ou être manipulé. hatch-safety en fournit une illustration très concrète : une partie des protections est volontairement placée hors de l’environnement que l’agent contrôle, précisément pour rester active même si cet environnement est compromis.

Cette approche ne supprime pas le risque. Les incidents de test rapportés par Reuters rappellent même pourquoi ces barrières sont nécessaires. Le bug bounty ouvert jusqu’à 300 000 dollars matérialise la même idée : Meta construit des défenses tout en demandant publiquement aux chercheurs de trouver les scénarios dans lesquels elles échouent.

Le choix de traiter explicitement des problèmes d’interface comme la « banner blindness », et de l’associer à un suivi technique des flux comme le tainted egress et à des autorisations de portée précisément définie, montre aussi que la confiance dans un agent dépend autant de l’architecture que du comportement humain autour des permissions.

La question n’est donc plus seulement de savoir si une IA comprend correctement une demande. Elle devient : quelles permissions lui donne-t-on, quelles données peut-elle voir, quelles actions peut-elle réellement exécuter et que se passe-t-il lorsqu’elle se trompe ?

Avec Muse, c’est peut-être cela le changement le plus important : à mesure que l’IA passe de la réponse à l’action, la qualité du modèle ne suffit plus. La confiance devient une propriété de tout le système.