Ingénieur Ant inverse le code source de Claude Code : Pipeline de décision à 4 niveaux du Mode Auto et mécanisme de classificateur de sécurité exposés

Selon la surveillance de 1M AI News, un ingénieur d’Ant Group, auteur du framework front-end Umi.js, a effectué une rétro-ingénierie du code source de Claude Code 2.1.81, reconstituant entièrement ce qui se passe après l’appui sur le mode auto. La découverte principale : chaque appel d’outil doit passer par une chaîne de décision à quatre niveaux. Ce n’est que lorsque les trois premiers niveaux ne peuvent pas statuer qu’un classificateur AI indépendant est sollicité pour une vérification de sécurité.

Les quatre niveaux de la chaîne de décision sont : le premier vérifie les règles d’autorisation existantes, si elles correspondent, l’accès est autorisé directement ; le deuxième simule le mode acceptEdits (c’est-à-dire le niveau d’autorisation permettant de modifier des fichiers), si la requête passe dans ce mode, cela indique un faible risque, et le classificateur est ignoré ; le 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 conditions n’est remplie, le quatrième niveau est atteint, où une requête API indépendante est envoyée à Claude Sonnet pour une classification de sécurité.

Les détails clés de la conception du classificateur : il utilise toujours Sonnet plutôt qu’Opus, un compromis entre coût et latence ; la température est fixée à 0 pour garantir la détermination des sorties ; le classificateur est défini comme « le surveillant 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 est 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 d’autorisation concernent 7 cas : clés codées en dur pour les tests, opérations sur 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 sur la branche de travail courante.

Il existe é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 directement arrêté. Lorsqu’un classificateur n’est pas disponible, un drapeau de fonctionnalité contrôle si le mode est « fail-closed » (refus direct) ou « fail-open » (passage en confirmation manuelle).

Le mode auto avec injection de prompts de comportement dispose également d’un contrôle précis de la fréquence : une injection toutes les 5 interactions, avec la première de chaque cycle d’injection étant une version complète (environ 800 mots, incluant « exécuter immédiatement, réduire les interruptions, l’action prime sur le plan » et six autres instructions), et les 4 autres étant une version simplifiée, équilibrant l’occupation de la fenêtre de contexte et la stabilité du comportement.