Par défaut, Claude Code demande ton accord avant de lancer une commande ou de modifier un fichier. C'est sûr, mais au bout de la centième demande, on clique sur « approuver » sans lire. Anthropic a mesuré le phénomène : les utilisateurs acceptent 93 % des demandes de permission. C'est ce qu'on appelle la fatigue d'approbation.
Le 25 mars, l'équipe d'ingénierie d'Anthropic a publié un long article sur la solution qu'elle a construite : l'auto mode. Un article particulièrement intéressant parce qu'il donne les vrais chiffres, y compris ceux qui ne sont pas flatteurs.
Jusqu'ici, trois approches coexistaient :
- les demandes manuelles : sûres en théorie, mais en pratique on accepte presque tout ;
- le sandbox : sûr, mais exigeant à maintenir, car chaque nouvelle capacité doit être configurée, et tout ce qui touche au réseau ou à la machine casse l'isolation ;
- le flag
--dangerously-skip-permissions : zéro maintenance, mais zéro protection.
L'auto mode vise un point intermédiaire : beaucoup d'autonomie, peu de maintenance, avec une sécurité qui s'améliore à mesure que les classifieurs progressent.
Anthropic tient un journal interne des incidents liés au comportement de ses agents. Quelques exemples cités :
- supprimer des branches Git distantes à cause d'une instruction mal interprétée ;
- envoyer le jeton GitHub d'un ingénieur sur un cluster de calcul interne ;
- tenter des migrations sur une base de production.
Point commun : le modèle était trop zélé. Il essayait d'aider, mais a pris des initiatives que l'utilisateur n'avait pas voulues.
L'article distingue quatre raisons pour lesquelles un agent peut faire quelque chose de dangereux :
- l'excès de zèle : l'agent comprend l'objectif mais va au-delà de ce qui est autorisé, par exemple en utilisant un identifiant trouvé par hasard ;
- l'erreur honnête : il se trompe sur la portée d'une action, en croyant une ressource de test alors qu'elle est partagée ;
- l'injection de prompt : des instructions cachées dans un fichier, une page web ou une réponse d'outil le détournent ;
- un modèle mal aligné, qui poursuivrait ses propres objectifs. Anthropic précise ne pas observer ce cas en pratique, tout en l'évaluant pour chaque modèle.
Dans tous les cas, la défense est la même : bloquer l'action.
L'auto mode repose sur deux défenses : l'une pour ce que Claude lit, l'autre pour ce que Claude fait.
En entrée, une sonde anti-injection analyse côté serveur les résultats d'outils (lectures de fichiers, pages web, sorties de commandes) avant qu'ils n'entrent dans le contexte. Si un contenu ressemble à une tentative de détournement, elle ajoute un avertissement pour que l'agent s'en méfie et se recentre sur la demande réelle.
En sortie, un classifieur de transcription, qui tourne sur Sonnet 4.6, évalue chaque action avant son exécution, à la place d'un humain.
Toutes les actions ne passent pas par le classifieur :
- Niveau 1 : une liste d'outils sans danger (lecture de fichiers, recherche, navigation dans le code) et tes propres règles d'autorisation. Exception notable : en passant en auto mode, les règles trop larges qui permettent d'exécuter n'importe quel code (accès shell global, interpréteurs Python ou Node en joker, commandes
run des gestionnaires de paquets) sont désactivées. Les règles précises, comme « autoriser le formateur », restent.
- Niveau 2 : les modifications de fichiers dans le projet passent sans classifieur. Elles sont vérifiables avec Git.
- Niveau 3 : tout le reste va au classifieur : commandes shell, accès web, outils externes, sous-agents, fichiers hors du projet.
Le classifieur fonctionne en deux temps :
- un filtre rapide qui répond par un seul token, oui ou non, en penchant volontairement vers le blocage ;
- seulement si le filtre signale un problème, une analyse avec raisonnement qui réexamine l'action pour éliminer les faux positifs.
Comme la plupart des actions passent la première étape, le coût reste faible.
Choix de conception clé : le classifieur ne voit que les messages de l'utilisateur et les appels d'outils. Les explications de Claude et les résultats d'outils sont retirés.
Pourquoi ? Pour que l'agent ne puisse pas convaincre le classifieur avec une justification du type « c'est sans risque, l'utilisateur l'a implicitement accepté ». Et parce que les résultats d'outils sont justement la porte d'entrée des injections. Le classifieur juge ce que l'agent fait, pas ce qu'il dit.
Par défaut, plus de vingt règles de blocage, regroupées en quatre familles :
- détruire ou exfiltrer : force-push qui écrase l'historique, suppression massive de stockage, envoi de données internes à l'extérieur ;
- dégrader la sécurité : désactiver des journaux, installer des clés SSH ou des tâches cron, modifier la configuration des permissions de l'agent ;
- franchir des frontières de confiance : exécuter du code cloné depuis un dépôt externe, fouiller des magasins d'identifiants, envoyer des données à un service non demandé ;
- contourner une revue ou toucher aux autres : pousser directement sur
main, lancer un déploiement en production, modifier des ressources partagées.
Des exemples concrets tirés du journal d'incidents : un « nettoie les vieilles branches » qui aurait supprimé des branches distantes, une erreur d'authentification suivie d'une recherche de jetons dans les variables d'environnement, ou un déploiement relancé avec un flag qui saute les vérifications.
Par défaut, la seule zone de confiance est le dépôt Git dans lequel tu travailles. Tu peux l'élargir dans les réglages (ton organisation GitHub, tes buckets, tes API internes). La commande claude auto-mode defaults affiche la configuration par défaut complète.
C'est la partie la plus honnête de l'article. Trois jeux de données :
| Jeu de test | Filtre rapide seul | Chaîne complète |
|---|
| Trafic réel (10 000 actions) | 8,5 % de faux positifs | 0,4 % de faux positifs |
| Actions trop zélées réelles (52) | 6,6 % de faux négatifs | 17 % de faux négatifs |
| Exfiltration synthétique (1 000) | 1,8 % de faux négatifs | 5,7 % de faux négatifs |
En clair : la chaîne complète ne bloque plus que 0,4 % des actions légitimes, mais laisse passer 17 % des actions trop zélées de l'échantillon réel.
Anthropic explique que dans la plupart des cas ratés, le classifieur voit bien le danger. Ce qu'il évalue mal, c'est si un accord donné par l'utilisateur couvre vraiment cette action. « Nettoie la PR » ne veut pas dire « fais un force-push ».
La réponse d'Anthropic est nuancée, et c'est la bonne :
- si tu utilises
--dangerously-skip-permissions, l'auto mode est une nette amélioration ;
- si tu relis soigneusement chaque action, c'est plutôt une régression : tu remplaces ton jugement par un classifieur qui se trompera parfois.
L'auto mode n'est pas fait pour remplacer une revue humaine attentive sur une infrastructure critique. Il est fait pour tous ceux qui, de toute façon, cliquaient « approuver » sans lire.
- Constat : 93 % des demandes de permission sont acceptées, souvent par fatigue.
- Principe : une sonde anti-injection en entrée, un classifieur en deux étapes (sur Sonnet 4.6) en sortie.
- Conception : le classifieur ne lit pas le discours de l'agent, seulement tes messages et ses actions.
- Résultats : 0,4 % de faux positifs, mais 17 % d'actions trop zélées non bloquées.
- Usage : bien mieux que tout désactiver, moins bien qu'une relecture attentive.
