Faille MCP Azure DevOps : un commentaire de PR caché qui détourne les agents IA de revue de code

> En bref : Une faille dans le serveur MCP Azure DevOps de Microsoft permettait à un commentaire de pull request caché de manipuler les agents IA de revue de code qui le consomment. En plantant un commentaire que l'agent allait lire mais qu'un réviseur humain raterait probablement, un attaquant pouvait instructer l'agent d'approuver des changements malveillants, d'ignorer du code dangereux, ou de leak du contenu du dépôt. C'est une instance concrète du risque d'injection de prompt sur la couche MCP (Model Context Protocol) qui connecte désormais les agents IA à l'infrastructure de développement.

Pourquoi ça vous concerne

Le MCP (Model Context Protocol) est devenu la façon standard pour les agents IA d'atteindre des outils externes — dépôts, ticketing, bases de données, API internes. Si votre équipe d'ingénierie utilise Copilot, Cursor, Claude Code ou tout agent qui lit des pull requests ou des tickets, MCP est vraisemblablement dans le chemin. Le serveur MCP Azure DevOps est l'une des intégrations les plus déployées de ce type.

La classe de faille démontrée ici n'est pas spécifique à Microsoft. C'est le problème central de l'injection de prompt appliqué à un outil dev à forte confiance : toute source de données que l'agent lit devient un canal d'instruction, et les commentaires de PR sont contrôlables par l'attaquant.

La faille en deux phrases

Les agents IA de revue de code connectés via le MCP Azure DevOps lisent les commentaires de PR dans leur contexte. Un commentaire caché — replié, dans un thread caché, formaté pour être sauté par un humain mais parsé par l'agent — pouvait porter des instructions que l'agent exécutait ensuite : approuver la PR, marquer des problèmes comme résolus, ou résumer et exfiltrer le contenu de fichiers dans un canal sortant.

Le bug, c'est la frontière manquante entre *les données que l'agent lit* et *les instructions que l'agent obéit*. Le serveur MCP passait fidèlement le contenu des commentaires dans le contexte de l'agent sans séparation, sans allow-listing, sans marquage de taint.

Pourquoi MCP multiplie le risque

Le MCP a été conçu pour uniformiser l'appel d'outils : un protocole, plein de serveurs, n'importe quel agent. Le trade-off, c'est que la même uniformité offre à l'attaquant une surface d'injection générique. Dès qu'un agent lit des données contrôlées par l'attaquant via un serveur MCP, chaque outil que l'agent peut appeler — approuver, merger, commenter, lire un fichier, appeler un webhook — devient une primitive potentielle d'exfiltration ou de contournement d'autorisation.

Dans le contexte dev-workflow spécifiquement, l'agent tourne typiquement avec les permissions de l'auteur ou du réviseur. Donc une injection réussie ne produit pas juste une mauvaise réponse — elle produit une mauvaise action *autorisée* : une vraie approval sur une vraie PR, enregistrée sous l'identité d'un vrai salarié.

Ce qu'il faut faire

Le pattern

Cette faille est la version MCP de l'injection de prompt indirecte, la même classe qu'on voit sur les pipelines RAG et les outils de chatbot. La défense est la même : supposez la couche données hostile, scopez l'autorité de l'agent au minimum, et gardez l'humain dans la boucle sur les actions irréversibles. Ce qui est neuf, c'est que MCP rend la portée de l'agent large et uniforme — ce qui veut dire que la même injection atteint désormais vos dépôts, vos tickets et votre CI/CD en un seul protocole.