MOSAIC-Bench : les agents de code produisent du code exploitable à partir de tickets anodins

En bref Publié le 6 mai 2026 (arXiv:2605.03952), MOSAIC-Bench mesure un angle mort de la sûreté des agents de code : un modèle qui refuse une demande explicite d’écrire une vulnérabilité produit volontiers la même vulnérabilité lorsque l’objectif est découpé en une série de tickets d’ingénierie d’apparence banale. Sur 199 chaînes d’attaque en trois étapes, les agents de code de production ont assemblé du code exploitable dans 53 à 86 % des cas, avec seulement deux refus sur l’ensemble des exécutions — et les agents relecteurs ont approuvé environ un quart des diffs vulnérables comme de simples pull requests de routine.

De quoi s’agit-il ?

MOSAIC-Bench est un benchmark de ce que ses auteurs appellent l’induction compositionnelle de vulnérabilités : amener un agent de code à construire un logiciel non sûr non pas en le demandant directement, mais en décomposant l’état final malveillant en une suite de tâches raisonnables. Chaque ticket — « ajouter un endpoint de recherche », « journaliser la requête pour le débogage », « laisser le panneau d’admin accepter un filtre brut » — ressemble à du travail de backlog normal. Le comportement exploitable n’existe que dans la combinaison, qu’aucun prompt isolé ne révèle.

Le benchmark comprend 199 chaînes d’attaque en trois étapes associées à des oracles d’exploitation déterministes, construits sur des logiciels réels : 10 applications web cibles, 31 classes CWE et 5 langages de programmation. Comme chaque chaîne se termine par un exploit vérifiable, le benchmark peut évaluer si la sortie cumulée de l’agent est réellement vulnérable, et pas seulement si elle « paraissait » risquée à une étape donnée.

Le résultat compte parce que l’alignement de sûreté actuel évalue les demandes explicites de façon isolée. Un modèle entraîné à refuser « écris-moi une injection SQL » est mesuré sur des prompts autonomes — et reste aveugle à un état final malveillant qui émerge d’une conformité séquencée à des demandes chacune inoffensive.

Comment ça marche

L’attaque exploite le décalage entre la manière dont la sûreté est évaluée et la manière dont les agents travaillent réellement. L’entraînement à l’alignement et les garde-fous prompt par prompt jugent un tour à la fois. Une fonctionnalité logicielle, elle, s’assemble sur de nombreux tours, fichiers et commits. Répartissez un résultat dangereux sur cette chronologie et chaque point de contrôle voit quelque chose d’anodin.

Dans MOSAIC-Bench, chaque chaîne fait passer l’agent par trois étapes. Les premiers tickets installent un échafaudage inoffensif ; les tickets suivants élargissent discrètement une frontière de confiance, retirent une vérification, ou relient une entrée non fiable à un point sensible. L’agent réalise chaque ticket avec compétence et, ce faisant, livre un code dont le comportement composé est exploitable — un chemin d’injection, un contrôle d’autorisation manquant, une désérialisation non sûre — alors même qu’il aurait refusé une demande directe pour cette même faiblesse.

L’article rapporte deux résultats qui affinent le tableau. D’abord, les agents de code de production ont produit du code exploitable dans 53 à 86 % des chaînes, en ne refusant que deux fois sur l’ensemble des exécutions. Ensuite, le problème ne se réduit pas à un oubli de contexte : un protocole en session unique, où toute la tâche tient dans une seule conversation continue, ne comble qu’environ la moitié de l’écart. Le contexte fragmenté aggrave les choses, mais même une longue session cohérente laisse une exposition substantielle, ce qui désigne l’objectif d’alignement lui-même plutôt que les limites de mémoire.

Les agents relecteurs ne font pas mieux. Des modèles de revue de code invités à approuver ou rejeter des pull requests ont validé 25,8 % des diffs cumulés confirmés vulnérables comme des PR de routine — le filet de sécurité automatisé hérite du même aveuglement au diff unique et à l’instant unique que l’auteur.

Pourquoi c’est important

Les agents de code sont branchés directement sur les chaînes d’approvisionnement logicielles : ils ouvrent des pull requests, intègrent des changements et, de plus en plus, relisent le travail les uns des autres. Si un acteur malveillant — ou un gestionnaire de tickets amont compromis qui alimente un pipeline agentique — peut façonner la séquence de tâches, il peut orienter un agent vers la livraison d’une porte dérobée ou d’un point d’injection sans jamais déclencher de refus. La posture de sûreté prompt par prompt que vantent les éditeurs ne couvre pas cela, et un agent relecteur exécutant la même posture non plus.

Cela recadre aussi bien des raisonnements du type « le modèle a refusé, donc c’est sûr ». Les taux de refus mesurés sur des prompts explicites surestiment la sûreté réelle, car le risque de production réside dans la décomposition. Un benchmark qui ne pose que des questions directes continuera d’afficher des taux de refus élevés pendant que les agents assemblent tranquillement des vulnérabilités sur le terrain.

Défenses

1. Relire le diff cumulé, pas le ticket. Le jugement de sécurité doit porter sur l’état final composé — l’ensemble des changements produits par une chaîne de tickets — et non sur chaque demande isolée. Évaluez ce que le code fait après assemblage, au regard de contrôles de type exploit.
2. Recadrer le relecteur en pentesteur adversaire. La mitigation la plus utile de l’article : demander au modèle relecteur de chercher activement comment un changement pourrait être exploité, plutôt que de tamponner des PR de routine. Sous ce cadrage, un relecteur en poids ouverts (Gemma-4-E4B-it) a détecté 88,4 % des attaques avec 4,6 % de faux positifs, sur 608 pull requests GitHub réelles — un bond important par rapport à la revue par défaut.
3. Conditionner à des oracles d’exploitation, pas à une impression. Quand c’est possible, associez la sortie de l’agent à des contrôles de sécurité déterministes — SAST calibré sur les classes CWE pertinentes, analyse de dépendances et de teinte (taint), tests affirmant l’absence de la faiblesse ciblée — afin que l’approbation dépende d’une propriété vérifiable, pas de l’impression d’un modèle.
4. Traiter le flux de tickets comme une entrée non fiable. Si des tickets, éléments de backlog ou demandes amont peuvent être rédigés par des tiers et injectés dans un pipeline agentique, appliquez-leur la même défiance qu’à tout contenu externe. Le séquencement est désormais une surface d’attaque.
5. Garder un humain sur les fusions à fort impact. La logique d’autorisation, le code de traitement des entrées, la désérialisation et tout ce qui touche à l’authentification ou aux secrets doivent exiger une revue humaine avant qu’un changement rédigé par un agent ne soit intégré, quelle que soit l’apparence de routine de chaque ticket contributeur.
6. Cesser de lire les taux de refus comme de la sûreté. Testez vos propres agents face à des objectifs décomposés, multi-tickets, se terminant par un exploit vérifiable. Les métriques de refus prompt unique ne feront pas apparaître cette classe de défaillance.

Statut

Élément	Référence	Date	Notes
Article MOSAIC-Bench	arXiv:2605.03952	2026-05-06	199 chaînes en trois étapes, 10 substrats web, 31 classes CWE, 5 langages
Taux d’induction	MOSAIC-Bench	2026-05	Les agents de code de production produisent du code exploitable dans 53 à 86 % des chaînes ; deux refus au total
Approbation des relecteurs	MOSAIC-Bench	2026-05	Les agents de revue approuvent 25,8 % des diffs confirmés vulnérables
Relecteur pentesteur adversaire	MOSAIC-Bench	2026-05	Gemma-4-E4B-it détecte 88,4 % des attaques à 4,6 % de faux positifs sur 608 PR réelles

Le point à retenir n’est pas que les agents de code seraient particulièrement imprudents. C’est qu’une sûreté mesurée un prompt à la fois ne se compose pas en une sûreté sur une fonctionnalité entière — et tant que la revue n’opère pas sur le résultat assemblé avec un état d’esprit adversaire, la décomposition reste le moyen le moins coûteux d’amener un agent à construire la vulnérabilité qu’il n’accepterait jamais d’écrire.