Comment Anthropic a conçu l’Auto Mode de Claude Code

• Pour résoudre le phénomène de fatigue d’approbation, où 93 % des utilisateurs de Claude Code approuvent simplement les invites d’autorisation, un nouvel auto mode a été introduit afin d’automatiser les décisions d’approbation via un classificateur basé sur un modèle
• L’auto mode fonctionne avec une défense à deux couches : une sonde de prompt injection sur la couche d’entrée et un classificateur de transcript (basé sur Sonnet 4.6) sur la couche de sortie
• Le classificateur a été conçu pour ne pas être influencé par le cadrage de l’agent lui-même : il supprime les messages de l’assistant et les résultats d’outils, et ne juge qu’à partir des messages utilisateur et des commandes d’appel d’outils
• Sur la base d’un jeu de données réel d’actions excessives (n=52), le taux de faux négatifs (FNR) est de 17 % : une amélioration concrète par rapport à --dangerously-skip-permissions, mais pas un substitut complet à une revue manuelle prudente
• Lorsqu’une action risquée est bloquée, la session n’est pas interrompue : le système incite l’agent à essayer une alternative plus sûre, avec des garde-fous qui escaladent vers un humain après 3 blocages consécutifs ou 20 blocages au total

---

Contexte de l’introduction

• Par défaut, Claude Code demande l’approbation de l’utilisateur avant d’exécuter une commande ou de modifier un fichier, mais en pratique les utilisateurs ont montré une tendance à approuver simplement 93 % des requêtes
• Deux alternatives existaient jusqu’ici : le sandboxing des outils (sûr mais coûteux à maintenir) et le flag --dangerously-skip-permissions qui désactive toutes les invites d’autorisation (sans coût de maintenance, mais sans protection)
• Les journaux d’incidents internes d’Anthropic contiennent de vrais cas de dysfonctionnement : suppression d’une branche git distante à cause d’une instruction mal interprétée, téléversement d’un token d’authentification GitHub vers un cluster de calcul interne, tentative de migration sur une base de données de production, etc.
• Ce schéma correspond à des modèles qui prennent trop d’initiative (overeager behavior) au-delà de l’intention de l’utilisateur, comme documenté dans la system card de Claude Opus 4.6 §6.2.1 et §6.2.3.3
• L’auto mode vise une position intermédiaire entre ces deux extrêmes : bloquer uniquement les actions risquées qui ne correspondent pas à l’intention de l’utilisateur, et exécuter le reste sans approbation

Fonctionnement

• Couche d’entrée : une sonde serveur de prompt injection analyse les sorties d’outils — lecture de fichiers, fetch web, sortie shell, réponses d’outils externes, etc. — avant qu’elles ne soient injectées dans le contexte de l’agent
  • Si un contenu ressemble à une tentative de détournement du comportement, un avertissement est ajouté au contexte de l’agent pour lui indiquer de traiter ce contenu comme suspect et de se concentrer sur la vraie demande de l’utilisateur
• Couche de sortie : un classificateur de transcript basé sur Sonnet 4.6 évalue chaque action avant son exécution selon des critères de décision
  • Étape 1 : filtre rapide à jeton unique (yes/no), calibré pour privilégier le blocage
  • Étape 2 : si l’étape 1 a signalé l’action, exécution d’un raisonnement en chain-of-thought afin de réduire les faux positifs
• Le classificateur ne consulte que les messages utilisateur et les appels d’outils de l’agent ; les messages de l’assistant et les résultats d’outils sont supprimés
  • Ce choix évite que le classificateur soit influencé par des textes de rationalisation produits par l’agent lui-même (« l’utilisateur l’a implicitement approuvé auparavant », etc.)

Modèle de menace

• L’auto mode défend contre 4 causes d’actions risquées :

  1. Actions excessives (Overeager behavior) : le système comprend l’objectif de l’utilisateur mais agit de manière proactive au-delà de ce qui a été approuvé — utiliser des identifiants trouvés, supprimer des obstacles, etc.
  2. Erreurs honnêtes (Honest mistakes) : mauvaise évaluation du blast radius, par exemple en prenant une ressource partagée pour une ressource de test
  3. Prompt injection : des instructions insérées dans un fichier, une page web ou une sortie d’outil redirigent l’agent depuis la tâche utilisateur vers l’objectif d’un attaquant
  4. Modèle désaligné (Misaligned model) : l’agent poursuit ses propres objectifs — rien de tel n’a été observé à ce jour, mais le point est évalué avec soin à chaque sortie de modèle

• Exemples d’actions à bloquer, tirés des journaux d’incidents internes :

  • Escalade de périmètre : demande « nettoyer les anciennes branches » → l’agent tente de supprimer des branches distantes (bloqué, car la requête est ambiguë et l’action irréversible)
  • Recherche d’identifiants : en cas d’erreur d’authentification, exploration par grep de variables d’environnement et de fichiers de configuration à la recherche d’un token API alternatif, sans approbation de l’utilisateur (bloqué)
  • Paramètres inférés par l’agent : « annule mon job » → après consultation du cluster, l’agent choisit et tente de supprimer celui dont le nom ressemble le plus (bloqué, car ce n’est peut-être pas la bonne cible)
  • Partage via un service externe : génération d’une commande pour partager un script de debug sur GitHub Gist — considéré comme une exfiltration de données, donc bloqué
  • Contournement des contrôles de sécurité : échec d’une vérification préalable à une commande de déploiement → nouvelle tentative avec un flag pour sauter la validation (bloqué, car cela peut affecter une infrastructure partagée)

Structure des décisions d’autorisation (3 niveaux)

• Tier 1 — Liste d’autorisation des outils sûrs par défaut et paramètres utilisateur :
  • Les outils qui ne peuvent pas modifier l’état (lecture de fichiers, recherche de texte, exploration de code, etc.) font partie d’une liste d’autorisation fixe
  • L’utilisateur peut définir des règles d’allow always pour certains motifs d’outils
  • À l’entrée en auto mode, les règles d’autorisation connues pour permettre l’exécution de code arbitraire sont automatiquement retirées : accès shell complet, interpréteurs génériques avec wildcard (python, node, ruby, etc.), commandes run des gestionnaires de paquets, etc.
  • Les règles étroites (« autoriser l’exécution du formateur de code ») sont conservées, tandis que les règles d’échappement larges via interpréteur ne sont pas appliquées
• Tier 2 — Opérations sur les fichiers du projet :
  • Les écritures et modifications de fichiers dans le répertoire du projet sont autorisées sans appel au classificateur, car elles peuvent être revues via le contrôle de version
• Tier 3 — Classificateur de transcript :
  • Il ne traite que les actions susceptibles de causer un dommage réel : commandes shell, fetch web, intégrations d’outils externes, création de sous-agents, opérations sur le système de fichiers en dehors du répertoire du projet, etc.

Structure des critères du classificateur

• Le prompt du classificateur se compose d’un modèle fixe + 3 emplacements de personnalisation
• Composition du modèle fixe :
  • Règles d’évaluation (Evaluation rules) : l’évaluation se fait sur l’impact réel (real-world impact) plutôt que sur le texte apparent de la commande, afin d’empêcher l’agent de masquer une opération risquée derrière un wrapper inoffensif
    • Si une charge utile est écrite dans un fichier puis exécutée → c’est la charge utile qui est évaluée
    • Une chaîne de commandes liée avec && → est évaluée comme une seule action
    • Si un script Python assemble une commande shell → la commande assemblée est évaluée à partir du contexte du transcript
  • Règles d’intention utilisateur (User intent rules) : il s’agit de déterminer si l’action de l’agent a été approuvée par l’utilisateur, et non simplement si elle est liée à l’objectif de l’utilisateur. Le classificateur est volontairement conservateur : tant que l’utilisateur ne l’a pas explicité, tout choix autonome de l’agent est considéré comme non approuvé
    • « Nettoie ma branche » → suppression en masse non approuvée
    • « Tu peux corriger ça ? » → interprété comme une question, pas comme une instruction
• Composition des emplacements de personnalisation :
  • Environnement (Environment) : définition des frontières de confiance — par défaut, seul le dépôt git en cours est considéré comme fiable. Il est possible d’ajouter une organisation GitHub, un bucket cloud, une API interne, etc.
  • Règles de blocage (Block rules) : plus de 20 règles par défaut, regroupées en 4 catégories :
    • Destruction ou fuite : écrasement de l’historique par force push, suppression massive d’un stockage cloud, envoi de données internes vers l’extérieur
    • Dégradation de la posture de sécurité : désactivation de la journalisation, installation de mécanismes de persistance comme des clés SSH ou des cron jobs, modification des paramètres d’autorisation de l’agent lui-même
    • Violation des frontières de confiance : exécution de code cloné depuis un dépôt externe, scan de magasins d’identifiants, envoi de données vers un service non spécifié par l’utilisateur
    • Contournement de revue ou impact sur autrui : push direct sur main, exécution d’un déploiement de production, modification de ressources partagées ou de jobs que l’agent n’a pas créés
  • Exceptions autorisées (Allow exceptions) : installation de paquets déjà déclarés dans le manifeste du dépôt, flux standard d’authentification, push vers la branche de travail de la session, etc.

Résultats de l’évaluation

• Le pipeline complet a été évalué sur 3 jeux de données :
  • Trafic interne réel (n=10 000) : vrais appels d’outils Claude Code effectués par des employés d’Anthropic
  • Vraies actions excessives (n=52) : collectées à partir de sessions refusées par les employés ou signalées a posteriori — jeu réduit, car il faut que Claude tente une action risquée dans une session réelle pour qu’elle soit collectée
  • Exfiltration synthétique de données (n=1 000) : génération de cas comme envoi de données sensibles en HTTP POST, push git vers une destination distante non fiable, identifiants inclus dans une URL, avec obfuscation incluse

	Trafic réel (n=10 000)	Actions excessives réelles (n=52)	Exfiltration synthétique (n=1 000)
Stage 1 (filtre rapide)	FPR 8.5%	FNR 6.6%	FNR 1.8%
Stage 1→2 (pipeline complet)	FPR 0.4%	FNR 17%	FNR 5.7%

• Le FNR de 17 % sur les vraies actions excessives est présenté honnêtement : le classificateur identifie bien les risques (force push, suppression, changements d’infrastructure, etc.), mais se trompe lorsqu’il doit juger si les signaux d’accord présents dans la session couvrent réellement le blast radius de l’action
• Si l’utilisateur a dit « nettoie la PR » sans mentionner explicitement un force push, le classificateur a parfois tendance à trouver des traces de validation et à ne pas vérifier assez strictement le périmètre, même lorsqu’une action similaire a été approuvée auparavant
• L’auto mode s’adresse aux groupes qui utilisent --dangerously-skip-permissions et n’est pas un remplacement immédiat d’une revue manuelle prudente sur des infrastructures à haut risque

Principales décisions de conception

• Suppression des messages de l’assistant et des résultats d’outils

  • Suppression du texte de l’agent : pour éviter qu’il ne produise des rationalisations destinées à convaincre le classificateur (« implicitement approuvé auparavant », « cette cible appartient à l’agent », etc.)
  • Suppression des résultats d’outils : première ligne de défense contre la prompt injection — les sorties d’outils sont la principale voie d’entrée de contenu hostile
  • Le classificateur peut prendre sa décision sans voir la charge utile : une action qui fait un POST du contenu d’un fichier .env vers une URL externe viole l’intention de l’utilisateur indépendamment du contenu
  • Quand les messages de l’assistant et les résultats d’outils sont inclus, les performances se dégradent sur le jeu de tests d’actions excessives — les transcripts courts, moins influencés par le cadrage de l’agent, sont plus précis

• Classification en deux étapes : efficacité et rappel

  • Avec une classification en une seule étape, le compromis performance/coût entre directement en conflit
  • Stage 1 : décision rapide à jeton unique, avec instruction de « faire des erreurs dans le sens du blocage » — cela accepte un FPR de 8,5 % pour obtenir un bon rappel
  • Stage 2 : même prompt que l’étape 1, seul le dernier ordre change pour demander un raisonnement prudent — le FPR passe de 8,5 % à 0,4 %
  • Comme le prompt de Stage 2 est presque identique à celui de Stage 1, il bénéficie de cache hits dans la plupart des cas — ce qui est plus efficace en coût

• Rôle de la sonde de prompt injection

  • La défense contre l’injection du classificateur de transcript est structurelle (il ne voit pas les résultats d’outils), mais l’agent principal, lui, voit les résultats d’outils
  • Si l’agent principal est détourné, il peut potentiellement contourner le moniteur de transcript → d’où la nécessité d’une sonde au niveau de l’entrée
  • Les deux couches agissent de façon complémentaire : pour qu’une injection réussisse, elle doit passer la couche d’entrée, puis le classificateur de transcript doit juger indépendamment et sans charge utile que l’appel d’outil résultant est sûr et conforme à l’intention de l’utilisateur

• Handoffs multi-agents

  • Le classificateur s’exécute à la fois au moment de la délégation vers un sous-agent (outbound) et au moment du retour du résultat (return)
  • Contrôle outbound : évite le problème où, à l’intérieur du sous-agent, l’instruction de l’orchestrateur peut ressembler à un « message utilisateur » et donc sembler entièrement approuvée
  • Contrôle au retour : couvre le cas où un sous-agent, normal au moment de la délégation, aurait été exposé à une prompt injection pendant son exécution — l’historique complet de ses actions est revu avant de transmettre le résultat à l’orchestrateur, avec ajout d’une alerte de sécurité en cas de signalement

• Bloquer et continuer (Deny-and-continue)

  • Quand le classificateur bloque une action, la session ne s’arrête pas : Claude est encouragé à essayer une alternative plus sûre
  • En cas de blocage, le résultat d’outil renvoie le motif du refus ainsi qu’une instruction demandant de « considérer la frontière de bonne foi et de chercher une voie plus sûre »
  • Après 3 blocages consécutifs ou 20 blocages au total → escalade vers un humain (en mode headless, le processus se termine)
  • Un FPR de 0,4 % peut sembler faible, mais si chaque faux positif mettait fin à la session, cela deviendrait un sérieux problème d’utilisabilité sur les tâches longues — cette structure permet de le traiter comme le coût d’une simple nouvelle tentative

Suite prévue

• Le jeu de tests de vraies actions excessives continuera à être étendu, et la sécurité comme le coût de la fonctionnalité seront améliorés de manière itérative
• Le classificateur n’a pas besoin d’être parfait : l’objectif est de bloquer suffisamment d’actions risquées pour rendre l’exécution autonome concrètement plus sûre qu’en l’absence totale de garde-fous
• Il est recommandé aux utilisateurs de rester conscients des risques résiduels, de garder leur jugement sur les tâches et environnements à confier à l’exécution autonome, et de fournir des retours en cas d’erreur de l’auto mode