La publication SharedRoot d'Accomplish AI met le doigt sur un point que beaucoup d'équipes vont devoir regarder de plus près : un agent IA local n'est pas seulement un chatbot avec un meilleur accès aux fichiers. C'est un environnement d'exécution qui lit des documents, manipule des dossiers, lance du code, suit des instructions venues du web et peut agir dans le contexte d'un utilisateur connecté.

Dans le cas de Claude Cowork, les chercheurs décrivent une chaîne d'attaque touchant des sessions locales sur macOS. L'agent tourne dans une VM Linux, mais une combinaison de choix d'architecture et d'une vulnérabilité du noyau Linux, CVE-2026-46331, permettait selon eux d'atteindre des fichiers du Mac hôte au-delà du dossier explicitement connecté. Accomplish a nommé cette chaîne SharedRoot.

Le détail important n'est pas que "l'IA s'échappe" comme dans un scénario spectaculaire. Le sujet est plus concret : si un agent peut consommer du contenu non fiable et exécuter des actions, son sandbox devient une frontière de sécurité à part entière. Cette frontière doit résister à un modèle qui se trompe, à une page web hostile, à un dépôt malveillant, à un PDF piégé, et à des failles classiques du système sous-jacent.

Le problème n'est pas seulement le modèle

La sécurité des agents IA est souvent discutée sous l'angle du prompt injection. C'est logique : un agent lit des instructions, certaines instructions peuvent être hostiles, et le modèle peut être influencé. Mais cette lecture est incomplète.

Un agent moderne n'est pas dangereux uniquement parce qu'il peut croire une instruction malveillante. Il devient dangereux quand cette instruction peut déclencher une capacité réelle : lire un dossier, ouvrir un navigateur authentifié, exécuter une commande, modifier un fichier, envoyer une requête, extraire une clé, publier un message ou effacer un contenu.

La question centrale n'est donc pas seulement "le modèle suivra-t-il la mauvaise instruction ?". Elle devient "que peut-il faire si cela arrive ?". C'est une question d'architecture, pas seulement de comportement du modèle.

Dans ce cadre, la VM est une bonne idée, mais elle ne doit pas être traitée comme une réponse complète. Une VM réduit le risque si elle impose une frontière forte entre l'environnement de l'agent et la machine de l'utilisateur. Elle devient fragile si le système invite trop largement le disque hôte dans l'environnement invité.

Ce que SharedRoot raconte

Accomplish décrit une architecture dans laquelle Claude Cowork exécute le travail de l'agent dans une VM Linux créée depuis macOS. L'agent démarre comme utilisateur non privilégié, avec des restrictions, tandis que des dossiers sont montés pour donner accès aux fichiers que l'utilisateur veut partager.

La chaîne rapportée repose sur plusieurs étapes. D'abord, l'environnement autorise des namespaces utilisateur non privilégiés, ce qui peut donner des capacités puissantes dans le contexte du noyau invité. Ensuite, l'agent peut atteindre un chemin réseau du noyau Linux impliqué dans CVE-2026-46331, aussi appelée pedit COW. Le NVD décrit cette faille comme un problème de copy-on-write dans le sous-système traffic control du noyau Linux, avec un risque de corruption de page cache.

Dans le scénario d'Accomplish, cette faille permet de monter en privilèges dans la VM. Ce n'est pas encore une compromission du Mac. Une VM bien bornée devrait contenir ce type d'incident. Le problème arrive au dernier niveau : le système de fichiers hôte était, selon le rapport, exposé en lecture-écriture dans la VM via un montage accessible au root invité. Une fois root dans l'invité, l'agent pouvait toucher des fichiers de l'utilisateur macOS.

Ce point change l'analyse. Le noyau Linux vulnérabilisé a fourni une route vers root dans l'invité, mais le dégât vient surtout de ce que root dans l'invité pouvait atteindre. C'est la différence entre un bug confiné et une exposition de secrets.

Le risque des montages trop larges

Partager des fichiers avec une VM est normal. Les développeurs le font chaque jour avec Docker, des VM de test, des environnements CI locaux ou des outils d'automatisation. Mais la portée du partage détermine le rayon d'impact.

Un dossier projet en lecture seule n'a pas le même risque qu'un répertoire utilisateur entier en lecture-écriture. Un montage temporaire limité à une tâche n'a pas le même risque qu'un accès durable au disque. Une règle appliquée côté hôte n'a pas la même force qu'une simple convention dans l'invité.

Les agents IA aggravent cette équation parce qu'ils combinent trois choses rarement réunies dans les outils classiques : ils lisent beaucoup de contenu non fiable, ils improvisent des plans d'action, et ils disposent parfois d'outils très puissants. Un dépôt open source inconnu, un ticket client, un fichier Markdown ou une page web peuvent contenir des instructions qui n'ont aucune raison d'être exécutées, mais que l'agent peut tout de même intégrer à son contexte.

La bonne défense consiste donc à supposer que l'invité finira par être compromis. Cela paraît sévère, mais c'est une hypothèse saine. Si root dans la VM ne peut voir qu'un dossier de travail limité, l'incident reste beaucoup moins grave. Si root dans la VM peut lire les clés SSH, les tokens cloud, les profils navigateur ou des documents personnels, le sandbox n'a pas vraiment tenu son rôle.

Les correctifs techniques ne suffisent pas toujours

CVE-2026-46331 doit évidemment être corrigée dans les noyaux concernés. Les environnements Linux utilisés par des agents, des conteneurs ou des VM doivent suivre les correctifs de sécurité avec la même discipline qu'un serveur exposé. Mais l'article d'Accomplish insiste sur une idée plus durable : un correctif ferme une route, pas toute la classe de risques.

La prochaine faille ne sera pas forcément pedit COW. Elle peut toucher un autre module, un autre chemin de syscall, une autre interaction entre namespace, seccomp, montage et daemon privilégié. Si l'architecture donne au root invité une vue trop large du système hôte, chaque élévation locale devient plus dangereuse.

Les mitigations citées autour de ce cas vont dans ce sens : réduire les namespaces utilisateur non privilégiés quand ils ne sont pas nécessaires, durcir les filtres seccomp, limiter l'autoload de modules noyau inutiles, monter uniquement les dossiers nécessaires, privilégier la lecture seule quand c'est possible, et exécuter les composants privilégiés avec des protections système plus strictes.

Ce sont des mesures classiques de défense en profondeur. Elles deviennent simplement plus urgentes quand l'environnement contrôle un agent qui peut être influencé par des entrées externes.

Ce qu'Anthropic dit maintenant de Cowork

La documentation d'Anthropic présente Cowork comme une capacité agentive avec accès aux fichiers, au navigateur et aux applications via Claude Desktop. Elle indique aussi que les sessions Cowork s'exécutent à distance sur les serveurs d'Anthropic, dans un environnement isolé et temporaire, et conseille de limiter l'accès aux fichiers sensibles.

Cela change le risque par rapport au scénario local décrit par Accomplish. Si l'exécution est distante et que l'environnement ne peut pas joindre directement le disque de l'utilisateur, la chaîne SharedRoot ne s'applique pas de la même façon. Mais la leçon reste valable pour tous les produits qui proposent ou proposeront une exécution locale.

Les équipes devront vérifier le mode d'exécution réel, pas seulement se fier au nom du produit. Cloud, local, hybride, connecteur desktop, extension navigateur, MCP, dossier partagé : chacun de ces mots implique une surface différente. Pour une entreprise, cette distinction doit être visible dans la politique de sécurité, pas enterrée dans une interface.

Comment utiliser des agents locaux avec prudence

Le premier principe est simple : ne pas donner à un agent plus de fichiers qu'il n'en faut. Un dossier de travail dédié, sans clés SSH, sans exports clients, sans documents financiers et sans secrets de production, réduit immédiatement le risque.

Le deuxième principe est de séparer les identités. Un agent utilisé sur une machine personnelle connectée à tous les comptes de production n'a pas le même impact qu'un agent lancé dans un profil dédié, avec des droits limités et des secrets jetables. La productivité ne doit pas transformer le poste principal en coffre-fort ouvert.

Le troisième principe est de traiter les entrées non fiables comme du code potentiel. Un dépôt inconnu, une archive, une page web ou un document reçu par e-mail peut contenir des instructions destinées à l'agent. Cela ne veut pas dire qu'il faut tout bloquer, mais que les actions d'écriture, les commandes et les accès sensibles doivent rester sous contrôle.

Le quatrième principe est l'observabilité. Pour les équipes, il faut savoir quels agents ont été utilisés, sur quelles machines, avec quels dossiers, quels outils et quel mode d'approbation. Après incident, l'absence de trace rend la réponse presque impossible.

La vraie conclusion

SharedRoot n'est pas seulement une histoire Claude Cowork. C'est un avertissement pour toute la catégorie des agents IA de bureau. Les produits vont continuer à promettre plus d'autonomie, plus de contexte et plus d'intégration locale. Cette trajectoire est utile, mais elle transforme chaque agent en surface d'attaque.

Une VM est une bonne brique. Un filtre seccomp est une bonne brique. Une permission de dossier est une bonne brique. Mais aucune de ces briques ne suffit si la frontière finale donne à un processus compromis l'accès au disque hôte.

Pour les utilisateurs, la pratique raisonnable est de limiter les dossiers et de ne pas mélanger agents expérimentaux et secrets importants. Pour les éditeurs, la barre est plus haute : l'agent doit être conçu comme non fiable, même quand il fonctionne comme prévu. C'est la condition pour que l'autonomie devienne exploitable sans transformer chaque poste de travail en point faible.