Les ingénieurs d'Ant ont effectué une rétro-ingénierie du code source de Claude, révélant le mécanisme de la chaîne de décision à quatre niveaux du mode Auto.

Voici la traduction complète et corrigée en fr-FR :

Informations de Gate News, le 25 mars, un ingénieur d’Ant Group, auteur du framework front-end Umi.js, Chen Cheng, a effectué une rétro-ingénierie du code source de Claude Code 2.1.81, reconstituant intégralement le mécanisme de décision du Mode Automatique. La découverte principale : chaque appel d’outil doit passer par une chaîne de décision en quatre étapes ; ce n’est que lorsque les trois premières étapes ne permettent pas de déterminer une réponse que le classificateur AI indépendant est sollicité pour une vérification de sécurité.

La chaîne de décision en quatre étapes est la suivante : la première vérifie les règles de permission existantes, si elles correspondent, l’accès est autorisé directement ; la deuxième simule le mode acceptEdits (niveau de permission permettant de modifier des fichiers), si la requête passe dans ce mode, cela indique un risque faible, et le classificateur est ignoré ; la troisième vérifie la liste blanche des outils en lecture seule (Read, Grep, Glob, LSP, WebSearch, etc.), qui ne modifient aucun état, et sont donc autorisés sans condition ; si aucune de ces étapes n’est satisfaite, la quatrième étape consiste à envoyer une requête API indépendante à Claude Sonnet pour une classification de sécurité.

Les détails clés de la conception du classificateur incluent : l’utilisation systématique de Sonnet plutôt que d’Opus, pour un compromis entre coût et latence ; la température réglée à 0 pour garantir la déterminisme des sorties ; le classificateur étant défini comme « le superviseur de sécurité d’un agent de programmation AI autonome », protégeant contre trois types de risques (injection de prompts, propagation de portée, dommages accidentels) ; le fichier de configuration CLAUDE.md de l’utilisateur étant injecté dans le contexte du classificateur, servant de base pour interpréter l’intention de l’utilisateur.

Les règles d’interception couvrent plus de 22 catégories, notamment : force push, push direct sur la branche main, téléchargement et exécution de code externe, déploiement en production, fuite de données, modification autonome des permissions, création de vecteurs d’exécution de code à distance, fuite de credentials, etc. Les exceptions à l’autorisation incluent 7 cas : clés codées en dur pour les tests, opérations sur des fichiers locaux dans le répertoire de travail, requêtes GET en lecture seule, installation de dépendances déclarées, installation d’outils officiels, lecture de credentials de configuration envoyés au fournisseur cible, push vers la branche de travail courante.

Le système intègre également un mécanisme de circuit breaker : après 3 refus consécutifs ou 20 refus cumulés, le système passe en mode dégradé nécessitant une confirmation manuelle ; en mode headless, l’agent est simplement arrêté. Lorsqu’un classificateur est indisponible, un drapeau de fonctionnalité (feature flag) contrôle si le comportement est « fail-closed » (refus immédiat) ou « fail-open » (passage en confirmation manuelle).

Dans le Mode Automatique, l’injection de prompts d’action est contrôlée avec précision : une injection toutes les 5 interactions, avec la première de chaque cycle d’injection d’environ 800 mots (incluant « exécuter immédiatement, réduire les interruptions, l’action prime sur la planification » et six autres instructions), et les 4 autres étant une version simplifiée en une ligne, pour équilibrer l’occupation de la fenêtre contextuelle et la stabilité du comportement.