Pourquoi la sécurité doit changer d’échelle
Les systèmes autonomes peuvent désormais analyser, s’adapter et agir en continu. Cette évolution accélère aussi les opérations offensives. Les attaquants peuvent industrialiser la recherche de vulnérabilités, multiplier les campagnes et réduire le délai entre découverte et exploitation.
Les architectures de sécurité conçues autour d’actions humaines séquentielles atteignent leurs limites face à des attaques pilotées par des machines. Microsoft propose une nouvelle approche avec Project Perception, un système agentique destiné à transformer les signaux de sécurité en protections opérationnelles.

Disponibilité
Project Perception : une défense en boucle fermée
Project Perception rassemble des signaux, du contexte de sécurité, plusieurs modèles d’intelligence artificielle et des agents spécialisés. Son objectif n’est pas de produire davantage d’alertes. Il consiste à comprendre en permanence le risque, à le hiérarchiser et à déclencher une réponse adaptée.
L’architecture repose sur trois familles d’agents :
- Les agents Red Team recherchent des chemins de compromission potentiels avant qu’ils ne soient exploités.
- Les agents Blue Team analysent les événements, croisent le contexte disponible et évaluent le risque réel.
- Les agents Green Team appliquent des mesures correctives et renforcent les contrôles de sécurité.
Ces rôles forment une boucle continue : découverte, investigation, décision puis remédiation. Le modèle est particulièrement adapté aux environnements où les identités, les postes, les applications, les données, les clouds et les systèmes d’intelligence artificielle évoluent simultanément.

Point de contrôle
Les six couches du nouveau Cyber Stack
Project Perception ne se limite pas à ajouter des agents aux outils existants. Microsoft décrit un Cyber Stack composé de six couches complémentaires. La valeur opérationnelle provient de leur coordination, et non d’une couche isolée.
| Couche | Rôle opérationnel | Question à vérifier |
|---|---|---|
| Signals and sensors | Collecte de la visibilité sur les identités, terminaux, données, clouds, applications et systèmes IA | Les sources critiques sont-elles couvertes ? |
| Context | Enrichissement des signaux avec les actifs, relations, activités et risques | Les agents disposent-ils d’un contexte exploitable ? |
| Models | Raisonnement sur les menaces avec plusieurs modèles spécialisés ou généralistes | Le modèle choisi correspond-il à la tâche ? |
| Harness | Orchestration des modèles et des agents dans les workflows de sécurité | Les décisions sont-elles traçables ? |
| Agents | Investigation, simulation et correction par équipes Red, Blue et Green | Les responsabilités sont-elles clairement séparées ? |
| Actuators | Traduction des décisions en actions de protection | Les actions sont-elles réversibles et contrôlées ? |
Cette décomposition fournit une grille utile pour évaluer un projet de sécurité agentique. Une organisation qui dispose de modèles performants mais d’une faible visibilité ne pourra pas obtenir un résultat fiable. À l’inverse, une télémétrie abondante sans contexte cohérent augmente le volume d’analyse demandé aux équipes.
Le contexte de sécurité réduit le bruit analytique
Les signaux bruts ne suffisent pas à un agent. Celui-ci doit connaître les actifs concernés, les identités impliquées, les relations entre ressources, les chemins d’attaque et l’historique des événements.
Project Perception s’appuie sur un contexte de sécurité actualisé à partir de la visibilité Microsoft, des renseignements sur les menaces et de l’expertise opérationnelle. Ce contexte représente notamment :
- les actifs et leurs dépendances ;
- les identités et leurs relations ;
- les alertes, expositions et activités ;
- les graphes d’attaque et de déplacement latéral ;
- les arbres de processus et les scénarios d’anomalie ;
- les opérations de Red Team et les menaces liées au courrier électronique.

Ce mécanisme évite aux agents de reconstruire le contexte à partir de chaque événement. Il réduit la quantité d’informations à traiter et accélère la priorisation. Pour un déploiement opérationnel, la qualité de ce contexte doit être vérifiée sur les actifs les plus sensibles : comptes privilégiés, ressources exposées sur Internet, chaînes d’administration et données critiques.
Une architecture multi-modèle pour maîtriser le coût
Aucun modèle n’est optimal pour toutes les tâches de cybersécurité. La sélection doit prendre en compte la qualité de la réponse, la fiabilité, la latence et le coût d’exécution.
Project Perception adopte donc une architecture multi-modèle. Des modèles de pointe et des modèles spécialisés peuvent être associés selon le workflow. Cette approche évite de mobiliser systématiquement le modèle le plus coûteux pour une opération qui ne le justifie pas.
Le premier scénario annoncé concerne la gestion des vulnérabilités logicielles. MAI-Cyber-1-Flash est intégré à MDASH, présenté comme une équipe multi-modèle d’agents dédiée à ce domaine. Cette configuration atteint 96 % sur CyberGym, soit 12 points de plus que Mythos, avec une réduction annoncée de près de 50 % des coûts par rapport à la configuration MDASH alors disponible sur le marché.
Ces résultats doivent être interprétés dans leur contexte. CyberGym est un benchmark et ne remplace pas une évaluation sur le code, les processus de changement et les contraintes de production propres à chaque organisation. Avant adoption, il faut mesurer la précision des détections, les faux positifs, le temps de traitement et la capacité à justifier chaque recommandation.
Méthode d’évaluation
Des informations aux actions avec les actuators
Une plateforme de sécurité qui détecte sans corriger laisse le risque en place. Les actuators constituent donc une couche déterminante du Cyber Stack. Ils relient la décision d’un agent aux mécanismes de protection disponibles dans les produits Microsoft Security.
Les actions peuvent viser la réduction de l’exposition, le renforcement d’une configuration ou la réponse à une menace. Leur portée dépend toutefois des intégrations disponibles, des autorisations accordées et des contrôles appliqués par l’organisation.
Les équipes doivent documenter au minimum :
- les actions exécutables automatiquement ;
- les actions soumises à approbation ;
- les comptes ou identités utilisés pour agir ;
- les journaux conservés pour l’audit ;
- la procédure de retour arrière lorsqu’une action produit un effet indésirable.
La preview constitue précisément un cadre adapté pour tester ces garde-fous. Les scénarios irréversibles ou à fort impact doivent rester derrière une validation humaine tant que le comportement n’est pas suffisamment caractérisé.
Sécurité, conformité et responsabilité
Project Perception est présenté comme aligné sur les principes d’IA responsable de Microsoft. Le système hérite également des contrôles de sécurité, de conformité, de gouvernance et d’exploitation utilisés dans l’écosystème Microsoft.
Cette promesse ne dispense pas d’une analyse interne. Les responsables sécurité doivent vérifier les flux de données, les rôles nécessaires, la conservation des journaux et les limites d’accès aux informations de contexte. Les exigences varient selon le secteur, la sensibilité des données et les règles de séparation des responsabilités.
La supervision humaine reste également nécessaire pour les décisions à fort impact. Un agent peut accélérer une investigation ou proposer une remédiation. Il ne doit pas devenir une autorité implicite lorsqu’une décision affecte un compte privilégié, une application métier ou une ressource de production.
Ce que les équipes doivent préparer
La disponibilité en public preview le 3 août 2026 permet d’envisager une première évaluation. Un pilote utile doit rester mesurable et limité.
Définir le périmètre
Sélectionnez un scénario précis, comme la gestion des vulnérabilités logicielles. Excluez les actions de production tant que les critères de validation ne sont pas établis.
Vérifier la visibilité
Inventoriez les sources disponibles pour les identités, terminaux, applications, données, clouds et systèmes IA. Identifiez les angles morts qui pourraient fausser le raisonnement des agents.
Établir les garde-fous
Définissez les autorisations, les approbations, la journalisation et les procédures de retour arrière. Conservez une séparation claire entre simulation, investigation et remédiation.
Mesurer le résultat
Comparez la précision, la latence, le coût, le taux de faux positifs et le temps de résolution avec le processus existant. Utilisez un jeu de cas représentatif de l’environnement réel.
À retenir
L’approche de Project Perception repose sur trois capacités : percevoir l’environnement, raisonner avec un contexte riche et agir à la vitesse des menaces automatisées. Son Cyber Stack combine signaux, contexte, modèles, orchestration, agents et actuators.
La réussite dépendra moins du nombre d’agents que de la qualité de la visibilité, de la pertinence des modèles et du contrôle des actions. Les équipes peuvent suivre les informations disponibles sur le site Microsoft Security, le Security blog et la page dédiée à Project Perception.



