L’essentiel
- Le chercheur Johann Rehberger décrit une attaque qui contourne le mode automatique de Claude Code Opus 5 dans quatre essais sur cinq.
- La technique fait décompresser une archive à l’agent, puis détourne un import Python anodin pour exécuter du code hostile.
- Dans plusieurs essais, la protection a laissé démarrer le processus malveillant, puis a refusé la commande censée l’arrêter.
- Sa recommandation : conteneur ou machine virtuelle, sorties réseau restreintes, aucun accès aux clés SSH ni aux identifiants cloud.
Le fichier s’appelle struct.py. Il sort d’une archive zip que l’agent a téléchargée puis décompressée dans son répertoire de travail, sur simple demande. Quelques secondes plus tard, il s’exécute à la place du module standard du même nom, et le code d’un inconnu tourne sur la machine. Johann Rehberger a rejoué cette séquence contre le mode automatique de Claude Code Opus 5 : elle passe quatre fois sur cinq.
Un faux struct.py suffit à prendre la main
Johann Rehberger, l’un des chercheurs les plus actifs sur les injections de prompt (des instructions malveillantes glissées dans les données que lit l’agent, et qu’il finit par traiter comme des ordres), a monté une chaîne d’attaque qui ne réclame aucune faille logicielle. L’agent refuse d’abord de lancer le décodeur livré dans l’archive, qu’il juge opaque, et écrit son propre script Python pour faire le travail. Ce script importe base64, un module utilitaire de la bibliothèque standard. Or Python cherche ses modules en commençant par le dossier du script. Le struct.py de l’archive passe donc avant celui de la bibliothèque standard, que base64 appelle en cascade, et le code de l’attaquant s’exécute. À aucun moment l’agent ne rapproche ce fichier de l’archive qu’il vient d’ouvrir : sa prudence l’a conduit à écrire lui-même l’outil qui le compromet.
Du point de vue du classificateur de sécurité, la séquence reste banale : télécharger un fichier, le décompresser, lancer un script. Trois gestes que tout développeur pose vingt fois par jour. L’hostilité tient à leur enchaînement, pas à leur contenu. Prise isolément, aucune de ces commandes ne justifie un refus.
Quand la protection empêche le nettoyage
Dans plusieurs essais, Claude a détecté que la machine était infectée et a tenté de tuer le processus. Le mode automatique a refusé la commande de nettoyage.
Le même dispositif a donc autorisé la création du processus indésirable, puis interdit l’ordre destiné à l’interrompre. Il s’est trompé deux fois, et la seconde fois du mauvais côté : contre la remédiation. Une protection qui laisse entrer l’attaque et bloque les secours retire à l’utilisateur sa capacité de réaction au moment précis où il en a besoin.
Un classificateur note des actions isolées, sans modèle de l’intention ni mémoire de la scène. Tuer un processus, supprimer des fichiers, couper une connexion : ces gestes ressemblent statistiquement à ceux d’un code hostile. La défense n’a aucun moyen de savoir qu’elle empêche un sauvetage.
Une garde probabiliste face à un attaquant qui rejoue
Anthropic a fait de ce mode le réglage actif d’office, et publie ses propres mesures : 17 % de faux négatifs sur des actions dangereuses réelles, celles où l’agent déborde par excès de zèle, 5,7 % sur des tentatives d’exfiltration de données simulées. L’éditeur qualifie lui-même ce premier chiffre d’honnête. Activer une protection par défaut, c’est prendre l’engagement à la place de l’utilisateur, y compris de ceux qui n’ouvriront jamais la documentation.
Le chercheur mesure autre chose : un attaquant qui a préparé sa chaîne. Il donne deux séries, quatre réussites sur cinq pour la variante qui écrit un fichier, trois sur cinq quand l’attaque ouvre un canal de commande à distance. Cinq essais par série, c’est peu, et l’ordre de grandeur compte davantage que la décimale. L’asymétrie, elle, se voit : un attaquant ne joue pas un coup unique, il itère hors ligne contre une cible immobile jusqu’à ce qu’une variante passe. Remonter le score du classificateur de quelques points n’y change rien.
Les deux camps n’en tirent pas la même conclusion. Le chercheur recommande d’exécuter les agents en environnement isolé, quand Anthropic juge cette isolation sûre mais coûteuse à entretenir, chaque nouvelle capacité demandant sa configuration, et destine le mode automatique à ceux qui, sinon, couperaient toute demande de permission. Ses concurrents ont tranché dans l’autre sens : Codex enferme par défaut les commandes qu’il exécute dans un bac à sable imposé par le système, réseau coupé et écriture limitée à l’espace de travail, tandis que Jules fait tourner chaque tâche dans une machine virtuelle Google jetable. Chez eux, l’isolement est dans l’architecture. Ici, il est dans le conseil d’usage.
L’isolement, seule couche qui ne négocie pas
Les mesures que recommande le chercheur s’installent en une après-midi : conteneur, machine virtuelle ou isolation fournie par le système pour faire tourner un agent sans surveillance, sorties réseau restreintes, activité journalisée, et surtout aucun accès du processus au répertoire personnel, aux clés SSH ou aux identifiants cloud.
La différence de nature compte autant que la liste. Un classificateur estime ; un conteneur contraint. Un agent qui ne dispose pas d’une clé ne peut pas l’exfiltrer, quelle que soit l’habileté du prompt qui l’y invite. C’est la seule garantie qui ne dépende pas de la qualité d’une inférence.
- Faire tourner l’agent dans un conteneur jetable, recréé à chaque tâche.
- Inventorier ce que le processus voit réellement : ~/.ssh, ~/.aws, tokens de dépôt, fichiers .env.
- Limiter les sorties réseau aux dépôts et registres strictement nécessaires.
- Conserver un journal des commandes exécutées, relu après coup.
Les chiffres publiés restent ceux de l’éditeur, produits sur ses propres jeux de test, sans qu’aucun tiers puisse les rejouer. Entre 17 % d’actions dangereuses manquées côté Anthropic et quatre attaques réussies sur cinq côté chercheur, l’écart tient d’abord aux scénarios testés. Tant qu’un protocole commun ne permet pas de les comparer, activer une garde d’office déplace surtout la confiance de l’utilisateur, sans réduire d’autant son exposition.
Mon avis
Un classificateur de sécurité ne devrait jamais fonctionner comme une autorisation implicite de lancer un agent hors bac à sable, et c’est pourtant l’effet pratique d’un mode activé d’office. Je préfère un agent bavard qui me demande tout dans un conteneur jetable à un agent silencieux qui tranche seul sur ma machine, avec mes clés à portée de main. Anthropic a eu le mérite de publier son taux d’échec, y compris le mauvais ; ce qui manque désormais, c’est un protocole que des tiers puissent rejouer sur les mêmes scénarios, chez tous les éditeurs. Quand un incident coûtera vraiment cher à une équipe, personne n’ira demander des comptes au classificateur.
