Quand un prompt devient un shell : ce que Microsoft a trouvé dans les frameworks d'agents

Le 7 mai 2026, la Microsoft Defender Security Research Team a publié « When Prompts Become Shells », une analyse des chemins par lesquels une injection de prompt peut se transformer en exécution de code à distance dans les frameworks d'agents les plus utilisés : LangChain, AutoGen et Semantic Kernel. Pour ce dernier, développé par Microsoft lui-même, l'équipe a divulgué deux vulnérabilités critiques, CVE-2026-25592 et CVE-2026-26030, corrigées depuis.

La démonstration de Microsoft est volontairement sobre : une seule instruction, glissée dans le contenu traité par l'agent, suffisait à lancer un programme sur la machine qui l'exécutait. Pas d'exploit navigateur, pas de pièce jointe piégée, pas de corruption mémoire. Juste du texte, lu par un agent qui avait les moyens d'agir.

Comment fonctionne un framework d'agents

Un framework d'agents fait le lien entre un modèle de langage et le reste du monde. Le développeur déclare des outils (Semantic Kernel parle de « plugins », LangChain de « tools », AutoGen fournit des exécuteurs de code), et le modèle décide, à chaque étape, lequel appeler et avec quels arguments. Le framework se charge ensuite d'exécuter réellement l'appel : lire un fichier, interroger une base, lancer du code.

Toute la sécurité de ce modèle repose sur un point : les arguments que le modèle transmet aux outils doivent être traités comme une entrée non fiable. Car le modèle ne les invente pas seul : il les déduit de tout ce qu'il a lu, y compris des documents, des emails, des pages web ou des lignes de base de données qu'un attaquant a pu écrire. Si le framework fait confiance à ces arguments, l'attaquant qui contrôle le texte contrôle l'outil.

Le changement de nature

C'est le cœur de l'analyse de Microsoft. Tant qu'un modèle ne fait que produire du texte, une injection de prompt reste un problème de contenu : une réponse fausse, un ton détourné, une information divulguée. Dès qu'il est branché à des outils (exécution de code, système de fichiers, requêtes réseau), la même injection devient un problème d'exécution. La gravité ne dépend plus du modèle, mais de ce que ses outils ont le droit de faire.

Le problème n'est pas nouveau. Dès 2023, LangChain avait corrigé CVE-2023-29374 : sa chaîne LLMMathChain, conçue pour résoudre des calculs, faisait exécuter en Python l'expression produite par le modèle. Une question bien formulée suffisait à transformer un calcul en code arbitraire. Trois ans plus tard, les frameworks ont gagné en sophistication, mais la frontière de confiance est restée au même endroit fragile : entre ce que le modèle décide et ce que la machine exécute.

Une épidémie, pas un incident

La publication de Microsoft n'est pas isolée. Le suivi mensuel d'Adversa AI recense six divulgations confirmées d'exécution de code ou d'évasion de sandbox dans des frameworks agentiques pour le seul mois de mai 2026. Plusieurs équipes de recherche parlent désormais d'épidémie. L'explication est structurelle : chaque nouveau framework réinvente son registre d'outils, et avec lui sa propre frontière de confiance, souvent mal placée, parce que l'objectif premier est que l'agent « fasse les choses », pas qu'il en soit empêché.

Pour les équipes qui intègrent ces frameworks dans un produit, la conséquence est concrète. Un agent de support qui lit les tickets clients, un assistant qui résume des emails, un outil interne qui analyse des documents : tous lisent du contenu écrit par des tiers. Si l'un d'eux dispose, même indirectement, d'un outil capable d'exécuter du code ou d'écrire des fichiers, chaque ticket, chaque email, chaque document devient un vecteur potentiel.

Ce qui protège vraiment

Puisque le modèle finira toujours par lire une instruction malveillante, la défense porte sur ce qui se passe ensuite. Quatre principes font l'essentiel :

1. 1.Mettre à jour le framework. Les deux CVE Semantic Kernel sont corrigées ; les versions vulnérables ne le seront jamais.
2. 2.Donner à l'agent le strict minimum d'outils. Un agent qui résume des emails n'a aucune raison d'avoir accès à un shell, ni à l'écriture de fichiers.
3. 3.Isoler toute exécution de code : conteneur jetable, système de fichiers en lecture seule, aucun secret, aucun accès réseau sortant par défaut.
4. 4.Traiter le contenu récupéré comme une saisie utilisateur, et exiger une validation humaine pour les actions irréversibles (paiement, suppression, envoi).

Pour le troisième point, la plupart des frameworks proposent un exécuteur basé sur Docker plutôt qu'une exécution directe sur l'hôte ; AutoGen, par exemple, fournit les deux. Quel que soit l'outil, le conteneur doit être fermé par défaut. Les options Docker standards suffisent pour poser l'essentiel :

docker run --rm \
  --network none \
  --read-only --tmpfs /tmp \
  --cap-drop ALL --security-opt no-new-privileges \
  --pids-limit 128 --memory 512m --cpus 1 \
  -v "$PWD/job:/job:ro" \
  python:3.12-slim python /job/task.py

Pourquoi un bac à sable en Python n'en est pas un

Beaucoup d'outils d'exécution de code commencent par une tentative de sandbox « applicative » : exécuter le code généré dans le même processus, en retirant certaines fonctions dangereuses ou en filtrant l'arbre syntaxique. L'histoire de Python montre que cette approche ne tient pas. Le langage expose trop de mécanismes d'introspection (chaque objet donne accès à sa classe, chaque classe à ses sous-classes) pour qu'une liste d'interdits couvre tous les chemins vers une fonction dangereuse. La CVE LangChain de 2023 en est un exemple direct.

La frontière doit donc être au niveau du système d'exploitation, pas du langage. Par ordre d'isolation croissante : un conteneur avec des capacités réduites et un profil seccomp, un noyau applicatif comme gVisor qui intercepte les appels système, ou une micro-VM de type Firecracker, conçue pour exécuter du code non fiable de plusieurs clients sur la même machine. Le choix dépend du niveau de confiance accordé au contenu que l'agent lit, et pour un agent exposé au web, ce niveau est nul.

Le service de métadonnées, cible prioritaire

Sur une instance cloud, l'adresse 169.254.169.254 sert le service de métadonnées, qui délivre notamment les identifiants temporaires du rôle attaché à la machine. C'est la première cible d'un outil HTTP détourné : l'étude arXiv sur les serveurs MCP exposés cite d'ailleurs explicitement des SSRF visant ce service. Sur AWS, imposer IMDSv2 exige un jeton obtenu par une requête PUT préalable, et limiter le nombre de sauts réseau à 1 empêche les conteneurs de l'instance de l'atteindre :

aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required \
  --http-put-response-hop-limit 1

L'exfiltration par le rendu

Un agent sans aucun outil réseau peut encore faire sortir des données, par sa réponse elle-même. Si l'interface affiche la réponse du modèle en Markdown, une image dont l'URL contient des données (une clé, un extrait de conversation) est chargée automatiquement par le navigateur de l'utilisateur. Le serveur de l'attaquant reçoit la donnée dans ses logs, sans que personne ait cliqué. La défense est côté interface : ne pas rendre les images externes dans les réponses du modèle, ou restreindre leurs domaines via la Content-Security-Policy (directive img-src).

Enfin, journaliser chaque appel d'outil (nom, arguments, contenu qui a déclenché l'appel, résultat) n'empêche rien, mais c'est la seule façon de reconstituer après coup ce qu'un agent a fait, et pourquoi. Un appel à un outil d'exécution juste après la lecture d'un document externe est exactement le signal à surveiller.

Ce qu'on vérifie de l'extérieur

La partie de ce risque qui se voit depuis Internet, ce sont les endpoints d'agents exposés. Quand detektd trouve un serveur MCP (Model Context Protocol) accessible sans authentification, le scan liste les outils qu'il expose, en lecture seule, sans jamais les appeler. La sévérité dépend de ce que ces outils permettent : un serveur qui expose un shell, un accès aux fichiers, des requêtes SQL ou des appels HTTP arbitraires à n'importe quel visiteur est classé comme élevé : c'est exactement la situation que décrit Microsoft, sans même avoir besoin d'une injection de prompt.