Microsoft passe de l’assistant de sécurité au système qui agit
Microsoft a présenté, le 27 juillet 2026, Project Perception, une architecture de cybersécurité conçue autour d’agents d’intelligence artificielle capables d’observer, raisonner et intervenir en continu. La préversion publique est annoncée pour le 3 août 2026. À ce projet s’ajoute MAI-Cyber-1-Flash, le premier modèle spécialisé de Microsoft pour la cybersécurité, intégré à MDASH, son dispositif multi-agents de détection, validation et remédiation de vulnérabilités.
L’annonce ne consiste donc pas simplement à ajouter un chatbot à un centre opérationnel de sécurité. Microsoft décrit un « Cyber Stack » où des agents spécialisés reçoivent des signaux issus des identités, terminaux, applications, données, clouds et systèmes d’IA, les replacent dans un contexte commun, puis sollicitent les modèles les plus adaptés avant de déclencher des actions dans les outils de sécurité.
Les descriptions de Numerama et de Clubic convergent sur la logique générale : une boucle continue allant de la simulation d’attaque à l’enquête, puis à la correction. Microsoft ambitionne ainsi de déplacer l’IA de la production de recommandations vers l’exécution encadrée de tâches défensives.
Trois équipes d’agents dans une même boucle
L’architecture de Project Perception répartit les rôles entre trois catégories d’agents.
- Les agents red team cherchent les chemins de compromission potentiels avant qu’un attaquant ne les exploite.
- Les agents blue team analysent les alertes, recoupent le contexte, hiérarchisent le risque et déterminent si une anomalie justifie une réponse.
- Les agents green team appliquent ou proposent les mesures correctrices : modification de configuration, durcissement d’une protection, correction de règle ou remédiation logicielle.
Le point technique central est le « security context », une représentation continuellement actualisée des actifs, identités, relations, activités et risques d’une organisation. L’objectif est d’éviter que chaque agent reconstruise séparément l’état du système à partir de journaux bruts. Microsoft y voit un moyen de réduire les coûts de calcul, de gagner du temps et d’améliorer la cohérence des décisions entre agents.
Cette couche de contexte est reliée à un mécanisme d’orchestration, ou harness, qui affecte les tâches aux modèles et aux agents. Les « actuators », derniers maillons de la chaîne, transforment alors une décision en action dans les produits de sécurité. C’est cette faculté d’agir qui rend l’approche plus ambitieuse — et plus risquée — qu’un simple outil de triage d’alertes.
Microsoft affirme que les humains restent aux commandes. Cette formule devra toutefois être jugée dans la pratique : entre une recommandation, une action soumise à approbation et une remédiation automatique, le niveau réel d’autonomie peut varier considérablement selon les connecteurs, les droits accordés et les politiques de chaque client.
MAI-Cyber-1-Flash : la stratégie du bon modèle pour la bonne tâche
MAI-Cyber-1-Flash est le premier cas d’usage concret de cette architecture. Le modèle n’est pas proposé comme une interface de programmation généraliste : Microsoft indique qu’il sera réservé à des défenseurs vérifiés, via MDASH. Sa promesse est de prendre en charge jusqu’à 90 % des tâches du système, tandis qu’un modèle plus coûteux, GPT-5.4 dans la configuration évaluée, intervient pour les cas les plus difficiles.
Cette approche hybride est importante. Microsoft ne mise pas sur un unique modèle géant, mais sur du routage : un modèle spécialisé et moins cher traite les opérations répétitives, un modèle de frontière prend le relais lorsqu’un problème exige davantage de raisonnement. La page produit de Microsoft évoque également une orchestration de plus de 100 agents pour rechercher, vérifier et démontrer des vulnérabilités.
Le résultat mis en avant est précis : 95,95 % sur CyberGym, soit environ 96 % après arrondi, pour la combinaison MDASH, MAI-Cyber-1-Flash et GPT-5.4. Microsoft affirme que cette configuration réduit presque de moitié le coût par rapport à sa pile MDASH précédente, fondée sur GPT-5.4, GPT-5.4 mini et GPT-5.3 Codex. The Hacker News souligne à juste titre que le score ne doit pas être attribué au seul MAI-Cyber-1-Flash : il s’agit d’une performance de système, incluant le routage, les agents et le modèle de secours.
Le chiffre est impressionnant, mais il reste une annonce d’entreprise. Microsoft ne publie pas, à ce stade, les éléments nécessaires à une reproduction complète du calcul économique : volume de jetons, répartition exacte des tâches, latence, nombre d’appels, matériel mobilisé ou coût unitaire retenu. Le « coût divisé par deux » doit donc être compris comme une comparaison interne, non comme une mesure indépendante et universelle.
Un benchmark utile, mais insuffisant pour valider la promesse
CyberGym n’est pas un test anodin. Sa prépublication scientifique décrit 1 507 vulnérabilités réelles, corrigées dans 188 grands projets logiciels. Son scénario principal demande à un agent, muni d’une description de vulnérabilité et du code non corrigé correspondant, de produire une preuve de concept qui reproduit effectivement la faille.
C’est un bon indicateur de la capacité d’un système à analyser du code et à valider une vulnérabilité connue. Ce n’est pas, en revanche, une démonstration de découverte autonome de failles inédites dans un environnement d’entreprise complexe. Le benchmark ne mesure pas non plus à lui seul la qualité d’un correctif, l’absence de régression fonctionnelle, la pertinence métier d’une priorisation ou la sûreté d’une action automatique sur une infrastructure de production.
The Hacker News relève par ailleurs que le tableau de classement public de CyberGym ne faisait pas encore apparaître le résultat de 95,95 % au 28 juillet 2026. Cela ne prouve pas que la mesure soit erronée, mais empêche une vérification indépendante immédiate. La prépublication CyberGym elle-même reste une prépublication : elle apporte une méthodologie publique, mais n’équivaut pas à une validation par les pairs.
Le défi décisif : contenir les agents, pas seulement les rendre performants
Le vrai test de Project Perception ne sera pas uniquement la qualité de sa détection. Il concernera le confinement de ses capacités d’action. Une plateforme qui peut consulter un parc informatique, analyser des dépôts de code, changer des règles, lancer des outils ou recommander des correctifs devient elle-même une surface d’attaque privilégiée.
Le NIST rappelle que les agents sont particulièrement exposés au détournement par injection indirecte de consignes : un contenu externe, tel qu’un fichier, un courriel, une page web ou une réponse d’outil, peut contenir des instructions malveillantes poussant l’agent à agir contre l’objectif initial. OWASP ajoute les abus d’outils, l’escalade de privilèges, l’empoisonnement de mémoire, l’exfiltration de données et les défaillances en cascade entre agents parmi les risques propres aux architectures agentiques.
La conséquence est claire : une boucle red-blue-green ne doit pas devenir une boucle de propagation d’erreurs. Les agents chargés de rechercher une faille ne devraient pas posséder les mêmes droits que ceux qui modifient une configuration. Les actions irréversibles doivent exiger une autorisation explicite, liée à des paramètres précis. Les accès doivent respecter le moindre privilège, les sorties réseau être strictement contrôlées, les secrets isolés, et chaque décision produire une trace exploitable par les équipes de sécurité.
Microsoft possède déjà des briques allant dans ce sens. Sa documentation Defender sur la protection d’agents à l’exécution prévoit l’inspection des requêtes d’outils avant exécution et de leurs réponses après exécution afin de détecter les injections de prompt et les actions à risque. Mais une protection additionnelle ne dispense pas de tester l’architecture entière contre des scénarios adverses, y compris les interactions inattendues entre agents, données récupérées et connecteurs tiers.
Une bataille d’architecture plus que de modèle
Project Perception illustre une évolution majeure : la compétition en cybersécurité par IA se jouera moins sur le meilleur modèle isolé que sur la meilleure combinaison entre visibilité, contexte, routage, autorisations, journalisation et mécanismes d’arrêt.
Microsoft dispose d’un avantage structurel : son empreinte dans les postes de travail, l’identité, le cloud, la collaboration et les outils de sécurité lui procure une grande quantité de signaux et de points d’action. Cette intégration peut accélérer la remédiation. Elle renforce aussi l’enjeu de gouvernance pour les entreprises dépendantes de cet écosystème.
La préversion du 3 août 2026 devra donc être observée sur des critères plus concrets que le seul score CyberGym : taux de faux positifs, qualité des corrections proposées, délais de validation humaine, granularité des permissions, traçabilité, capacité à annuler une action et résistance aux tentatives de manipulation. Si Microsoft réussit ces arbitrages, Project Perception pourrait faire évoluer le SOC d’un modèle de réaction aux alertes vers une défense continuellement assistée. Sinon, il rappellera qu’en cybersécurité, automatiser une réponse ne signifie pas encore maîtriser ses conséquences.