Les équipes de sécurité ne manquent généralement pas d'alertes. Elles manquent de temps pour comprendre lesquelles décrivent un risque exploitable, quelles dépendances sont concernées et quelle correction réduira réellement l'exposition. Microsoft veut déplacer l'IA vers cette étape de décision avec Project Perception, disponible en preview publique à partir du 3 août.

Le système combine des signaux de sécurité, du contexte, plusieurs modèles et des agents spécialisés. Son premier scénario concerne la gestion des vulnérabilités logicielles. L'objectif affiché n'est pas de produire un résumé supplémentaire, mais de relier la découverte d'une faiblesse à sa priorité et à une action de remédiation, tout en maintenant un contrôle humain.

Trois familles d'agents, une boucle continue

Microsoft décrit trois rôles coordonnés. Les agents de red team cherchent des chemins de compromission avant qu'un attaquant ne les exploite. Les agents de blue team enquêtent sur les signaux et évaluent le risque dans son contexte. Les agents de green team proposent ou appliquent des mesures correctives afin de renforcer l'environnement.

La distinction est importante. Un scanner traditionnel peut signaler une version vulnérable dans des milliers de machines. Une analyse contextuelle doit déterminer si le composant est accessible, si une identité permet de l'atteindre, si une donnée sensible se trouve derrière lui et si plusieurs faiblesses peuvent être enchaînées.

Project Perception cherche à entretenir cette représentation dans le temps. Les actifs, identités, applications, données, clouds et systèmes IA forment un graphe qui évolue. Lorsqu'une dépendance change ou qu'un nouvel indicateur apparaît, la priorité peut être recalculée sans attendre une enquête entièrement manuelle.

MAI-Cyber-1-Flash cible les vulnérabilités logicielles

Le premier modèle spécialisé mis en avant est MAI-Cyber-1-Flash. Il rejoint MDASH, l'équipe multi-modèle d'agents de Microsoft consacrée aux vulnérabilités logicielles. Selon les résultats publiés par l'entreprise, cette configuration atteint 96 % sur le benchmark CyberGym, soit douze points de plus que Mythos, pour un coût annoncé presque inférieur de moitié à la configuration MDASH alors commercialisée.

Ces chiffres doivent être lus comme des résultats fournisseur, pas comme une garantie de performance dans chaque dépôt. Un benchmark mesure un périmètre défini, avec des vulnérabilités et des conditions qui ne reproduisent pas toutes les contraintes d'une base de code réelle : dépendances internes, conventions historiques, code généré, services externes ou documentation incomplète.

Ils illustrent néanmoins un choix d'architecture pertinent. Microsoft ne présente pas un modèle généraliste comme optimal pour chaque tâche. Project Perception sélectionne plusieurs modèles selon la qualité, la fiabilité, la latence et le coût. Un modèle spécialisé et rapide peut traiter un grand volume de code, tandis qu'un modèle plus coûteux intervient sur les cas difficiles.

Le contexte vaut autant que le modèle

Une IA de sécurité peut être techniquement capable et produire une mauvaise priorité si elle ignore l'environnement. Une faille critique dans un composant isolé n'a pas le même niveau d'urgence qu'une faiblesse moyenne exposée sur Internet avec des identifiants trop permissifs.

Microsoft insiste donc sur une couche de contexte partagée. Elle relie les actifs, les identités, les relations, les risques et les activités afin que les agents ne reconstruisent pas la situation depuis des journaux bruts à chaque requête. Cette approche vise aussi à réduire le nombre de jetons et le coût du raisonnement continu.

L'avantage concurrentiel se trouve probablement ici autant que dans MAI-Cyber-1-Flash. Microsoft dispose déjà de signaux provenant des postes, des identités, du cloud, des applications et de ses produits de sécurité. La qualité de l'analyse dépendra de la couverture réelle du client, de la fraîcheur des données et de la capacité à intégrer des environnements qui ne reposent pas uniquement sur l'écosystème Microsoft.

Passer d'une recommandation à une action

Project Perception introduit la notion d'« actuators », des connecteurs qui traduisent une décision en protection. Dans la gestion des vulnérabilités, cela peut conduire à proposer une correction, créer une tâche, modifier une politique ou déclencher un workflow de validation.

C'est aussi la partie la plus sensible. Une alerte erronée coûte du temps ; une remédiation automatique erronée peut interrompre un service. Les organisations devront séparer les actions réversibles des changements à fort impact et définir des niveaux d'autonomie explicites.

Une mise en œuvre prudente peut suivre cette progression :

  1. observation et classement sans modification ;
  2. recommandation accompagnée des preuves et du chemin d'attaque ;
  3. création automatique d'une proposition de correction et de tests ;
  4. application après validation humaine ;
  5. automatisation limitée aux cas répétables, réversibles et suffisamment évalués.

Le contrôle humain promis par Microsoft ne doit pas se limiter à un bouton de confirmation. L'analyste doit pouvoir examiner les sources, comprendre les hypothèses et estimer le périmètre du changement.

Les questions à poser pendant la preview

Une preview sert à mesurer le produit dans son propre environnement. Les équipes devraient suivre au moins cinq indicateurs : précision des priorités, faux positifs, vulnérabilités réellement manquées, délai entre détection et correction, et taux de recommandations acceptées sans reprise importante.

Le coût mérite également une mesure complète. Une économie sur l'inférence peut être annulée par l'intégration, le stockage du contexte, la revue humaine ou des analyses trop fréquentes. Inversement, une solution coûteuse à l'appel peut devenir rentable si elle réduit fortement le temps passé sur des alertes sans issue.

La gouvernance reste centrale. Quels dépôts et journaux sont envoyés aux modèles ? Combien de temps les données sont-elles conservées ? Un correctif proposé peut-il introduire une dépendance non approuvée ? Les décisions sont-elles auditables après un incident ? Une équipe ne devrait pas étendre l'autonomie tant que ces réponses ne sont pas testées.

Une évolution plus importante que le chatbot de sécurité

Project Perception représente une évolution du rôle assigné à l'IA. Le premier âge des assistants de sécurité résumait une alerte ou répondait à une question. Le suivant cherche à maintenir un modèle du système, coordonner plusieurs spécialistes et fermer la boucle jusqu'à la remédiation.

Cette promesse correspond au besoin des centres opérationnels, mais augmente aussi le niveau de confiance requis. Un agent connecté aux identités, au code et aux politiques de protection devient une composante privilégiée de l'infrastructure. Il doit être surveillé comme tel, avec des droits minimaux, des journaux complets et un mécanisme d'arrêt.

La preview dira si Microsoft parvient à réduire la file d'attente plutôt qu'à ajouter une nouvelle couche d'alertes. Le critère décisif ne sera pas le nombre de vulnérabilités détectées. Ce sera la capacité à expliquer lesquelles comptent, à proposer une correction vérifiable et à démontrer que le risque a réellement diminué.