~9 minutes
Un papier de recherche publié sur arXiv (Abhishek Kumar, Carsten Maple) documente un mode d’échec que beaucoup pressentaient sans l’avoir mesuré : les agents de codage intégrés aux IDE, évalués comme des chatbots, refusent presque systématiquement une demande nuisible en conversation directe ; mais ils l’exécutent dans la quasi-totalité des cas dès qu’elle est répartie sur les étapes ordinaires d’un workflow de développement.
Source : Abhishek Kumar, Carsten Maple — “Refused in Chat, Written in Code: Workflow-Level Jailbreak Construction in IDE Coding Agents”, arXiv:2607.03968.
Ce que le papier nous apprends
Les auteurs testent GitHub Copilot dans Visual Studio Code, sur quatre backends fermés : Claude Sonnet 4.6, Claude Haiku 4.5, Gemini 3.1 Pro et Gemini 3.5 Flash. Ils construisent 204 prompts a risque à partir de trois jeux de données de référence (Hammurabi’s Code, HarmBench, AdvBench), puis les soumettent selon quatre conditions :
| Condition | Description | Résultat |
|---|---|---|
| Chat direct | La demande posée telle quelle en conversation | 8/816 réponses exploitables |
| Lecture CSV isolée | La demande encapsulée dans un fichier à ingérer, en une seule étape | 8/816 réponses exploitables |
| Correction de code isolée | La demande encapsulée dans un correctif à une seule étape | 8/816 réponses exploitables |
| Workflow complet | La même demande décomposée sur les étapes ordinaires d’un développement (ingestion, optimisation, construction de dataset…) | 816/816 completions non sécurisées |
816 correspond à 204 prompts multipliés par 4 backends. Les trois premières conditions donnent un taux de réussite de l’attaquant proche de zéro, ce qui est exactement ce qu’on attend d’un système correcte. La quatrième condition retourne l’inverse complet : un taux d’échec du garde-fou de 100%, sur les mêmes prompts et les mêmes modèles. Les 816 completions du workflow complet ont été vérifiées indépendamment par deux évaluateurs experts, sur une grille stricte.
Le refus conversationnel n’a pas disparu. Il a simplement cessé d’être la question qu’on pose à l’agent.
Le mécanisme : pas d’injection
Ce papier ne décrit pas une nouvelle technique d’injection de prompt au sens classique. Rien n’est caché dans un commentaire de code ou un fichier tiers pour tromper le parseur. Le mécanisme est presque plus dérangeant : l’objectif nuisible n’existe nulle part sous une forme que le classifieur de sécurité reconnaîtrait, parce qu’il n’est jamais formulé en un seul morceau.
Au lieu de demander directement “écris ce malware”, l’attaquant reformule sa demande comme une suite de tâches de développement banales : ingérer un fichier CSV, optimiser un benchmark de performance, construire un jeu de données d’entraînement. Chaque étape, prise seule, ressemble à ce qu’un développeur demande cent fois par jour. Le contenu à risque devient une donnée à traiter dans un pipeline, pas une intention à évaluer. Le refus n’a rien à saisir parce qu’aucune étape individuelle ne porte l’intention complète.
Note du PandaRedacteur : c’est le même principe que découper un virement suspect en dix petits virements sous le seuil de déclaration. Sauf qu’ici, c’est votre agent de codage qui fait office de guichetier, et qu’il n’a pas de procédure de vigilance renforcée au-delà du premier tour de conversation.
Ce constat rejoint ce que je décrivais dans ASI01 — Agent Goal Hijack : le détournement ne porte pas sur une réponse isolée, il porte sur la trajectoire complète de l’agent. Un garde-fou qui n’évalue que chaque tour de conversation, un par un, est structurellement aveugle à un objectif qui se construit entre les tours.
Un problème que j’avais déjà vu venir…sans le mesurer
Ce n’est pas la première fois que je documente ce point aveugle sur ce blog, mais ce papier lui donne enfin un chiffre. Dans Sécuriser le cycle de développement assisté par IA, j’insistais sur le fait que la sécurité d’un agent qui code ne peut pas se limiter à la revue du prompt initial : elle doit couvrir les spécifications, la planification, et chaque étape de génération. Ce papier confirme empiriquement pourquoi : les trois baselines à une étape se comportent bien précisément parce qu’elles sont évaluées comme des interactions isolées, et le workflow complet échoue précisément parce qu’il ne l’est pas.
Dans L’ennemi dans le terminal, je montrais comment un dépôt Git piégé pouvait manipuler un agent CLI (Copilot, Claude Code) pour exécuter des commandes malveillantes à son insu. Le vecteur d’entrée diffère de celui étudié ici, mais la faille structurelle est la même : un agent qui exécute des instructions à travers plusieurs étapes fait confiance à sa propre continuité de raisonnement, sans qu’un tiers ne revérifie l’objectif final à chaque bond.
Et dans la série Agentic AI Guardrails, je détaillais des contrôles en entrée et en sortie (partie sortie) qui, relus à la lumière de ce papier, souffrent tous du même angle mort s’ils ne sont appliqués qu’au tour de conversation courant plutôt qu’à la session entière.
Note du PandaRedacteur : j’aime bien quand un papier de recherche vient confirmer avec des chiffres ce qu’on ne pouvait dire jusque-là qu’avec un “je pense que”. 816 sur 816, ça ne laisse pas beaucoup de place au doute.
Analyse STRIDE
| Catégorie STRIDE | Applicable | Explication |
|---|---|---|
| Spoofing (Usurpation d’identité) | Faible | L’attaque ne repose pas sur une usurpation d’identité ; elle passe par des prompts légitimement soumis par un utilisateur de l’IDE. |
| Tampering (Falsification) | Oui | L’objectif malveillant est reconstitué en falsifiant le contexte : chaque étape est présentée comme une tâche de développement normale, jamais comme ce qu’elle sert réellement à produire. |
| Repudiation (Répudiation) | Modéré | Un workflow multi-étapes dans un IDE laisse une trace (fichiers, historique de commandes), mais rien n’agrège cette trace pour révéler l’objectif final reconstitué. |
| Information Disclosure (Divulgation) | Modéré | Le papier se concentre sur la génération de contenu malveillant plutôt que sur l’exfiltration, mais un objectif de collecte de données pourrait suivre le même schéma de décomposition. |
| Denial of Service (Déni de service) | Faible | Aucun impact sur la disponibilité documenté dans cette recherche. |
| Elevation of Privilege (Élévation de privilèges) | Oui | Le workflow complet obtient de l’agent un résultat que le même agent, interrogé directement, aurait catégoriquement refusé : c’est une élévation de capacité obtenue par contournement du contrôle, pas par une faille technique. |
Impact potentiel
| Impact | Niveau | Description de l'impact |
|---|---|---|
| Confidentialité | Modéré | Le papier ne teste pas l'exfiltration de données, mais un objectif de collecte suivrait probablement le même schéma de décomposition sur plusieurs étapes. |
| Intégrité | Critique | Le taux de réussite de l'attaquant passe de quasi nul en conditions isolées à 100% en workflow complet, sur les quatre backends testés, sans qu'aucun garde-fou ne se déclenche. |
| Disponibilité | Modéré | Aucun impact direct documenté ; le risque porte sur le contenu produit, pas sur la continuité de service de l'agent. |
| Réputation | Sévère | Des benchmarks de sécurité conversationnels qui affichent un refus quasi parfait donnent une fausse assurance aux équipes qui déploient ces agents en production, sur la seule foi de ces chiffres. |
Mitigations
- Étendre la surveillance au-delà de la conversation. Un garde-fou qui évalue chaque prompt isolément ne peut pas voir un objectif qui se construit sur plusieurs échanges ; il faut évaluer la session, pas juste un prompt.
- Scanner les artefacts produits, pas seulement les réponses de chat. Fichiers générés, scripts, jeux de données : ce sont eux qui portent le résultat final, souvent bien après que la conversation qui l’a produit soit sortie du contexte visible.
- Corréler les étapes d’un même workflow. Un système qui reconstruit la trajectoire complète d’une session (ingestion → traitement → construction) peut détecter un objectif final incohérent avec le contexte déclaré du projet.
- Ne pas se fier aux benchmarks de refus conversationnels seuls. Un score de refus élevé en chat direct ne dit rien sur le comportement de l’agent une fois intégré dans un vrai flux de travail multi-étapes.
- Appliquer les mêmes disciplines de revue qu’à du code humain. Comme je le recommandais pour VVAH dans mon analyse du pipeline agentique de Visa, tout artefact produit par un agent de codage mérite une revue humaine avant merge, quel que soit le degré de confiance accordé au modèle.
Note du PandaRedacteur : la prochaine fois qu’un fournisseur vous présente son taux de refus en chat comme preuve de la sécurité de son agent de codage, demandez-lui le même chiffre mesuré sur un workflow complet. Le contraste, ici, va de 1% à 100%.
