← Retour à la veille

Defender for Endpoint : Intune 2609 ajoute le pilotage de la protection runtime des agents IA

la page des nouveautés Intune 2609 indique que Microsoft Intune ajoute un profil Endpoint security pour configurer la protection runtime des agents IA locaux par Microsoft Defender for Endpoint sur Windows. Le sujet concerne surtout les postes de développeurs, administrateurs et utilisateurs avancés qui exécutent des agents capables de lire des fichiers, d'appeler des outils ou de lancer des commandes.

Impact
appareils Windows onboardés dans Microsoft Defender for Endpoint, avec Defender Antivirus actif, sur lesquels des agents IA locaux supportés sont utilisés. Le réglage peut être déployé via Intune ou via la gestion des paramètres de sécurité Defender, mais la fonctionnalité Defender reste en Preview.
Action
lancer un test en mode Audit sur un groupe restreint de postes où ces agents sont réellement utilisés, vérifier les paramètres effectifs et les alertes Defender, puis décider séparément si un passage en mode Block est acceptable.
Statut
À tester

Ce qui change

Microsoft a mis à jour la page What's new in Microsoft Intune le 25 septembre 2026. Dans le bloc Week of September 28, 2026 (Service release 2609), Intune annonce un nouveau template Endpoint security Windows pour configurer Microsoft Defender for Endpoint AI agent runtime protection. Les modes documentés sont Audit, pour détecter et alerter sans bloquer, et Block, pour empêcher certaines actions avant leur exécution.

La fonctionnalité Defender n'est pas une protection générique de tous les assistants IA. La documentation Microsoft Defender for Endpoint la présente comme une protection runtime des agents IA locaux supportés : assistants de code, outils CLI, applications desktop ou plateformes autonomes. Defender inspecte des points précis de la boucle agentique, notamment les prompts utilisateur, les demandes d'outils avant exécution et les réponses d'outils après exécution, afin de détecter des injections de prompt ou des actions à risque.

Le périmètre reste celui d'une Preview. Les prérequis publiés incluent une licence Microsoft Defender for Endpoint Plan 2, Microsoft 365 E5, Microsoft Agent 365 ou Microsoft 365 E7, des appareils onboardés dans Defender for Endpoint, Microsoft Defender Antivirus en mode actif avec la protection temps réel, une version Windows supportée, et au moins un agent local pris en charge. La page de configuration consultée indique aussi que les appareils de test en preview doivent recevoir les mises à jour plateforme et moteur Defender depuis le Beta Channel ; ce point doit être traité comme une contrainte de pilote, pas comme un détail cosmétique.

Qui est concerné

Le premier périmètre utile est celui des postes de développeurs, d'ingénieurs poste de travail, d'administrateurs et d'équipes sécurité qui utilisent des agents locaux capables d'agir sur l'environnement : lecture de dépôt, appels à des outils, commandes shell, analyse de sortie d'outils, ou accès à des MCP servers. Microsoft cite notamment la prise en charge d'agents via interfaces d'événements fournisseur, et documente aussi une inspection réseau pour les agents qui n'exposent pas ces interfaces.

Le second périmètre est opérationnel : les équipes Intune et Defender doivent distinguer deux méthodes de protection. Le template Intune Microsoft Defender AI agent runtime protection configure l'inspection par événements agent-native avec le paramètre Ai Agent Protection. La documentation précise que l'inspection réseau n'est pas couverte par ce profil Intune et doit être déployée autrement, par exemple via un script PowerShell Intune en contexte système. Il ne faut donc pas conclure qu'un seul profil Intune couvre automatiquement tous les agents locaux.

Actions recommandées

Commencer par l'inventaire. Dans Defender, utiliser les capacités de découverte des agents IA locaux pour identifier les postes et comptes où ces outils existent réellement, puis croiser avec les populations à risque : développeurs, packaging, sécurité, automatisation, administrateurs d'infrastructure et postes qui manipulent du code ou des secrets opérationnels.

Créer ensuite un pilote Audit sur un groupe limité, avec des utilisateurs qui exécutent réellement les agents supportés. Le test doit vérifier trois choses : le paramètre effectif sur l'appareil, l'apparition des alertes Suspicious AI prompt injection dans Defender, et l'absence de bruit excessif sur des flux de travail normaux. Microsoft recommande de revoir les alertes pendant une à deux semaines avant d'étendre ou de passer en blocage.

Pour valider le déploiement, la documentation Microsoft indique de contrôler, côté portail Defender, la page appareil puis Configuration management > Effective settings, et de vérifier la valeur effective de Ai Agent Protection et sa source de configuration. En cas d'écart, la suite logique est de corriger le ciblage Intune ou la gestion des paramètres de sécurité Defender avant d'élargir le périmètre.

Ne pas activer Block par défaut sur tout le parc. Le critère de passage en blocage doit être explicite : alertes compréhensibles par le SOC, utilisateurs pilotes capables de continuer leur travail, procédures de traitement des faux positifs connues, et périmètre limité aux agents effectivement supportés. Pour l'inspection réseau, prévoir un test séparé : Microsoft documente des limites, notamment les agents utilisant le certificate pinning ou HTTP/3.

Points de vigilance

Cette nouveauté ne remplace pas les contrôles de base autour des agents IA : droits locaux, accès aux dépôts, secrets, MCP servers, proxy, journalisation et règles de sortie réseau. Elle ajoute une couche Defender centrée sur certaines interactions agentiques.

Le changement n'est pas une urgence pour tous les postes Windows. Il devient pertinent là où des agents locaux ont déjà accès à des données ou outils sensibles. Pour un parc bureautique classique sans agents supportés, la bonne première action est l'inventaire, pas le blocage.

Sources