MOSAIC : pourquoi 96% des coding agents IA tombent dans le piège

Tu utilises Claude Code, Cursor, Codex ou un autre coding agent pour aller plus vite ? Ces outils enchaînent des commandes terminal pour toi : git clone, npm install, npm run build. Chaque commande est légitime. Mais un papier publié en juillet 2026 montre que l'enchaînement de ces commandes normales, dans un environnement piégé, suffit à compromettre 96% des coding agents. Sans une seule instruction malveillante dans le prompt.

Le papier s'appelle MOSAIC (arXiv:2607.02857), publié le 3 juillet 2026 par des chercheurs de Sun Yat-sen University et Shandong University entre autres. Il introduit un concept nouveau : le CLI command-composition risk, ou CCR. C'est pas de la prompt injection. Les défenses existantes ne le détectent pas. Et il n'y a pas de patch pour le problème structurel.

Voici comment ça marche, pourquoi le sandbox ne suffit pas, et ce que tu peux faire.

Le problème : les commandes normales qui se combinent en attaque

Un coding agent fonctionne en enchaînant des commandes CLI. git clone pour récupérer un repo, npm install pour installer les dépendances, npm run build pour compiler. Chaque commande écrit et lit dans un état partagé : variables d'environnement, hooks git, scripts de cycle de vie des paquets npm, fichiers dans node_modules.

Individuellement, chaque commande est bénigne. Mais ensemble, elles forment une chaîne producteur-consommateur. La commande A écrit quelque chose que la commande B lit et exécute. C'est le design normal d'Unix, et c'est exactement ce que MOSAIC exploite.

Concrètement : un attaquant publie un repo avec un script postinstall caché dans package.json. Tu demandes à ton coding agent d'auditer le projet. L'agent fait git clone (récupère le repo), puis npm install (installe les dépendances, ce qui déclenche le hook postinstall), puis npm run build. Le hook s'exécute pendant le build et exfiltre ta variable AWS_SECRET_ACCESS_KEY depuis l'environnement. L'agent n'a jamais lancé une commande qu'il n'aurait pas lancée normalement.

Version plus subtile : l'attaquant empoisonne les git hooks. git clone écrit le dossier .git/hooks. Quand l'agent fait ensuite git commit ou git push, le hook de l'attaquant s'exécute. Clone écrit, commit exécute. Deux opérations de routine, un payload déclenché.

Les chiffres : 96,59% de succès, et le modèle ne change rien

MOSAIC a été testé sur 5 coding agents CLI réels avec 5 backend LLMs différents, sur 2 525 tentatives. Taux de succès : 96,59%. Le modèle utilisé (GPT-5.6, Claude Sonnet 5, et trois autres) ne change pas le résultat. Le type d'agent non plus. Le problème est architectural : il vient de la façon dont les coding agents utilisent le terminal, pas de la façon dont ils raisonnent.

Le benchmark complémentaire, MOSAIC-Bench (arXiv:2605.03952), teste 9 agents de production issus d'Anthropic, OpenAI, Google, Moonshot, Zhipu et Minimax. Les taux de succès end-to-end vont de 53 à 86%. Sur l'ensemble des runs, les agents ont refusé d'exécuter... deux fois. Deux refus sur des centaines de séquences d'attaque. Tout le reste a passé.

Pourquoi le sandbox ne résout rien

Tous les grands fournisseurs ont livré des sandbox en 2026. Anthropic a ajouté des modes de permission restreints à Claude Code. OpenAI fait tourner Codex en environnement isolé. Google Cloud Run Sandboxes est passé en disponibilité générale début juillet. Aucun de ces sandbox ne bloque CCR.

La raison : le sandbox restreint ce à quoi l'agent peut accéder, pas ce qu'il peut être amené à faire dans son périmètre autorisé. Les variables d'environnement se propagent à l'intérieur du sandbox. Les hooks de paquets npm s'exécutent dans le sandbox. Les git hooks s'exécutent dans le sandbox. Le payload de l'attaquant se déclenche entièrement dans la zone légitime de l'agent. Il n'y a rien à bloquer.

Microsoft l'a résumé dans un billet de sécurité de mai 2026 : « l'attaquant n'a pas besoin d'échapper au sandbox, l'usage normal des outils par l'agent est le chemin d'exécution ». Et TrustFall, une faille divulguée en juin 2026, a montré que Claude Code, Cursor, Gemini CLI et Copilot auto-exécutent les configs MCP définies dans un projet dès qu'on ouvre le dossier, avant même que le sandbox s'initialise.

Un exemple chez Maisons&Mobilia

Antoine, le dev lead de Maisons&Mobilia (M&M), utilise Claude Code pour auditer un repo open source que l'équipe veut intégrer. Il ouvre le projet, demande à l'agent de vérifier les dépendances et de lancer les tests.

L'agent enchaîne : git clone, npm install, npm run test. Le package.json contient un script postinstall qui écrit une clé AWS dans un fichier temporaire. Le npm run test lit ce fichier et l'envoie vers un endpoint externe dans un test déguisé en vérification d'environnement. Antoine n'a vu que des commandes normales dans les logs. Le sandbox de Claude Code n'a rien bloqué : chaque commande était dans les permissions accordées.

La parade d'Antoine : il relance l'audit dans une VM éphémère sans credentials, avec un token à courte durée. Le hook se déclenche, mais il n'y a rien à voler. La VM est détruite après le run.

Ce que tu peux faire maintenant

Aucun patch ne viendra pour le problème structurel. CCR n'est pas un bug qu'on corrige, c'est une conséquence de la façon dont les coding agents travaillent. Cinq mitigations réduisent le risque.

Environnements éphémères. Chaque tâche de l'agent doit tourner dans une VM fraîche, sans état antérieur. Sans état partagé entre les commandes, la chaîne producteur-consommateur ne peut pas se former. Modal, Daytona et E2B proposent ce type d'environnement.

Strip credentials. Ne lance jamais un coding agent avec des credentials longue durée dans l'environnement. Utilise des tokens à courte durée, des rôles d'instance, ou Workload Identity Federation. Si le hook se déclenche, il n'y a rien à exfiltrer.

Allowlists de commandes. Définis explicitement ce que l'agent peut lancer. Les denylists se contournent facilement avec des astuces shell. Les allowlists obligent l'attaquant à connaître ta politique.

Audit des logs. Logge chaque commande lancée par l'agent avec la tâche d'origine et le contexte. Détecte les séquences où une opération en lecture précède une écriture inattendue.

Traitement non fiable. Applique aux runs CI assistés par IA le même scepticisme qu'à du code tiers qui tourne dans ton pipeline.

Pourquoi c'est important au-delà des devs

Tu n'es pas développeur ? La question te concerne quand même. Les coding agents s'intègrent partout dans les workflows : CI/CD, revue de code, génération de tests, déploiement. Si un assistant IA peut être piégé en lui faisant exécuter des commandes normales dans un environnement compromis, la confiance qu'on accorde à ces outils dans les entreprises est sur fondations fragiles.

Le parallèle avec la prompt injection est direct. La prompt injection attaque la couche d'instructions (du texte malveillant qui se fait passer pour une commande). CCR attaque la couche d'exécution (des commandes légitimes qui se combinent en attaque). Les deux profitent du même décalage : l'agent fait confiance à son environnement, et l'environnement peut être manipulé.

Le point clé à retenir : les coding agents ne sont pas dangereux parce qu'ils désobéissent. Ils sont dangereux parce qu'ils obéissent parfaitement, dans un environnement qu'ils ne contrôlent pas.

Aller plus loin

Pour comprendre comment un agent IA décompose une tâche et appelle des outils, lis c'est quoi un agent IA. Pour la sécurité côté prompt (l'autre vecteur d'attaque), la prompt injection décrypte le texte piégé. Et pour le cadre plus large des garde-fous à mettre autour d'un agent, les garde-fous des agents IA fait le tour.

Dans l'app saisir.ai, le parcours Code & sécu traite du périmètre, du moindre privilège et de la prompt injection pour que tu saches où sont les limites avant de les franchir.