La permission était faite pour les sauvegardes

Le 2 octobre, Apple a publié une courte note sur sa page d'actualités pour développeurs, intitulée Updates to Full Disk Access in macOS. Elle explique pourquoi ce réglage existe : « l'Accès complet au disque contourne en grande partie ces contrôles afin de permettre aux apps de sauvegarde de fonctionner correctement sur le Mac ». Puis elle décrit ce que certains développeurs en ont fait : « exposer tout ce qui se trouve sur leur système, y compris les fichiers, les mails, les messages et même l'historique de navigation, sans que les utilisateurs le sachent et le comprennent pleinement ».

Apple ajoutera des contrôles pour que les utilisateurs qui veulent accorder cet accès « ne puissent le faire que par une action très explicite ». Elle a aussi donné une raison d'agir maintenant : « À mesure que les agents d'IA deviennent plus capables et plus autonomes, les risques liés à ce niveau d'accès vont considérablement augmenter. »

Apple n'a donné aucune date et n'a pas dit ce qu'il adviendra des autorisations déjà accordées. La note montre en revanche clairement ce qu'Apple pense de l'Accès complet au disque entre les mains d'un agent.

Deux affaires en deux semaines

La couverture de la note, à commencer par TechCrunch, l'a reliée à deux incidents.

Muse et la base de données Messages. Le 19 septembre, Jason Aten, chroniqueur chez Inc., a raconté que l'agent Muse de Meta, sur son Mac, lui avait envoyé une notification suggérant une chronique tirée d'une conversation qu'il venait d'avoir avec le coanimateur de son podcast. Il affirme avoir refusé à Muse l'accès à Messages, et avoir pourtant découvert que Muse avait synchronisé sa base de données Messages jusqu'à la ligne 187 462, alors que les réglages de Muse indiquaient l'Accès complet au disque désactivé. Meta conteste ce récit. David Singleton, de Meta Superintelligence Labs, a déclaré que Muse ne peut lire Messages qu'après « trois étapes distinctes d'autorisations au niveau de l'application et de protections intégrées au niveau du système macOS » qui « ne peuvent pas être contournées même si l'application Muse avait un bug ». Muse lui-même a dit à Aten qu'il synchronisait ses « notifications de l'appareil ».

Patrick Wardle, de l'Objective-See Foundation, a résumé ce que signifie cette permission une fois qu'une app l'a obtenue : « n'importe quel fichier (hors root) est lisible, l'historique de navigation, les cookies du navigateur, les conversations, etc. »

L'app ChatGPT pour Mac. La même semaine, Wired a fait état d'une faille trouvée par Wardle dans l'app ChatGPT d'OpenAI pour macOS, CVE-2026-100754. L'app décidait à quels processus locaux faire confiance d'après leur signature de code et leur ascendance. Un interpréteur de scripts de confiance pouvait recevoir une entrée non fiable, ce qui permettait à du code ordinaire déjà en cours d'exécution sur le Mac de se glisser dans une chaîne de processus acceptée et de piloter les fonctions de confiance de l'app : l'historique des conversations et les intégrations connectées, comme les sessions de navigateur. OpenAI l'a corrigée dans la build 26.924.20706, en production depuis le 25 septembre. Personne n'a signalé d'exploitation dans la nature.

Les deux affaires partent de la même prémisse. Un agent sur le Mac s'exécute en votre nom, et tout ce qu'il peut lire, n'importe quel code qui prend le contrôle de l'agent peut le lire aussi.

Le terminal avait déjà dit oui

Muse a demandé l'Accès complet au disque via les Réglages Système, comme le prévoit le modèle d'Apple. Un agent de code en terminal ne demande rien et s'exécute avec les autorisations du terminal.

macOS vérifie les permissions de confidentialité par rapport à l'app responsable, qui pour un outil en ligne de commande est le terminal qui l'a lancé. Beaucoup de développeurs ont accordé l'Accès complet au disque à Terminal, à iTerm ou à leur éditeur il y a des années, pour faire taire les demandes que find, rsync ou un script de sauvegarde déclencheraient sinon. Chaque processus lancé depuis cette fenêtre hérite de l'autorisation. Cela inclut Claude Code, Codex et Gemini CLI, ainsi que chaque script postinstall d'npm install, chaque serveur MCP qu'ils lancent et chaque commande en une ligne qu'un README les a convaincus d'exécuter.

Dans cette configuration, les fichiers listés par Apple sont à la portée de l'agent et de tout ce que l'agent exécute :

• ~/Library/Messages/chat.db, l'historique Messages que Muse est accusé d'avoir synchronisé
• ~/Library/Mail, toutes les boîtes aux lettres
• l'historique et les cookies de Safari, sous ~/Library/Safari et dans son conteneur
• Notes, les bibliothèques Photos et les conteneurs privés des autres apps

Les secrets n'ont jamais été derrière la demande

Le changement d'Apple est le bon, et il couvre les fichiers que l'on considère comme privés. Les identifiants de travail d'un développeur sont ailleurs. Ces chemins ne sont protégés ni par l'Accès complet au disque, ni par aucune autre permission de confidentialité de macOS :

• ~/.ssh/id_ed25519
• ~/.aws/credentials et ~/.aws/sso/cache/
• ~/.config/gh/hosts.yml, ~/.git-credentials, ~/.npmrc, ~/.docker/config.json, ~/.kube/config
• le fichier .env de chaque projet que vous avez cloné
• les jetons OAuth et les transcriptions de session de l'agent lui-même

N'importe quel processus qui s'exécute sous votre utilisateur peut les lire, avec ou sans Accès complet au disque. Les nouveaux contrôles d'Apple rendront une grosse permission plus difficile à accorder. Un agent de code sur un portable n'avait pas besoin de cette permission pour atteindre les fichiers qui permettent à un attaquant de pousser dans vos dépôts ou d'ouvrir votre compte AWS. Les infostealers qui ciblent les agents de code récoltent déjà ces fichiers : jetons d'accès et de rafraîchissement, configurations MCP, historiques de prompts.

Avant de vérifier quelles apps détiennent l'Accès complet au disque, regardez ce que contient l'ordinateur de l'agent.

Dans Bromure, l'agent n'est pas un processus du Mac

Bromure Agentic Coding exécute les agents de chaque machine dans une VM Ubuntu, sous le Virtualization.framework d'Apple. Claude Code, Codex, Grok et les autres sont des processus Linux sur un noyau Linux. Les permissions de confidentialité de macOS ne s'appliquent pas à eux, parce qu'ils n'ouvrent jamais un fichier sur le système de fichiers du Mac. Il n'y a aucune autorisation à hériter et aucun terminal dont les permissions fuiraient vers l'agent, car le terminal que vous voyez dans Bromure est rattaché à la VM, pas au shell de votre Mac.

Ce que la VM peut voir tient en une courte liste :

• Son propre disque système, un clone copy-on-write d'une image Ubuntu signée.
• Son propre dossier personnel, /home/ubuntu, sur une image disque privée.
• Les dossiers que vous avez partagés avec cette machine, jusqu'à huit, chacun monté par son nom dans le dossier personnel. Si vous partagez ~/code/payments, l'agent voit ~/payments. Il ne voit pas ~/code, et il ne voit jamais ~/Library.
• Un petit partage de configuration par démarrage, en lecture seule, qui contient les réglages du proxy et les identifiants de substitution.

chat.db n'est pas sur cette liste, pas plus que Mail ou l'historique de Safari. Une tâche de synchronisation à la Muse, ou un agent victime d'une injection de prompt à qui l'on dit de « résumer mes messages récents pour le contexte », constate que ~/Library/Messages n'existe pas. Aucun chemin de la VM ne mène là.

Les secrets de développeur sont des substituts

Voilà pour la liste d'Apple. Bromure couvre aussi celle que la note d'Apple laisse de côté : les dotfiles.

Les vrais identifiants restent chiffrés sur le Mac. La VM reçoit des substituts qui ont la bonne forme : GH_TOKEN vaut ghp_ suivi de 36 caractères que GitHub refuserait, ANTHROPIC_API_KEY vaut sk-ant-api03-brm-…, et ~/.git-credentials, ~/.docker/config.json et ~/.kube/config contiennent des faux. Le proxy sur le Mac place la vraie valeur sur une requête une fois qu'elle a quitté la VM, et seulement quand la requête se dirige vers l'hôte auquel cet identifiant appartient. Pour reprendre les mots du manuel : « Aucun fichier, aucune variable d'environnement, aucun processus dans la VM ne contient jamais une vraie clé d'API, un jeton OAuth, un secret AWS ou une clé privée SSH. »

Deux détails répondent à l'inquiétude d'Apple sur les autorisations trop larges :

• L'import AWS demande un seul dossier, sur le Mac. Pour importer vos profils AWS, Bromure demande une autorisation security-scoped sur ~/.aws uniquement. Le dossier est lu sur le Mac et n'est jamais monté dans la VM. C'est l'autorisation étroite et explicite que réclame la note d'Apple, et elle va à l'app hôte, jamais à l'agent.
• Les clés SSH restent sur le Mac. Le SSH_AUTH_SOCK de la VM est un pont vers un agent sur le Mac. L'invité peut demander des signatures, et les octets de la clé privée n'entrent jamais dans la VM. Votre ssh-agent de session macOS ne lui est jamais exposé.

Quand Claude Code se connecte via Bromure, le flux OAuth se déroule dans le navigateur de votre Mac et les jetons sont stockés sur le Mac. Le ~/.claude de la VM ne contient aucun vrai jeton. C'est pourtant le fichier que recherchent les infostealers qui visent les agents de code.

Le navigateur a lui aussi son propre disque

Apple a cité l'historique de navigation, et Wardle les cookies. Dans Bromure, l'agent a un navigateur, un Chromium complet qu'il pilote via le serveur MCP browser intégré. Il tourne dans une seconde VM jetable, distincte de la machine de l'agent et de votre Mac. Par défaut, son disque est un clone temporaire supprimé à la fermeture du navigateur, si bien que cookies, connexions et historique disparaissent avec lui. Il n'a pas accès à l'historique de Safari ni à votre profil Chrome de bureau, puisque ceux-ci vivent sur le Mac.

Tout ce qui sort traverse le Mac

Supposons qu'un agent réussisse à rassembler quelque chose qui vaille la peine d'être volé dans le dossier de projet que vous avez partagé. Il n'a qu'une issue. Le commutateur virtuel de la VM détourne chaque connexion web vers le proxy sur le Mac, et l'invité ne peut pas le désactiver.

• Au niveau de traçage par défaut, chaque requête est écrite dans une trace chiffrée sur le Mac, et les échanges avec le modèle y sont décomposés en appels d'outils et en commandes shell lancés par l'agent. Le Trace Inspector montre un POST vers un hôte inconnu au moment même où il se produit.
• Le pare-feu sortant de la machine, appliqué sur le Mac, peut n'autoriser que les hôtes dont le projet a besoin et bloquer tout le reste.
• Si la charge contient l'un des identifiants de substitution, le proxy voit un identifiant qui se dirige vers un hôte pour lequel il n'a pas été émis. Il répond par un HTTP 451, met la VM en pause et ouvre une alerte sur le Mac : This environment may have been compromised.

L'astuce IPC locale exige un processus du Mac

CVE-2026-100754 reposait sur du « code non privilégié déjà en cours d'exécution sur un Mac » qui atteignait le canal de confiance local de l'app ChatGPT. Sur un portable, la source la plus active de code qui s'exécute en votre nom est souvent l'agent de code : les dépendances qu'il installe, les scripts qu'il lance, les outils qu'il télécharge. Dans Bromure, ce code s'exécute dans l'invité Linux. Les services XPC et les sockets Unix du Mac, et les apps de bureau qui sont derrière, vivent dans un autre noyau. Un script postinstall malveillant dans la VM ne peut pas rejoindre une chaîne de processus sur le Mac.

Une machine par tâche

Les dossiers partagés sont l'endroit où vous décidez de ce que l'agent voit. Chaque machine Bromure a sa propre liste de dossiers, ses propres identifiants et son propre dossier personnel, si bien que la bonne habitude vient facilement :

1. Donnez à chaque projet sa propre machine, et ne partagez que le dossier de ce projet.
2. Ne donnez à une machine que les identifiants dont son projet se sert. La machine de test où vous essayez de nouveaux serveurs MCP et plugins d'agent n'en reçoit aucun.
3. Laissez Prompt before write activé, le réglage par défaut des nouvelles machines pour GitHub, les fournisseurs cloud, les registres, Kubernetes et les bases de données. Les push et les suppressions s'arrêtent alors sur un dialogue macOS qui montre l'opération exacte.
4. Ne partagez jamais votre dossier personnel. L'agent n'en a pas besoin.

Chaque démarrage d'une machine prend aussi un point de contrôle copy-on-write de son dossier personnel, si bien que Rewind home… peut restaurer ce qu'un agent y a supprimé.

Donnez à l'agent un ordinateur à lui

La note d'Apple, c'est un éditeur de système d'exploitation qui dit aux développeurs qu'une permission conçue pour les logiciels de sauvegarde n'a pas sa place chez des agents autonomes. Apple a raison. Son remède est une demande plus claire, et l'utilisateur doit toujours faire le bon choix pour chaque app, sur un Mac qui contient tout ce qu'il possède.

Bromure donne à l'agent un ordinateur à lui. Il contient le projet que vous avez partagé et des clés qui ne fonctionnent que lorsque le proxy de votre Mac y substitue les vraies. Quand le nouveau dialogue d'Apple arrivera, votre agent de code ne fera pas partie des apps qui le déclenchent.