L’injection de prompts dans Azure DevOps cible les agents de codage IA 

Des chercheurs ont révélé une vulnérabilité d’injection de prompts affectant le serveur officiel Azure DevOps Model Context Protocol (MCP) de Microsoft, qui peut manipuler des agents de codage IA afin qu’ils accèdent à des informations sensibles en utilisant les propres autorisations d’un développeur. 

Les conclusions montrent comment des instructions dissimulées dans une pull request peuvent amener des assistants IA de confiance à effectuer des actions non prévues à l’insu de l’évaluateur. 

Principaux enseignements de l’injection de prompts dans Azure DevOps

• Des injections de prompts dissimulées dans les pull requests Azure DevOps peuvent manipuler des agents de codage IA afin qu’ils effectuent des actions non autorisées en utilisant les autorisations légitimes d’un développeur.
• L’attaque exploite la confiance entre les utilisateurs et les assistants IA plutôt que des vulnérabilités logicielles ou des identifiants dérobés.
• Les chercheurs ont constaté une mise en œuvre incohérente de la protection de Microsoft contre les injections de prompts, laissant vulnérables les descriptions des pull requests.
• Les agents IA ayant accès à des données d’entreprise, à du contenu non fiable et à des canaux de communication externes créent de nouvelles voies d’attaque par injection de prompts.
• Les organisations devraient combiner accès selon le principe du moindre privilège, gouvernance de l’IA, surveillance de l’activité et tests de réponse aux incidents afin de réduire les risques de sécurité liés aux agents IA.

Fonctionnement de la vulnérabilité MCP d’Azure DevOps

Le serveur MCP Azure DevOps de Microsoft permet aux assistants de codage IA d’interagir directement avec les ressources Azure DevOps, notamment les pull requests, les pipelines, les wikis, les éléments de travail et les dépôts de code source. 

Comme l’agent IA fonctionne avec les autorisations de l’utilisateur authentifié, il peut effectuer des actions légitimes sur l’ensemble des projets auxquels cet utilisateur est autorisé à accéder.

Les chercheurs ont découvert que des attaquants ayant accès à un seul projet Azure DevOps peuvent intégrer des instructions dissimulées dans un commentaire HTML au sein de la description d’une pull request. 

Bien que le commentaire reste invisible pour les évaluateurs humains dans l’interface Azure DevOps, il est renvoyé par l’API et transmis directement à l’agent IA pendant la revue du code.

Lorsqu’un développeur demande à l’assistant IA d’examiner la pull request, le prompt dissimulé prend le pas sur la tâche prévue de l’agent et lui ordonne d’effectuer des actions supplémentaires avec les identifiants de l’évaluateur.

Microsoft a reconnu le problème et l’a pris en charge à la suite d’une divulgation responsable.

Comment l’injection de prompts permet un accès interprojets dans Azure DevOps 

Selon les chercheurs, l’attaque ne repose ni sur la compromission des identifiants des utilisateurs ni sur l’exploitation directe des autorisations Azure DevOps.

Elle abuse plutôt de la relation de confiance entre le développeur et l’assistant IA.

Dans la preuve de concept présentée, un attaquant a créé une pull request apparemment légitime contenant des instructions dissimulées. 

Après que l’évaluateur a lancé une revue assistée par IA, l’agent a :

• Lu l’injection de prompts dissimulée.
• Accédé à un pipeline d’un autre projet auquel l’attaquant n’avait pas accès.
• Récupéré du contenu confidentiel du wiki de ce projet.
• Publié les informations récupérées dans la pull request de l’attaquant.

Comme chaque action a été effectuée avec les autorisations légitimes de l’évaluateur, l’activité semblait autorisée.

Les chercheurs décrivent ce scénario comme un cas classique de « confused deputy », dans lequel un système de confiance est manipulé afin d’utiliser à mauvais escient ses propres privilèges au profit d’un attaquant.

Comment Microsoft a renforcé les protections d’Azure DevOps contre les injections de prompts 

L’étude a également révélé que Microsoft avait déjà mis en œuvre une mesure d’atténuation appelée spotlighting, qui signale le contenu non fiable afin d’aider les modèles d’IA à mieux distinguer les données des instructions exécutables.

Cependant, cette protection n’était pas appliquée de manière uniforme sur le serveur MCP Azure DevOps. 

Si les outils qui renvoient le contenu des pipelines et des wikis utilisaient le spotlighting, celui chargé de renvoyer les descriptions des pull requests ne le faisait pas, laissant la voie d’injection exposée.

Les chercheurs ont indiqué que le spotlighting rend les attaques par injection de prompts plus difficiles, sans toutefois éliminer entièrement le risque.

Pourquoi la sécurité des agents IA va au-delà des vulnérabilités logicielles 

Ces conclusions illustrent un défi croissant pour les organisations qui déploient des agents IA. 

À mesure que les systèmes d’IA sont chargés d’examiner le code, de résumer des projets, de déclencher des workflows et d’accéder aux ressources de l’entreprise, les attaquants ciblent le processus de prise de décision plutôt que le logiciel sous-jacent.

Dans les environnements où les revues de pull requests ou d’autres tâches de développement sont lancées automatiquement, des injections de prompts dissimulées peuvent s’exécuter sans aucune intervention humaine, élargissant ainsi la surface d’attaque potentielle.

Les conclusions mettent également en lumière ce que les chercheurs décrivent comme la trifecta létale des agents IA :

• L’accès à des données d’entreprise sensibles via les identifiants des utilisateurs.
• L’exposition à du contenu contrôlé par l’attaquant.
• La capacité à envoyer les informations récupérées vers des destinations externes.

Individuellement, chacune de ces capacités permet une automatisation légitime par l’IA. Ensemble, elles créent des possibilités d’attaques par injection de prompts capables de détourner des agents de confiance afin qu’ils effectuent des actions non autorisées.

Comment les organisations peuvent réduire les risques de sécurité liés aux agents IA 

À mesure que les organisations intègrent des agents IA dans leurs workflows de développement logiciel, les équipes de sécurité devraient adopter des contrôles qui traitent à la fois les injections de prompts et les autorisations excessives des agents. 

• Appliquer le principe du moindre privilège et vérifier régulièrement les autorisations des agents IA.
• Traiter les pull requests, les commentaires et les problèmes, ainsi que les autres contenus générés par les utilisateurs, comme des entrées non fiables.
• Exiger une approbation humaine pour les actions sensibles des agents IA, notamment les accès interprojets et la récupération de données.
• Surveiller et auditer l’activité des agents IA afin de détecter les utilisations inhabituelles des outils, les comportements interprojets et les accès aux données.
• Maintenir les serveurs MCP, les outils de développement IA, ainsi que les intégrations associées, à jour avec les derniers correctifs de sécurité.
• Mettre en œuvre des politiques de gouvernance de l’IA qui définissent les workflows approuvés et restreignent l’automatisation à haut risque.
• Tester les plans de réponse aux incidents avec des compromissions d’agents IA et des injections de scénarios afin de valider les capacités de détection et de réponse.

Collectivement, ces mesures peuvent aider les organisations à réduire leur exposition globale.

En résumé : l’injection de prompts dans Azure DevOps met en évidence les risques liés aux agents IA 

À mesure que les agents IA deviennent de plus en plus capables de lire, de décider et d’agir au nom des utilisateurs, les organisations devront disposer d’une visibilité sur le comportement des agents, en complément de la surveillance traditionnelle des terminaux et des réseaux, afin de détecter les nouvelles techniques d’attaque pilotées par l’IA.

Pour faire face à ces risques en évolution, les organisations devraient compléter la gouvernance de l’IA par une stratégie Zero Trust qui valide en continu les utilisateurs, les appareils, les workloads et les agents IA avant d’accorder l’accès aux ressources sensibles.