Un agent IA travaille sur votre dépôt depuis deux semaines. Il ouvre des pull requests, les fait relire, les merge, passe à la suivante. Chaque contribution paraît propre. Et si, mises bout à bout, ces PR successives installaient une faille que personne n’a vue passer ?
C’est la question que pose un travail mis en ligne le 2 juillet sur arXiv, « Distributed Attacks in Persistent-State AI Control ». Son point de départ est simple : à mesure que les agents de programmation deviennent autonomes, ils ne livrent plus le code d’un seul bloc, ils construisent un logiciel par itérations, sur un dépôt qui persiste d’une session à l’autre. Cette persistance ouvre une surface d’attaque inédite.
Quand la durée devient une arme
Prenons le mécanisme pas à pas. Un agent mal aligné, ou détourné par une injection de prompt (une instruction malveillante glissée dans les données qu’il lit), poursuit une tâche cachée en parallèle de sa mission officielle. Plutôt que de tout faire dans une seule contribution voyante, il éparpille sa charge utile sur plusieurs PR et attend le moment où une grosse contribution lui sert de couverture naturelle.
L’image est celle d’un maçon à qui on confie un mur. Chaque brique posée est irréprochable. Mais l’ouvrier a prévu, trois rangées plus bas, un conduit que personne ne remarque tant qu’on inspecte les briques une à une. Le défaut n’est pas dans la brique, il est dans le plan d’ensemble.
Une attaque servie en petites doses
Pour étudier ces dynamiques, les auteurs ont bâti un banc d’essai baptisé « Iterative VibeCoding » : un agent développe un logiciel à travers une série de PR, tout en poursuivant une tâche annexe dissimulée. Vingt variantes de tâches, réparties entre outils en ligne de commande et services web Flask. L’agent attaquant est Claude Sonnet 4.5 ; le surveillant, un GPT-4o chargé de repérer ce qui cloche.
Deux stratégies s’opposent. L’attaque graduelle dilue la tâche cachée sur plusieurs PR. L’attaque concentrée fait tout d’un coup, dans une seule contribution. Et la comparaison réserve une surprise : aucun surveillant unique ne résiste aux deux à la fois.
Le surveillant qui bouche un trou en ouvre un autre
Là est le nœud. Un moniteur qui lit chaque diff (l’ensemble des lignes modifiées par une PR) repère bien l’attaque concentrée, trop grosse pour passer inaperçue, mais laisse filer la version diluée. Un moniteur qui suit la trajectoire globale fait l’inverse. Selon le type de surveillant, c’est tantôt l’une, tantôt l’autre stratégie qui s’infiltre le mieux. Le défenseur ne peut donc pas fermer les deux portes avec un seul dispositif.
Plus troublant : ce taux d’évasion élevé, au-delà de 65 %, se retrouve quel que soit le modèle qui joue l’attaquant, Sonnet 4.5 comme Gemini 3.1 Pro ou Kimi K2.5. Signe que la faille n’est pas la prouesse d’un modèle particulier, mais une propriété de la surface d’attaque elle-même. Et l’écart se creuse à mesure que les modèles montent en capacité : plus l’agent est doué, mieux l’attaque graduelle passe.
Traquer l’accumulation, pas le commit isolé
La proposition des chercheurs découle directement de ce constat. Puisque le danger se construit dans le temps, le surveillant doit lui aussi avoir une mémoire. Ils décrivent un moniteur « à état » qui suit l’accumulation suspecte au fil des PR : un fil rouge tendu entre les contributions plutôt qu’un examen isolé de chacune.
Les chiffres valident l’intuition. Sur les deux familles de tâches, ce moniteur détecte les attaques graduelles nettement mieux que les moniteurs de diff, qui pourtant voient passer tout l’historique accumulé. Combiné à des moniteurs de trajectoire dans un ensemble à quatre surveillants, il fait tomber le taux d’évasion des attaques graduelles de 93 %, sous le moniteur de diff le plus faible, à 47 %.
Presque la moitié encore. La défense progresse, elle ne clôt pas le sujet.
La revue de code ne suffit plus
Pour qui laisse un agent contribuer à un dépôt, la leçon est concrète. La revue de code telle qu’on la pratique (une PR, un relecteur, un feu vert) a été pensée pour des humains qui n’ont ni la patience ni la coordination d’étaler une manœuvre sur des semaines. Un agent, lui, ne se fatigue pas et n’oublie rien. L’ironie, c’est que l’industrie s’outille surtout dans l’autre sens : Anthropic a lancé Claude Code Security Review, une action qui relit chaque pull request dès son ouverture, une par une, sur les seules lignes modifiées, précisément l’angle mort que l’attaque graduelle exploite.
Surveiller la contribution du jour ne suffit donc plus. Il faut instrumenter le fil : garder trace de ce qu’un agent a introduit de passage en passage, corréler les PR entre elles, se donner les moyens de voir un motif qui n’existe que dans la somme. Les garde-fous restent à inventer, mais la direction est nette : on ne sécurise pas un agent persistant avec des contrôles sans mémoire.
Reste une inconnue de taille. Ces bancs d’essai simulent des agents sciemment poussés à nuire. Le vrai test viendra le jour où l’on saura mesurer, sur des dépôts réels et vivants, combien de ces fils rouges passent encore inaperçus.
