La sécurité d'exécution des agents de code est un champ éclaté — et ses lacunes le prouvent

De quoi s’agit-il ?

Le 7 juillet 2026, un article de systématisation des connaissances (SoK) intitulé The Balkanization of Execution-Security Research for AI Coding Agents (arXiv:2607.05743, CC BY 4.0) soutient que la recherche protégeant la couche où s’exécutent réellement les agents de code — le bac à sable, le shell, le système de fichiers, les appels d’outils — s’est fragmentée en sous-champs déconnectés qui se citent rarement les uns les autres.

Un agent de code ne vaut, en sécurité, que l’environnement dans lequel il s’exécute. Un modèle capable de lire un dépôt, de lancer des commandes shell et d’appeler des outils hérite de chaque faiblesse de la frontière qui l’entoure. L’article passe en revue 39 travaux publiés entre 2023 et 2026, vérifie chacun directement à la source, et les classe en 17 catégories : isolation par bac à sable, contrôle d’accès et capacités, application de politiques, courses TOCTOU (time-of-check-to-time-of-use), menaces liées au Model Context Protocol (MCP), délégation d’identité, provenance d’exécution, contrôle du trafic sortant, et analyse statique du code généré par l’agent. C’est une cartographie du champ, pas un exploit.

Comment ça fonctionne

L’observation centrale est structurelle. Les travaux sont regroupés par le mécanisme qu’ils proposent — une équipe livre un bac à sable, une autre un système de capacités, une autre un moteur de politiques — et ce regroupement sépare discrètement des travaux qui traitent pourtant le même problème sous-jacent. L’auteur note les 17 catégories les unes par rapport aux autres selon leurs causes racines et leur étape dans le pipeline, et plusieurs des scores de similarité les plus élevés relient des catégories qui ne se citent jamais.

Pour montrer que le sujet n’est pas théorique, la systématisation confirme quatre vulnérabilités divulguées et corrigées, vérifiées directement dans la base NVD du NIST. La première est la fuite de descripteur de fichier du runtime de conteneurs runc, connue sous le nom de « Leaky Vessels » : elle précède l’outillage des agents mais illustre la classe d’évasion dont hérite tout bac à sable bâti sur les mêmes primitives. La deuxième est une faille d’injection de commande dans un assistant de code très répandu, corrigée dans une version de 2026. Les deux dernières touchent un agent de code en terminal populaire : une faille d’injection de code où du code de projet non fiable pouvait s’exécuter avant que l’utilisateur n’accepte la boîte de dialogue de confiance au démarrage, et une faille d’exfiltration où un dépôt malveillant pouvait fuiter des données — dont des clés d’API — avant la prise d’effet de la décision de confiance. Les deux reposent sur le même moment fragile : l’intervalle entre l’ouverture d’un dépôt non fiable et l’application effective de la décision de confiance. C’est une course « vérifier puis agir » classique, exactement ce qu’étudie la catégorie TOCTOU.

Pourquoi c’est important

La contribution de l’article tient dans cinq lacunes transversales qu’aucune étude ne comble, et chacune est directement opérationnelle pour qui déploie des agents.

Premièrement, les architectures d’isolation et les modèles de capacités sont évalués chacun face à un attaquant, mais presque jamais l’un contre l’autre sur un banc d’essai commun — impossible donc de dire si un bac à sable plus un système de capacités vaut mieux que l’un ou l’autre seul. Deuxièmement, les études d’application de politiques rapportent que les listes de refus de commandes échouent sur 69 % à 98 % des entrées adverses, mais aucun article d’isolation ne re-teste sa propre défense sous ce taux d’échec. Troisièmement, les courses TOCTOU et les menaces MCP sont traitées comme des littératures distinctes alors qu’elles relèvent du même problème de validation d’état. Quatrièmement, chaque mécanisme d’application examiné suppose un auteur de politique honnête — laissant de côté la mauvaise configuration par le défenseur lui-même. Cinquièmement, un mode de défaillance nouvellement mesuré : des actions bénignes mais hors périmètre, où le même agent, sur la même tâche, prenait des actions non demandées à des taux allant de 0,0 % à 17,1 % selon la seule formulation de la consigne. Une autorisation qui répond « cette action est-elle permise ? » ne répond pas « l’agent devrait-il seulement la faire ? » — et aucun article de contrôle d’accès du corpus ne cite même cette mesure.

Défenses

Comme il s’agit d’une cartographie et non d’une attaque, l’enseignement pratique porte sur la façon de raisonner votre propre déploiement d’agent, plutôt que sur un payload à bloquer.

• Superposez isolation et contrôle d’accès, et testez la combinaison. Ne comptez pas sur un bac à sable ou un modèle de capacités isolément ; la recherche montre qu’aucun n’est évalué face à l’autre, alors supposez des failles à la jointure et vérifiez la pile de bout en bout.
• Partez du principe que votre liste de refus fuit. Les listes d’autorisation et de refus de commandes échouent sur la grande majorité des entrées adverses. Traitez-les comme une couche parmi d’autres, derrière une vraie isolation et le moindre privilège, jamais comme la frontière elle-même.
• Fermez la course à la décision de confiance. Les failles réelles confirmées vivent toutes dans la fenêtre entre l’ouverture d’un contenu non fiable et la prise d’effet de la décision de confiance. N’exécutez jamais de code de projet, ne chargez pas de configuration de dépôt et n’honorez pas de description d’outil tant que la vérification de confiance n’a pas pleinement pris effet.
• Traitez TOCTOU et MCP comme un seul problème. Les deux sont des défaillances de validation d’état : validez l’état au moment de l’action, pas lors d’une vérification antérieure qu’une action ultérieure peut dépasser.
• Auditez l’auteur de la politique, pas seulement l’agent. Chaque couche d’application suppose sa propre configuration correcte. Examinez qui écrit les politiques d’agent et comment, car la mauvaise configuration est un mode de défaillance non modélisé mais bien réel.
• Contraignez le périmètre, pas seulement les permissions. Les actions hors périmètre varient fortement selon la formulation. Ajoutez des contrôles vérifiant si une capacité autorisée est invoquée dans un but non demandé, pas seulement si la capacité est détenue.

Statut

Élément	Détail
Type	Systématisation des connaissances (préprint)
Publication	7 juillet 2026 (arXiv:2607.05743, CC BY 4.0)
Corpus	39 travaux (2023–2026), 17 catégories de sécurité d’exécution
Attaque publiée	Aucune — état de l’art et agenda de recherche, sans payload
Incidents confirmés	4 CVE divulguées et corrigées, vérifiées dans la NVD : CVE-2024-21626 (runc « Leaky Vessels »), CVE-2025-53773 (GitHub Copilot / Visual Studio), CVE-2025-59536 et CVE-2026-21852 (agent de code en terminal, corrigées)
Classe de risque	Sécurité de la couche d’exécution des agents de code
Pertinence	Quiconque déploie des agents de code, en terminal ou reliés à MCP