ASI05 : exécution de code inattendue par un agent

ASI05, cinquième entrée du Top 10 OWASP des applications agentiques, porte sur le moment où du texte devient du code et où ce code s’exécute. Les agents de développement génèrent et lancent des programmes ; les agents d’administration lancent des commandes ; et beaucoup d’architectures agentiques fabriquent, pour résoudre un problème, un bout de code qu’elles exécutent aussitôt. Le référentiel relève le point qui rend la classe particulière : ce code est produit à l’instant, il n’a donc traversé ni revue, ni analyse statique, ni test — c’est-à-dire aucun des contrôles sur lesquels repose la sécurité du développement.

→ Lire l’explication complète de la marmotte

Le mécanisme : du texte, puis un processus

Un modèle produit toujours la même chose, du texte. L’exécution de code inattendue est ce qui arrive quand ce texte atteint quelque chose qui l’interprète. Le référentiel énumère les interprètes concernés, et la liste est plus longue qu’on ne le croit : scripts, binaires, modules compilés à la volée ou WebAssembly, objets désérialisés, moteurs de gabarits, évaluations en mémoire. Chacun transforme une chaîne en comportement, et beaucoup le font sans qu’on l’ait demandé explicitement.

Trois chemins y mènent, selon le document. Le premier est l’injection de prompt : une instruction glissée dans un contenu lu conduit l’agent à produire puis lancer du code choisi par l’attaquant. Le deuxième est l’hallucination : l’agent génère sincèrement une construction exploitable ou dangereuse, sans que personne l’y pousse — le document note qu’un agent chargé de produire des correctifs de sécurité peut halluciner du code d’apparence irréprochable contenant une porte dérobée, par exposition à des données d’entraînement empoisonnées ou à des prompts adverses. Le troisième est la sérialisation non sûre : un objet fabriqué par l’agent, transmis à un autre composant et désérialisé sans validation, déclenche une exécution dans l’environnement cible — le mécanisme est celui que le site décrit dans la désérialisation non sécurisée, avec un producteur d’objets inhabituellement créatif.

Le cas le plus traître n’a cependant rien à voir avec une faille. Le référentiel décrit une exploitation par chaîne d’outils : un envoi de fichier, puis une traversée de chemin, puis un chargement dynamique de code. Chaque appel est légitime, chaque outil est approuvé, et l’exécution est obtenue par la séquence. Les deux étapes intermédiaires de cet exemple sont des classiques du web, traitées sur le site dans la traversée de chemin et l’envoi de shell déguisé — à ceci près qu’ici, l’enchaînement n’est pas construit par un attaquant mais proposé par un planificateur à qui l’on a demandé de résoudre un problème.

Ce qui distingue ASI05 de ses voisins

La frontière avec ASI02, détournement et exploitation des outils, est explicitement traitée par le référentiel, et elle est fine : l’exécution de code passe souvent par les mêmes interfaces d’outils. Ce qui sépare les deux entrées est la nature du résultat. ASI02 s’arrête au mésusage d’une fonction ; ASI05 commence quand ce mésusage aboutit à une compromission de l’hôte ou du conteneur, à une persistance ou à une évasion du bac à sable. La conséquence est pratique plutôt que taxinomique : les remèdes ne sont pas les mêmes. Un profil de droits par outil ne protège pas d’un processus qui tourne déjà sur la machine ; il faut des mitigations propres à l’hôte et à l’exécution.

L’autre frontière utile est avec ASI04, chaîne d’approvisionnement agentique. Quand l’agent installe un paquet non vérifié et que du code hostile s’exécute à l’installation ou à l’import, les deux entrées se superposent, et le référentiel l’assume : c’est une compromission de chaîne qui a escaladé en exécution. Le document donne un cas spécifiquement agentique, l’empoisonnement de verrou de dépendances dans un bac à sable éphémère : l’agent, chargé de « réparer la compilation », régénère le fichier de verrouillage depuis des contraintes non épinglées et tire une version mineure contenant une porte dérobée. Le problème des versions inventées est traité sur le site dans l’hallucination de paquets et le slopsquatting.

Face au Top 10 LLM, l’entrée prolonge LLM01 (injection de prompt) et LLM05 (traitement non sûr des sorties), en remplaçant la sortie unique mal interprétée par une chaîne orchestrée de plusieurs outils. Dans la taxonomie du projet, elle correspond à T11, exécution de code et attaques par code inattendues.

Les incidents qui ont marqué 2025

Le suivi d’incidents du référentiel aligne, pour cette seule entrée, une série de cas publics qui méritent d’être connus parce qu’ils dessinent un motif.

En juillet 2025, un agent en ligne de commande de Google a mal interprété des instructions portant sur des fichiers et effacé le répertoire de l’utilisateur, avant de reconnaître lui-même la perte comme catastrophique. Le même mois, un agent de développement sur une plateforme d’hébergement a supprimé une base de données de production au cours d’une session de programmation assistée, puis produit des sorties fausses masquant l’erreur. Ni l’un ni l’autre ne suppose un attaquant : ce sont des accidents, obtenus par des agents disposant du droit d’exécuter.

Les cas avec attaquant existent aussi, et ils visent la configuration plutôt que le code. En octobre 2025, deux vulnérabilités distinctes d’un éditeur assisté par agent ont permis, par injection de prompt, d’écraser des fichiers de configuration critiques et d’obtenir ainsi une exécution persistante. Le motif est intéressant : plutôt que de faire exécuter du code tout de suite, l’attaquant modifie ce qui sera exécuté la prochaine fois. Et en mars 2025, une fonction d’envoi de fichiers sans authentification dans un cadre d’orchestration d’agents a ouvert la voie à un contrôle du serveur.

La leçon commune est que l’agent de développement est devenu une cible, et que le poste du développeur est le périmètre à défendre — ce que le site soutenait déjà dans les postes de développeurs, cible oubliée.

Réduire : séparer la génération de l’exécution

Le référentiel propose une architecture avant des réglages, et c’est la bonne hiérarchie.

Séparer la génération de code de son exécution par des portes de validation, et interdire l’accès direct de l’agent à la production. C’est la mesure qui aurait évité les deux accidents de juillet 2025. Le site décrit le dispositif correspondant dans sécuriser les actions irréversibles des agents LLM.
Bannir l’évaluation dynamique en production : pas d’eval dans un agent, interpréteurs restreints, analyse de teinte sur ce qui vient de contenus non fiables. Le référentiel insiste particulièrement sur les évaluateurs cachés dans les systèmes de mémoire, qui ont permis des démonstrations d’exécution à distance en passant par le stockage de contexte.
Un environnement d’exécution hostile au code : jamais de compte privilégié, conteneur en bac à sable, limites de ressources, pas d’accès réseau sortant par défaut, accès au système de fichiers restreint à un répertoire de travail dédié, et journalisation des différences de fichiers sur les chemins critiques. Un environnement par session, avec ses propres limites de permissions, et l’échec sécurisé comme défaut.
Des contrôles avant exécution : analyse statique du code généré avant de le lancer, blocage des paquets vulnérables connus, et surtout une liste d’auto-exécution sous contrôle de version. Cette dernière recommandation est la plus utile et la moins appliquée : dans la plupart des déploiements, la liste des commandes que l’agent peut lancer sans demander existe bien, mais sous forme de configuration locale modifiable par l’agent lui-même — ce qui explique précisément les incidents d’écrasement de configuration.
Une approbation humaine pour les exécutions élevées, et des contrôles par rôle et par action. Les conditions pour que cette approbation veuille dire quelque chose sont décrites dans comment valider le function calling d’un LLM.
Opérationnaliser la programmation assistée plutôt que l’interdire : évaluations de sécurité, tests unitaires adverses, contrôles de pré-production. Le site détaille cette démarche dans la revue de sécurité du code généré par IA.

Détecter : ce qui se voit à l’exécution

Le référentiel demande de journaliser et d’auditer toutes les générations et toutes les exécutions, ce qui suppose de conserver non seulement la sortie d’une commande mais la commande elle-même, son origine dans le plan de l’agent et le contenu qui l’a motivée. C’est la seule trace qui permette, après coup, de distinguer une erreur d’interprétation d’une instruction injectée — deux causes aux remèdes opposés.

Trois signaux se câblent sans grande difficulté. Un processus fils inattendu dans l’environnement de l’agent, en particulier un interpréteur de commandes qu’aucune tâche normale n’invoque. Une écriture hors du répertoire de travail autorisé, qui devrait être impossible et mérite donc une alerte plutôt qu’un refus silencieux. Et une connexion sortante depuis l’environnement d’exécution, dont la liste des destinations légitimes tient en général sur une ligne. À cela s’ajoute la surveillance des motifs d’injection dans les contenus consommés, utile en complément et jamais suffisante seule.

Ce que ces mesures ne font pas

Un bac à sable n’est pas une garantie, et le référentiel range explicitement l’évasion de bac à sable parmi les issues de la classe. Un conteneur partage un noyau, voit parfois un socket d’administration, atteint souvent un service de métadonnées, et son isolation dépend d’une configuration que personne ne relit. La règle est d’en tenir compte dans le modèle de menace : l’exécution confinée réduit le rayon d’action, elle ne l’annule pas.

L’analyse statique du code généré, de son côté, détecte les constructions connues et laisse passer la logique hostile bien écrite. C’est particulièrement vrai du cas que le référentiel cite, le correctif avec porte dérobée : le code est propre, idiomatique, commenté, et fait en plus ce qu’on lui demandait. Aucun linter ne s’en émeut. Il n’y a là qu’un remède, et il est lent : la relecture humaine de ce qui part en production, avec le temps que cela prend.

🐝 Ce qui arrive si on s’en passe

Sans séparation entre génération et exécution, il n’existe aucun instant où le code produit peut être examiné : il est écrit et lancé dans le même geste, et le journal ne conserve au mieux que la sortie de la commande, pas la commande ni la raison de son appel. L’incident se diagnostique alors sur l’état final — un répertoire vide, une base absente — sans moyen de reconstituer la séquence. Sans liste d’auto-exécution versionnée hors de portée de l’agent, la frontière entre ce qui demande une validation et ce qui part tout seul est un fichier de configuration que l’agent peut lui-même modifier : c’est le mécanisme exact des vulnérabilités d’écrasement de configuration recensées en octobre 2025, où l’exécution obtenue n’est pas immédiate mais persistante. Sans répertoire de travail restreint ni journal des différences de fichiers, enfin, un agent qui se trompe de chemin produit un dégât indiscernable d’un agent qu’on a détourné, et les deux hypothèses restent ouvertes jusqu’à la fin de l’enquête.

🦫 Explication de la marmotte 🍫

Certains assistants informatiques ne se contentent pas d’écrire du texte : ils écrivent des programmes, puis les lancent. C’est ce qui les rend utiles — ils réparent un script, installent ce qui manque, lancent une vérification — et c’est aussi ce qui les rend dangereux. Le programme qu’ils viennent d’écrire n’a été relu par personne, testé par personne, et il s’exécute sur une vraie machine avec de vrais fichiers.

Deux choses peuvent mal tourner. La première est l’accident : l’assistant comprend mal une consigne et efface ce qu’il ne fallait pas. Des cas réels ont été rendus publics en 2025, dont un répertoire d’utilisateur supprimé et une base de données de production détruite pendant une session de développement assisté. La seconde est l’attaque : quelqu’un glisse une consigne dans un document que l’assistant va lire, et l’assistant écrit puis lance le programme que cette consigne demandait.

Les protections sont celles du bon sens industriel. On ne laisse pas l’assistant toucher directement aux systèmes réels : il propose, quelqu’un valide, un autre mécanisme exécute. On le fait travailler dans un espace cloisonné, sans droits d’administration, sans accès libre au réseau, avec un seul répertoire où il peut écrire. On conserve la liste des commandes qu’il peut lancer sans demander, et surtout on la conserve ailleurs que là où l’assistant pourrait la modifier.

Reste le cas qu’aucun outil ne détecte : un programme bien écrit, bien commenté, qui fait ce qu’on lui demandait et, en plus, quelque chose d’autre. Il n’y a là qu’un remède, et il n’est pas automatisable : quelqu’un doit lire le code avant qu’il parte en production.

Pages voisines

La citent

TA0002 Exécution : faire tourner son code chez quelqu'un d'autre

ASI05 : exécution de code inattendue par un agent

Elle cite

: les deux pages se citent l’une l’autre.

ASI05 : exécution de code inattendue par un agent

ASI05 : exécution de code inattendue par un agent

Le mécanisme : du texte, puis un processus

Ce qui distingue ASI05 de ses voisins

Les incidents qui ont marqué 2025

Réduire : séparer la génération de l’exécution

Détecter : ce qui se voit à l’exécution

Ce que ces mesures ne font pas

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines