Anthropic lance l'auto mode dans Claude Code : les faux blocages tombent à 0,4%

Les utilisateurs de Claude Code valident 93% des demandes de permission : l'approbation manuelle est depuis longtemps devenue un réflexe, un « Approve » automatique. Anthropic tente de supprimer cet effet avec l'auto mode, où ce sont des classificateurs basés sur des modèles qui prennent les décisions. Sur 10 000 appels d'outils réels émis par des employés de l'entreprise, le pipeline complet ne bloque à tort que 0,4% des actions sûres. Mais sur les épisodes réellement dangereux, il en laisse passer 17%, et Anthropic le dit sans détour dans son analyse.

Pourquoi un mode intermédiaire

Aujourd'hui, l'utilisateur dispose de deux moyens pour éviter les confirmations superflues. Le premier est le bac à sable (sandbox). Il est sûr, mais demande une configuration pour chaque nouvelle capacité, et tout ce qui nécessite le réseau ou l'accès à l'hôte brise l'isolation. Le second est le flag --dangerously-skip-permissions, qui désactive toutes les demandes et ne protège de rien. Les confirmations manuelles se situent entre les deux, mais la lassitude qu'elles provoquent en réduit fortement l'intérêt.

Le journal interne d'incidents d'Anthropic montre ce qu'il faut réellement craindre. Un agent a supprimé des branches git distantes à cause d'une commande mal comprise. Un autre a envoyé le token GitHub d'un ingénieur vers un cluster de calcul interne. Un autre encore a tenté de lancer des migrations sur une base de production. Dans tous les cas, le modèle ne cherchait pas à nuire : il faisait preuve d'une initiative excessive. Ce schéma est décrit dans la system card de Claude Opus 4.6.

Comment fonctionne la protection

Il y a deux couches. En entrée, une sonde côté serveur examine les sorties des outils (lecture de fichiers, requêtes web, sortie du shell, réponses de services externes) avant qu'elles n'entrent dans le contexte de l'agent. Si un contenu ressemble à une tentative de prise de contrôle, un avertissement lui est ajouté : considérer la source comme suspecte et s'en tenir à la tâche initiale de l'utilisateur.

En sortie, c'est un classificateur de transcription basé sur Sonnet 4.6 qui travaille. Il procède en deux étapes : un filtre rapide à un seul token (« bloquer ou non »), puis un raisonnement par chaîne de pensée, uniquement pour ce que la première étape a signalé. Le classificateur ne voit que les messages de l'utilisateur et les appels d'outils. Les répliques et les sorties de Claude lui-même sont supprimées : par conception, il ne voit donc pas le raisonnement de l'agent.

Les décisions sont prises selon trois niveaux :

• Niveau 1 : une liste intégrée d'outils sûrs (lecture, recherche, navigation) et les règles de l'utilisateur. À l'entrée en auto mode, les règles qui autorisent l'exécution de code arbitraire sont écartées : accès général au shell, interpréteurs python, node, ruby avec masques, lancement via des gestionnaires de paquets.
• Niveau 2 : les modifications de fichiers dans le projet passent sans classificateur, car elles sont vérifiables via le système de contrôle de version.
• Niveau 3 : tout le reste, des commandes shell et requêtes web à la création de sous-agents et aux opérations hors du répertoire du projet, est soumis au classificateur.

Le classificateur évalue l'effet réel de l'action, et non le texte de la commande. Si l'agent a écrit un payload dans un fichier puis l'exécute, c'est le payload qui est examiné. Une chaîne reliée par && compte comme une seule action. Un script qui assemble une commande shell est analysé d'après le résultat assemblé. Tout ce que l'agent a choisi de lui-même est considéré comme non autorisé tant que l'utilisateur n'en dispose pas autrement. Une demande du type « nettoie les branches » ne donne pas le droit de procéder à une suppression de masse, et une question comme « peut-on corriger ça ? » ne vaut pas instruction.

Par défaut, seul le dépôt git courant est considéré comme fiable. Il existe plus de vingt règles de blocage, regroupées en quatre thèmes : destruction et fuite de données, dégradation de la sécurité, franchissement des frontières de confiance, contournement de la relecture et impact sur autrui. La liste peut être consultée avec la commande claude auto-mode defaults.

Chiffres et limites

Anthropic a testé le pipeline sur trois jeux de données : 10 000 appels réels d'employés, 52 cas réels d'initiative excessive et 1 000 tentatives synthétiques d'exfiltration de données, dont certaines avec obfuscation.

• Étape 1 (filtre rapide) : 8,5% de faux positifs sur le trafic réel ; 6,6% d'actions dangereuses manquées sur les cas réels ; 1,8% sur l'exfiltration synthétique.
• Pipeline complet (étapes 1 et 2) : 0,4% de faux positifs ; 17% d'actions dangereuses manquées sur les cas réels ; 5,7% sur l'exfiltration synthétique.

La seconde étape élimine les faux blocages, mais au prix du rappel : une partie des actions dangereuses passe. L'échantillon de 52 cas est réduit, car il faut que Claude ait tenté de faire quelque chose de dangereux dans une session réelle et qu'un humain l'ait consigné. L'analyse d'origine s'interrompt précisément sur la discussion de ces 17%, mais Anthropic ne cache pas le chiffre.

Comment l'utiliser

L'auto mode ne remplace pas le bac à sable là où une erreur coûte cher : sur une infrastructure de production et avec de vrais secrets, l'isolation est plus fiable. Dans les autres cas, ce mode apparaît comme un remplaçant raisonnable au flag aveugle de contournement des permissions. Avant de l'activer, il convient de vérifier ses propres règles allow : il retirera de toute façon les règles larges pour les interpréteurs. Les organisations GitHub de confiance, les buckets cloud et les API internes doivent être déclarés dans les paramètres. Sinon, tout envoi hors du dépôt sera considéré comme une fuite potentielle. Anthropic recommande de modifier les valeurs de base plutôt que d'écrire une configuration de zéro.