Le mode auto de Claude Code n'est pas une frontière de sécurité

Le mode auto de Claude Code est-il une frontière de sécurité ? Non, et Anthropic le dit. Après que le chercheur Johann Rehberger a signalé une chaîne d’attaque fonctionnelle contre Claude Code Opus 5 en mode auto, Anthropic a clos le rapport en « Informatif », avec la position suivante : le mode auto est une fonctionnalité de confort adossée à un classificateur qui fait au mieux plutôt qu’une garantie de sécurité, les chaînes déterminées assemblées à partir d’étapes individuellement bénignes sortent de ce qu’on attend d’un classificateur, et la véritable frontière, c’est l’isolation au niveau du système d’exploitation associée au contrôle du trafic sortant.¹ Cette réponse n’est pas une esquive. C’est le bon modèle mental, et la plupart d’entre nous se trompaient de modèle. {.answer-block}

Il existe une catégorie de découvertes de sécurité qui comptent moins pour la faille que pour la croyance qu’elles corrigent. L’article de Rehberger du 26 août en fait partie. La chaîne qu’il démontre est astucieuse, mais l’essentiel tient à la réponse qu’elle a suscitée, car cette réponse indique quelle couche de votre installation porte réellement la charge — et ce n’est pas celle à laquelle la plupart des développeurs font confiance depuis que le mode auto est devenu le réglage par défaut en août.

En bref

• Rehberger a publié le 26 août 2026 une chaîne d’attaque fonctionnelle contre Claude Code Opus 5 en mode auto, avec un taux de réussite annoncé de 60 à 80 % sur de petits échantillons : trois exécutions sur cinq pour la chaîne principale, puis trois sur cinq et quatre sur cinq pour deux configurations d’une seconde variante. Il précise qu’il s’agit là de petits échantillons, et non d’un taux de réussite général.¹
• La découverte se heurte à un chiffre précis : une évaluation tierce commandée par Anthropic faisait état d’un taux de réussite des attaques par injection de prompt de 0,00 % pour Opus 5 en mode auto, mesuré sur 72 scénarios exécutés dix fois chacun. La chaîne de Rehberger ne figurait pas dans cet ensemble : le 0,00 % et une chaîne d’exécution de code fonctionnelle sont donc vrais en même temps.¹
• Chaque étape de la chaîne est raisonnable prise isolément. C’est là la leçon de conception : un classificateur évalue les actions une par une, et l’attaque vit dans la composition, pas dans une action prise à part.
• Anthropic a clos le rapport en « Informatif », présentant le mode auto comme une fonctionnalité de confort adossée à un classificateur qui fait au mieux plutôt que comme une garantie de sécurité, l’isolation du système d’exploitation et le contrôle du trafic sortant constituant la véritable frontière.¹
• Le détail le plus tranchant, rapporté par Rehberger et mis en avant par Willison : lors de quelques exécutions, Claude a détecté la compromission et tenté de tuer le processus malveillant, et le mode auto a refusé la commande de nettoyage.¹²
• Conséquence pratique : le mode auto est un contrôle de productivité qui bloque aussi une liste documentée d’opérations destructrices lorsqu’il estime que vous ne les avez pas demandées. Ce n’est pas lui qui se dresse entre un texte contrôlé par un attaquant et vos identifiants. Un conteneur, un trafic sortant restreint et un répertoire personnel sans identifiants, si.

La chaîne, étape par étape

Le point de départ est un agent qui fait un travail ordinaire : récupérer une ressource, la décoder, en utiliser le contenu. Voici comment cela devient une exécution de code.¹

Un serveur répond au WebFetch de l’agent par un HTTP 415, ce qui se lit comme un problème de type de contenu plutôt que comme une attaque. L’agent fait la chose sensée et se rabat sur curl. L’archive qu’il récupère se déploie dans un répertoire de travail temporaire contenant un README, un manifeste de sommes de contrôle, un index CSV, sept enregistrements JSON encodés en Base85 puis compressés avec zlib, un binaire de décodage natif et un fichier nommé struct.py.

Puis la machinerie de sécurité fonctionne. L’agent refuse d’exécuter le binaire natif non fiable, exactement comme on le souhaiterait. Ayant refusé ce binaire, il écrit son propre décodeur Python à la place et l’exécute depuis l’intérieur du répertoire d’extraction.

Ce décodeur importe base64. Le base64 de la bibliothèque standard importe struct. Python place le répertoire de travail en tête du chemin de recherche des modules : struct se résout donc vers le struct.py de l’attaquant présent dans l’archive extraite, et non vers celui de la bibliothèque standard.

Relisez la séquence et remarquez ce qui manque : aucune étape n’ordonne à l’agent de faire quelque chose de manifestement malveillant, et aucune étape ne serait signalée par un relecteur raisonnable prise isolément. Se rabattre sur curl après un 415 est normal. Extraire une archive est normal. Refuser un binaire non signé est un gain de sécurité. Écrire son propre décodeur relève de la débrouillardise. Et l’exécuter dans le répertoire qui contient les données, c’est l’endroit évident où l’exécuter.

Pourquoi un classificateur perd cette partie

Le classificateur du mode auto évalue une action au regard de l’intention de la session : cette commande correspond-elle à ce que l’utilisateur a demandé, et est-elle dangereuse en soi ? Cette question a une bonne réponse pour rm -rf / et une mauvaise pour python decode.py.

L’attaque ne présente jamais d’action dangereuse. Elle réagence l’environnement pour qu’une action d’apparence sûre ait une conséquence dangereuse, et cette conséquence n’existe qu’à cause d’une étape survenue plus tôt — l’extraction de l’archive qui a déposé le module. Pour l’attraper, un relecteur devrait garder tout l’historique en tête et raisonner sur la résolution des imports de Python au regard du répertoire de travail courant. La position d’Anthropic, selon laquelle les chaînes construites à partir d’étapes individuellement bénignes sortent du périmètre du classificateur, est une déclaration sur cet écart.¹

Il vaut la peine de nommer cette classe avec précision. Willison a mis à jour son article le 30 août pour reprendre à son compte un point soulevé par un lecteur de Lobste.rs : il ne s’agit pas du tout d’une injection de prompt classique, car à aucun moment le modèle ne lit des instructions de l’attaquant pour les suivre. Mieux vaut parler d’une attaque par environnement confus, où la forme de l’environnement remis à l’agent produit à elle seule l’exploitation.² Cette distinction aiguise le problème au lieu de l’adoucir. Un classificateur à l’affût d’instructions injectées n’a rien à observer ici, puisqu’il n’y en a aucune.

C’est exactement le point structurel que la vague de CVE MCP ne cesse de rappeler : l’outillage des agents accumule des capacités plus vite qu’il n’accumule du confinement, et la revue action par action ne se compose pas en sécurité de session.

Le détail qui devrait changer votre modèle mental

Rehberger rapporte, et Willison met en avant, le moment sur lequel il faut s’arrêter : lors de quelques exécutions, Claude a remarqué la compromission et tenté de terminer le processus malveillant, et le mode auto a refusé la commande de nettoyage.¹²

Une couche de sécurité qui empêche la remédiation n’est pas un paradoxe : c’est ce qui arrive quand un contrôle optimise le « ne pas laisser l’agent faire quoi que ce soit de radical » sans disposer de la notion du pourquoi cette action radicale est tentée. Le nettoyage après une compromission ressemble énormément, pour un classificateur, à de la destruction.

La leçon opérationnelle est étroite et utile. « L’agent s’en apercevra » n’est pas un contrôle. S’apercevoir et pouvoir agir sont deux capacités différentes, et votre réponse à incident ne peut pas supposer que l’agent compromis aura le droit de nettoyer derrière lui.

Ce qui borne réellement un agent

Les recommandations de Rehberger sont les moins spectaculaires, et les deux premières auraient contenu cette chaîne :¹

Exécutez les agents non surveillés dans un conteneur ou une VM. La compromission a exécuté du code sous l’utilisateur de l’agent. Une couche d’isolation transforme un accès à la machine entière en un environnement jetable.

Restreignez le trafic sortant. Le gain de la chaîne, c’était un sous-processus qui sortait chercher puis exécuter une charge utile distante, suivi d’un callback. Une politique de sortie sur liste d’autorisation casse à la fois le téléchargement de l’étage distant et le callback.

Gardez les identifiants hors de portée de l’agent. Les clés SSH, les identifiants cloud et les fichiers .env du répertoire personnel se trouvent par défaut dans le rayon d’action. Déplacez-les, ou faites tourner l’agent là où ils ne sont pas.

Surveillez l’agent, et ne lisez pas les approbations comme des preuves. Une approbation en mode auto signifie qu’un classificateur n’a pas objecté. Ce n’est pas un constat que l’action était sûre.

Notez ce qui ne figure pas sur cette liste : désactiver le mode auto. Il bloque une liste documentée d’opérations destructrices lorsqu’il estime que vous ne les avez pas demandées, et il réduit la lassitude face aux invites qui pousse les gens à tout approuver par réflexe. L’échanger contre un faux sentiment de rigueur revient à troquer un contrôle faible contre un pire encore. Gardez-le, et cessez de le prendre pour la frontière.

Ce qu’il faut dire clairement

Il serait facile de présenter cette découverte comme un échec, et plus facile encore d’en faire un procès de l’éditeur. Ni l’un ni l’autre n’est juste.

La réponse d’Anthropic — une fonctionnalité de confort adossée à un classificateur qui fait au mieux, pas une garantie de sécurité, avec l’isolation du système d’exploitation et le contrôle du trafic sortant comme frontière — constitue une posture de sécurité plus honnête que ne l’aurait été une affirmation plus forte.¹ Un éditeur qui promettrait que son classificateur attrape les chaînes d’injection déterminées ferait une promesse qu’aucun classificateur ne peut tenir, et les développeurs bâtiraient sur cette promesse. La question intéressante n’est pas de savoir si cette attaque fonctionne. Elle est de savoir si le modèle mental de l’écosystème correspond à celui de l’éditeur, et pour l’instant ce n’est pas le cas : le mode auto est devenu le réglage par défaut des sessions Pro, Max et Team en août, alors que le chiffre mis en circulation par Anthropic était un taux de réussite des attaques de 0,00 % issu d’une évaluation commandée sur 72 scénarios — Rehberger le range sous le problème marketing du 0,00 % — et le cadrage qui l’accompagnait parlait de sécurité, pas de confort assorti d’une réduction du rayon d’action.¹ Rehberger en tire une conclusion plus dure que la mienne : il lit la communication autour du 0,00 % et la qualification hors périmètre comme des messages contradictoires qui ne tiennent pas ensemble.¹ Je pense que les deux peuvent coexister. La qualification est l’honnête, et le chiffre n’aurait jamais dû être commercialisé comme une propriété du produit.

Si votre installation supposait que le classificateur était le mur, ajoutez le mur.

Mise à jour du 3 septembre : ce qui a été livré depuis cet article

Claude Code a livré trois versions dans les 48 heures suivant cet article ; deux d’entre elles touchent au mode auto.³ La version 2.1.257, publiée le 1er septembre, ajoute ce que les notes de version appellent une règle Containment Escape : « les récupérations d’identifiants via les métadonnées cloud, l’évasion du filtrage sortant et les accès inter-locataires ne sont plus approuvés automatiquement, sauf si votre environnement les marque comme attendus ». La même version ajoute, en mode auto, une invite unique avant la première lecture de fichier hors des répertoires de travail, avec un paramètre, permissions.blockReadsOutsideWorkingDirectories, qui transforme cette invite en refus. La version 2.1.259, publiée le 2 septembre, ajoute --permission-prompts none pour les hôtes headless non surveillés : « tout ce qui déclencherait une invite est refusé automatiquement, tandis que le mode de permission actif (y compris le mode auto) continue de décider ».

Lisez-les dans le cadre posé par cet article. La règle, l’invite de lecture et l’option sont un durcissement bien réel, et l’option headless est le réglage à défaillance fermée avec lequel un hôte non surveillé devrait tourner. Mais les deux premières restreignent ce que le mode auto approuvera de lui-même : la règle sort trois catégories de l’approbation automatique, sauf si l’environnement les marque comme attendues, et le changement sur les lectures demande une fois, ou refuse si le paramètre est activé. Aucune des deux n’est décrite comme une frontière, et toutes deux se situent à l’intérieur du flux d’approbation du mode auto. C’est précisément la revue que cette chaîne a traversée sans jamais présenter une seule action qui paraissait fautive en soi. La règle nomme l’évasion du filtrage sortant ; Rehberger ne décrit aucune évasion, seulement une connexion sortante à chaque saut : un téléchargement par curl, un processus enfant qui va chercher un étage distant, cet étage qui va chercher la charge utile, puis un callback. Les notes ne disent pas si la règle interprète quoi que ce soit de cela comme une évasion, ni si l’invite de lecture couvre les lectures effectuées par un processus enfant. Que l’un ou l’autre de ces changements ait pu arrêter cette chaîne, les notes ne le prétendent pas, et ce n’est pas à supposer. Un correctif de la 2.1.257 se situe bien à la couche frontière : une entrée deniedDomains du bac à sable ne bloquait pas un hôte écrit avec un point final, et la version corrige cela. C’est une réparation de la frontière, pas un déplacement. Ce que le mode auto approuve de lui-même a rétréci. La frontière, elle, n’a pas bougé.

Points clés

• Le mode auto est un confort et un contrôle du rayon d’action, pas une frontière de sécurité. C’est la position de l’éditeur lui-même après un contournement fonctionnel, pas une critique extérieure.¹
• Les classificateurs jugent des actions ; les attaques vivent dans les compositions. Chaque étape de la chaîne démontrée est défendable isolément, et c’est précisément pour cela que la revue action par action l’a manquée.
• Remarquer n’est pas remédier. Lors de certaines exécutions, l’agent a détecté sa propre compromission puis s’est vu bloquer le nettoyage. Planifiez votre réponse à incident en conséquence.¹²
• Les contrôles qui tiennent sont hors du modèle. Conteneur ou VM, trafic sortant restreint, identifiants hors du répertoire personnel. Tout le reste relève de la profondeur, pas de la frontière.

FAQ

Faut-il désactiver le mode auto ?

Non, sauf si vous comptiez dessus comme confinement. Il bloque un ensemble documenté d’opérations destructrices — git reset --hard, git checkout -- ., git clean -fd, git stash drop et terraform/pulumi/cdk destroy — lorsqu’il estime que vous ne les avez pas demandées, et il réduit le volume d’invites qui alimente l’approbation réflexe. Gardez-le comme contrôle de productivité et de rayon d’action, et ajoutez une véritable isolation pour les sessions qui touchent à des entrées non fiables.

Cela ne concerne-t-il que Claude Code ?

Le mécanisme n’est pas propre à Claude. Tout agent qui récupère des archives non fiables, écrit du code et l’exécute dans le répertoire qu’il vient d’extraire est exposé au même piège de résolution d’imports, et toute revue de sécurité action par action est exposée au même angle mort de composition. Les détails présentés ici ont été démontrés contre Claude Code Opus 5 en mode auto.¹

Qu’est-ce qui compte comme session à entrées non fiables ?

Tout ce par quoi un texte influencé par un attaquant peut atteindre le modèle : pages web récupérées, archives téléchargées, texte d’issues et de pull requests, e-mails, journaux d’un service public et serveurs MCP tiers. En pratique, cela couvre l’essentiel du vrai travail, et c’est là que le bât blesse.

Est-ce corrigé ?

Cela n’a pas été traité comme une vulnérabilité à corriger. Anthropic a clos le rapport en « Informatif » au motif qu’une évasion de classificateur de ce type sort de ce que promet le mode auto.¹ Traitez-le comme une propriété documentée du système plutôt que comme un correctif en attente. Une version publiée dans les 48 heures suivant cet article, la 2.1.257, a restreint ce que le mode auto approuve de lui-même et ajouté un blocage optionnel des lectures hors des répertoires de travail, et la 2.1.259 a ajouté une option à défaillance fermée pour les hôtes headless ; la mise à jour du 3 septembre ci-dessus détaille ce qu’elles changent et ce qu’elles ne changent pas.³

Sources