Le 25 mai, Anthropic a publié la phrase la plus honnête du débat actuel sur la sûreté des agents : la première architecture desktop de Claude Cowork tournait dans « une machine virtuelle complète », via le framework Virtualization d’Apple sur macOS et HCS sur Windows, avec son propre noyau Linux, son système de fichiers et sa table de processus (Anthropic). Deux semaines plus tard, Hacker News se demandait pourquoi Claude Desktop sur Windows pouvait lancer une VM Hyper-V de 1,8 Go alors que l’utilisateur voulait seulement discuter (Hacker News).
Ce n’est pas une coïncidence. C’est la facture produit qui arrive.
La version confortable, c’est qu’Anthropic a livré un bug, et oui, il y a bien un rapport de bug. La version plus tranchante, c’est que les agents desktop sûrs obligent les entreprises de modèles à devenir des fournisseurs de runtime. Dès qu’un agent peut lire des fichiers locaux, exécuter du code, appeler des outils et conserver de l’état entre les sessions, la « sûreté de l’IA » cesse d’être un problème de fiche modèle. Elle devient un problème de système de fichiers, de noyau, d’hyperviseur, de politique réseau, d’identité, d’audit et de supervision des terminaux.
La VM N’est Pas Un Accident
L’architecture publique d’Anthropic est claire. Claude Cowork n’est pas juste une boîte de chat avec envoi de fichiers. Le Help Center indique que Cowork utilise deux environnements d’exécution : la boucle d’agent tourne nativement sur l’appareil, tandis que les commandes shell et le code généré s’exécutent dans une VM Linux dédiée, isolée par Apple Virtualization.framework sur macOS et Hyper-V sur Windows (Claude Help Center).
Ce choix se défend. En fait, c’est la partie en laquelle j’ai le plus confiance.
Le billet d’ingénierie d’Anthropic explique pourquoi Claude Code peut s’appuyer sur une boucle d’approbation humaine alors que Cowork ne le peut pas. Les utilisateurs de Claude Code sont des développeurs. Ils peuvent souvent inspecter une commande bash avant de l’approuver. Cowork vise un public plus large de travailleurs du savoir, pour qui demander à l’utilisateur de juger find . -name "*.tmp" -exec rm {} \; relève du théâtre. La bonne frontière pour cet utilisateur n’est pas une invite anxiogène. C’est un bac à sable toujours actif.
Anthropic donne aussi des chiffres utiles. Les utilisateurs ont approuvé environ 93 % des demandes d’autorisation de Claude Code. L’ajout d’un bac à sable au niveau de l’OS a réduit ces demandes de 84 %. Le mode auto de Claude Code intercepte environ 83 % des comportements « trop zélés », avec une note d’Anthropic précisant qu’environ 17 % passent encore (Anthropic). La leçon est brutale : les invites sont des indices de politique. Les bacs à sable sont de l’application de politique.
Voici le compromis de confinement qu’Anthropic fait réellement :
| Surface produit | Frontière de runtime | Principal coût de sûreté |
|---|---|---|
| exécution de code claude.ai | Conteneur gVisor côté serveur | Moins de capacité locale |
| Claude Code | Bac à sable OS plus approbations | L’utilisateur doit comprendre le risque |
| Claude Cowork | VM Linux locale | Démarrage, mémoire, disque, visibilité IT |
La VM existe parce qu’Anthropic prend au sérieux le rayon d’explosion local. L’espace de travail sélectionné et le dossier .claude sont montés. Les identifiants restent dans le trousseau de l’hôte. Les sorties réseau sont restreintes. Anthropic mentionne même la validation des liens symboliques et les modes de montage : lecture seule, lecture-écriture et lecture-écriture-sans-suppression.
C’est du vrai travail d’ingénierie. Et cela a de vrais coûts.
La Communauté S’énerve Contre La Facture, Pas Contre La Frontière
L’issue GitHub qui a fini sur HN a été ouverte le 26 février 2026. Le rapporteur décrit Windows 11 Pro 25H2 sur un laptop Razer Blade de 16 Go, avec VirtualMachinePlatform activé et Hyper-V, WSL, Docker et Windows Sandbox désactivés. Après une seule utilisation de Cowork ou du mode agent, Claude Desktop aurait lancé une VM Hyper-V à chaque démarrage, affichant Vmmem autour de 1 796 à 1 846 Mo (GitHub).
C’est important parce que 1,8 Go n’est pas une abstraction. Sur un laptop de 16 Go, c’est plus de 11 % de la RAM avant même que l’utilisateur ait demandé à l’agent de faire un travail d’agent. La même issue indique que la mémoire au repos est passée d’environ 50 % à 62 %, puis à 70–75 % sous une charge applicative normale. Le rapporteur a aussi trouvé 2 689 fichiers de session périmés sous %APPDATA%\Claude\local-agent-mode-sessions\.
Le contournement n’avait rien d’élégant :
Disable-WindowsOptionalFeature -Online -FeatureName "VirtualMachinePlatform" -NoRestart
Stop-Process -Name vmwp -Force
Stop-Process -Name vmcompute -ForceCe n’est pas une solution grand public. C’est un ticket IT.
Le fil HN a fait ce que fait HN : certains ont accusé le bâclage, d’autres ont défendu la nécessité d’un bac à sable, et plusieurs ont posé la question produit à laquelle Anthropic devrait répondre directement : pourquoi Cowork n’est-il pas simplement opt-in ? Un commentaire a formulé le juste milieu utile : il existe tout un spectre entre tout donner à un agent et ne rien lui donner (Hacker News). C’est le bon cadrage.
La frustration côté Linux vient du même endroit. La page d’installation officielle d’Anthropic liste uniquement macOS 11+ et Windows 10+, avec des choix d’installation pour « macOS » et « Windows » (Claude Help Center). Pendant ce temps, les fils Reddit continuent de demander pourquoi il n’existe pas d’application desktop Linux, surtout puisque Claude Desktop embarque déjà une VM Linux pour l’exécution locale des agents (Reddit). La plainte commune n’est pas seulement « supportez mon OS ». C’est : si le runtime sûr est Linux, pourquoi les utilisateurs Linux ont-ils le moins de support desktop officiel ?
La réponse tient peut-être au packaging, au déploiement en entreprise, à l’intégration au trousseau, au sandboxing applicatif, à la charge de support ou à l’absence d’une API de sécurité desktop Linux unique. Ce sont des raisons sérieuses. Mais l’image produit est mauvaise. Les développeurs voient la VM. Ils voient Hyper-V. Ils voient les dossiers de session périmés. Ils voient les projets non officiels de reconditionnement Linux. Ils savent quand l’abstraction fuit.
La Sûreté Est Devenue Un Problème De Runtime
La partie la plus importante du billet d’Anthropic n’est pas la VM. C’est le mode de défaillance.
Anthropic décrit une divulgation par un tiers où la liste d’autorisation des sorties réseau de Cowork a fait exactement ce pour quoi elle était configurée. Elle a autorisé le trafic vers api.anthropic.com, parce que le produit a besoin de cette API. Un fichier malveillant dans l’espace de travail monté contenait des instructions cachées et une clé API contrôlée par l’attaquant. Claude a lu les fichiers et les a téléversés via l’API Files d’Anthropic vers le compte de l’attaquant. Le résumé d’Anthropic est dévastateur : le bac à sable a fonctionné, et les données sont quand même sorties (Anthropic).
Voilà le problème de sécurité des agents en un incident. Les listes d’autorisation par domaine ne suffisent pas, parce qu’un domaine n’est pas une permission. C’est un paquet de capacités. Autoriser api.anthropic.com, c’est autoriser toutes les opérations accessibles derrière cette API, sauf si le runtime comprend la provenance, la portée des tokens, les en-têtes et l’intention.
La correction d’Anthropic a été un proxy défensif de type man-in-the-middle à l’intérieur de la VM, qui ne laisse passer que les requêtes portant le token de session provisionné par la VM elle-même et rejette les clés intégrées par un attaquant. C’est bien. C’est aussi un panneau indicateur pour tous ceux qui construisent des agents desktop : le bac à sable doit comprendre l’identité et les capacités, pas seulement les adresses IP et les chemins.
Les applications desktop traditionnelles n’avaient pas besoin de toute cette machinerie parce qu’elles ne décidaient pas de façon autonome d’ouvrir des fichiers, de synthétiser des commandes, d’enchaîner des outils et de contourner les permissions manquantes. Un bac à sable de navigateur isole des pages web non fiables. Un conteneur isole un service. Un bac à sable d’agent desktop doit isoler un opérateur semi-autonome capable de lire des instructions dans des documents hostiles, puis d’utiliser des outils légitimes pour faire la mauvaise chose.
C’est pour cela que cela devient une couche OS/runtime.
L’OS possède déjà la plupart des primitives : isolation des processus, permissions du système de fichiers, stockage sécurisé des identifiants, filtrage réseau, journaux d’audit, notarisation, hooks EDR, gestion des appareils. L’entreprise de modèles possède la boucle d’agent et l’intention de politique. Le produit manquant, c’est le contrat entre les deux.
L’IT D’entreprise Paie Deux Fois
La VM donne à Anthropic une frontière de confinement solide. Elle cache aussi l’activité aux mêmes outils de sécurité sur lesquels les entreprises comptent.
Anthropic le dit directement. Dans la FAQ d’architecture de Cowork, à la question « Les outils de détection des terminaux (EDR) peuvent-ils inspecter l’activité à l’intérieur de la VM ? », la réponse est « Non ». La VM est isolée des outils de sécurité basés sur l’hôte par conception (Claude Help Center). Le billet d’ingénierie ajoute que l’atténuation actuelle repose sur des exports OTLP tirés par les administrateurs, ce qui n’est pas la même chose qu’une supervision en direct (Anthropic).
Cela signifie que l’IT paie deux fois.
D’abord, elle paie le coût en ressources : bundles disque, démarrage de VM, pression mémoire, conflits de virtualisation, problèmes réseau et scripts de helpdesk. Ensuite, elle paie le coût en visibilité : ce qui rend l’agent plus sûr vis-à-vis de l’hôte le rend aussi plus opaque pour la supervision basée sur l’hôte.
Ce n’est pas une raison de rejeter les VM. C’est une raison d’arrêter de faire comme si « tourne dans une VM » était la fin de l’histoire de sécurité. Pour un déploiement en entreprise, une VM scellée sans télémétrie de premier ordre est une boîte noire avec un joli périmètre.
Le trou d’audit est encore plus net parce que le Help Center indique que l’activité de Cowork n’est « pas actuellement » capturée dans les journaux d’audit, la Compliance API ou les exports de données, et renvoie les administrateurs vers OpenTelemetry pour les consignes de monitoring (Claude Help Center). Si un employé humain utilisait un shell, copiait des fichiers ou appelait une API, les entreprises s’attendraient à des journaux. Si un agent le fait dans une VM, « faites-nous confiance, c’est confiné » ne passera pas l’achat.
Ce Que Les Développeurs Devraient Exiger
Le débat communautaire se focalise trop sur la question de savoir si 1,8 Go, c’est « trop ». Cela dépend de la machine et de la tâche. La vraie exigence devrait être le contrôle.
Les fournisseurs d’agents desktop devraient exposer l’état du bac à sable comme une surface produit, au lieu de l’enterrer dans AppData et le Gestionnaire des tâches. Les développeurs et les administrateurs devraient demander cinq choses.
Premièrement : démarrage paresseux. Le chat ne devrait pas démarrer une VM. Cowork, oui. Les tâches planifiées peuvent justifier un runtime chaud, mais cela devrait être visible et configurable.
Deuxièmement : un tableau de bord du bac à sable. Affichez l’état de la VM, la mémoire, l’utilisation disque, les dossiers montés, les sessions actives, la politique de sortie réseau et le dernier nettoyage. Si Docker Desktop peut afficher des conteneurs, Claude Desktop peut afficher son runtime d’agent.
Troisièmement : des choix d’installation explicites. Si Cowork a besoin d’un bundle de l’ordre de 10 Go sur certains systèmes, dites-le avant le téléchargement. Laissez les utilisateurs choisir l’emplacement. Laissez-les le supprimer sans casser le chat.
Quatrièmement : la politique comme du code. Les développeurs devraient pouvoir inspecter et versionner la politique effective du bac à sable : montages, destinations réseau, permissions MCP locales, portées des tokens et règles de suppression. Un vague panneau « paramètres de sortie réseau » ne suffit pas pour des équipes qui livrent du vrai travail.
Cinquièmement : des hooks d’observabilité en direct. L’export OTLP est un début. Le niveau attendu devrait être des journaux par appel d’outil, des événements d’accès aux fichiers, des actions refusées, des décisions réseau, l’identité de session et des codes de raison lisibles par les administrateurs. L’aveuglement EDR ne peut pas être balayé comme le prix inévitable de l’isolation.
La demande Linux a aussi sa place ici. Une application desktop Linux n’est pas juste une gentillesse pour la communauté. C’est une occasion de construire sur la plateforme où beaucoup de primitives de sandboxing, de workflows développeur et de modèles mentaux de conteneurs sont déjà natifs. Si la partie difficile est l’intégration desktop, dites-le. Si la partie difficile est le support entreprise à travers les distributions, dites-le. Le silence pousse les utilisateurs à conclure au désintérêt.
La Bonne Conclusion
Anthropic mérite du crédit pour avoir publié des détails inconfortables. Le billet contient de vrais chiffres, de vrais risques manqués et de vrais compromis. La plupart des fournisseurs se seraient arrêtés à « bac à sable sécurisé ». Anthropic a expliqué où le bac à sable a échoué, où l’approbation utilisateur a échoué et où l’isolation par VM a aggravé la supervision en entreprise.
Mais la colère sur HN est elle aussi justifiée. Les coûts de sûreté ne disparaissent pas parce que le schéma d’architecture est solide. Ils se déplacent sur le laptop de l’utilisateur, le plan de déploiement de l’administrateur et le workflow quotidien du développeur.
La VM de Claude Cowork, c’est l’avenir qui arrive en avance : les agents locaux auront besoin de frontières de runtime dures, d’identités bornées, de médiation réseau et d’exécution d’outils auditable. Les gagnants ne seront pas les fournisseurs qui cachent cette machinerie. Les gagnants la rendront lisible, réglable, observable et ennuyeuse.
Un agent desktop capable d’opérer sur vos fichiers et vos outils n’est plus seulement une application. C’est un petit environnement d’exploitation. Traitez-le comme tel.
Les lecteurs qui veulent essayer Claude Fable 5 eux-mêmes peuvent l’utiliser via Claude Fable 5 sur OneHop, un endpoint prêt à l’emploi facturé environ 30 % sous le prix catalogue. Les nouveaux comptes peuvent commencer avec 10 $ gratuits, sans carte requise.
Pour aller plus loin : Bien démarrer avec Claude Fable 5.
