Microsoft passe en open source l'outillage de red team qu'il utilise sur ses propres agents IA
Guides pratiques pour vous protéger — vous, votre famille et votre entreprise — contre les arnaques liées à l'IA, les deepfakes et les nouvelles menaces cyber.
Articles populaires
Microsoft passe en open source la stack de red team d'agents IA qu'il utilise en interne
Le 20 mai 2026, l'AI Red Team de Microsoft — l'unité interne qui met à l'épreuve les systèmes IA de l'entreprise — a publié deux outils de sécurité sur GitHub : RAMPART, un framework pytest-native pour red-teamer en continu des agents IA dans la CI, et Clarity, un outil structuré de revue de design qui pousse à interroger les décisions d'architecture avec lesquelles un agent est figé. Les deux sont gratuits. Les deux ont été utilisés en interne chez Microsoft avant la sortie.
La sortie compte parce que, jusqu'à cette semaine, le workflow de red team IA de Microsoft était surtout inaccessible à toute personne extérieure à Microsoft.
Ce que font vraiment ces outils
RAMPART — Risk Assessment and Measurement Platform for Agentic Red Teaming — s'appuie sur PyRIT, la bibliothèque open source de red teaming d'IA générative que Microsoft a publiée en 2024. Là où PyRIT s'adresse à des chercheurs en sécurité qui sondent un système fini, RAMPART s'adresse aux ingénieurs qui en livrent un. Les tests sont écrits sous forme de cas pytest, chacun décrivant un scénario adverse — cross-prompt injection, exfiltration de données, régression comportementale — et routés vers l'agent via un adaptateur léger. Les résultats pass/fail conditionnent le build CI exactement comme le ferait un test d'intégration. Ram Shankar Siva Kumar, fondateur de l'AI Red Team de Microsoft, raconte que l'équipe response de l'entreprise a utilisé RAMPART pour générer 100 variantes d'une seule vulnérabilité signalée et vérifier les mitigations contre chacune — un travail qui aurait pris des semaines aux experts Microsoft, achevé en quelques heures.
- RAMPART est livré avec des exemples d'adaptateurs, supporte des re-runs probabilistes avec des seuils de réussite configurables, et est conçu pour vivre dans la même pull request que le changement d'agent qu'il teste.
- Clarity orchestre des conversations structurées qui couvrent la définition du problème, l'exploration de solutions, l'analyse des modes d'échec et le suivi des décisions — chaque résultat étant écrit dans un dossier .clarity-protocol/ sous forme de markdown lisible par un humain.
- L'analyse des modes d'échec de Clarity utilise plusieurs « thinkers » IA qui examinent un design proposé sous des angles différents — sécurité, facteurs humains, scénarios adverses, préoccupations opérationnelles — puis l'équipe d'ingénierie traite ensemble les résultats regroupés.
Pourquoi c'est important
La surface d'attaque des agents IA a été documentée dans des incidents rien que ce mois-ci : le worm npm Mini Shai-Hulud qui a touché Mistral AI et TanStack, le zero-day de contournement de 2FA conçu par IA que le Threat Intelligence Group de Google a intercepté en environnement réel, le motif de prompt injection Comment and Control qui a détourné Claude Code, Gemini CLI et Copilot Agent la même semaine. Le motif commun à tous ces incidents : les capacités prévues d'un agent — lire un titre de PR, exécuter un outil, appeler une API — deviennent la surface d'attaque. Les workflows AppSec statiques ne captent pas ça. Les modes d'échec sont probabilistes et comportementaux, pas déterministes.
RAMPART transforme le test de red team en test de régression. Clarity déplace la revue de sécurité vers la gauche, au moment où les décisions sont encore peu coûteuses à modifier. Aucune de ces idées n'est nouvelle en soi — c'est comme ça que l'AppSec mature fonctionne pour du code traditionnel. Ce qui est nouveau, c'est que le workflow interne de red team IA d'un éditeur majeur est désormais un artefact open source que toute équipe qui construit des agents peut adopter dès cet après-midi.
Ce qu'il faut faire
- Cloner RAMPART et écrire un test qui échoue pour votre agent le plus déployé. Commencez par la cross-prompt injection — collez une charge utile d'attaquant dans la source de données que l'agent lit, et vérifiez que l'agent n'agit pas dessus. Un test qui échoue dans la CI vaut mieux qu'un rapport de red team trimestriel.
- Faire tourner Clarity avant votre prochaine revue de design d'agent. La conversation qu'il force — quel accès aux outils cet agent nécessite, à quoi ressemble l'échec, qui valide les actions irréversibles — est précisément celle qui n'a pas lieu assez souvent.
- Traiter les tests de sûreté d'agent comme des tests d'intégration. Conditionnez la merge à leur passage. Bloquez les builds sur régression. Ajoutez un nouveau test pour chaque nouvel outil, source de données ou capacité ajoutée à l'agent.
À retenir
Jusqu'ici, la méthode défensive pour les agents IA, c'était : embaucher une red team, espérer qu'elle attrape les choses avant les attaquants. Microsoft vient de publier un moyen d'intégrer ce travail dans la pull request. L'outillage ne règle pas la prompt injection — rien ne la règle, pour le moment — mais il sort la sûreté des agents d'une revue ponctuelle pour la transformer en artefacts vivants que les ingénieurs maintiennent à chaque commit. Pour les équipes qui livrent des agents en production, c'est l'amélioration de contrôle la moins coûteuse disponible cette semaine.
