Copilot Studio : 10 erreurs de configuration à éviter

Introduction : pourquoi c’est important

Les agents deviennent rapidement un nouveau plan de contrôle pour l’accès aux données et l’automatisation des workflows — souvent créés et déployés rapidement via des outils low-code comme Copilot Studio. Microsoft avertit que de petits choix de configuration (partage trop large, actions non sécurisées, auth faible, propriété obsolète) peuvent créer des chemins d’identité et d’accès aux données que les contrôles de sécurité traditionnels ne surveillent pas forcément. Résultat : des agents mal configurés peuvent étendre discrètement votre surface d’attaque et permettre des abus pilotés par prompt ou l’exfiltration de données.

Quoi de neuf : 10 erreurs de configuration d’agents courantes (et comment les détecter)

Microsoft décrit dix erreurs de configuration observées « sur le terrain » et associe chacune à des Defender Advanced Hunting Community Queries (Portail Security → Advanced hunting → Queries → Community Queries → dossier AI Agent) ainsi qu’à des mesures d’atténuation recommandées dans Copilot Studio/Power Platform.

Thèmes clés :

1) Surpartage et limites d’accès faibles

• Risque : Agents partagés à l’ensemble de l’organisation ou à des groupes trop larges.
• Détecter : Des requêtes comme AI Agents – Organization or Multitenant Shared.
• Atténuer : Utiliser Managed Environments et les agent sharing limits ; valider la stratégie d’environnements et le périmètre de partage.

2) Authentification manquante ou incohérente

• Risque : Des agents qui n’exigent pas d’authentification deviennent un point d’entrée public.
• Détecter : AI Agents – No Authentication Required.
• Atténuer : Imposer agent authentication at the environment level (l’auth est activée par défaut — ne l’assouplissez pas pour des tests sans garde-fous).

3) Actions, connecteurs et chemins d’exfiltration risqués

• Risque : Actions HTTP Request avec des paramètres non sécurisés (non-HTTPS, ports non standards), ou actions email facilitant l’exfiltration de données.
• Détecter : Des requêtes couvrant les schémas de requêtes HTTP et les scénarios d’email vers l’externe / entrées contrôlées par l’IA.
• Atténuer : Appliquer Data Policies / Advanced Connector Policies, et envisager Microsoft Defender Real-time Protection ainsi que des contrôles sur les actions des connecteurs.

4) Dérive de gouvernance : agents dormants, orphelins et sur-privilégiés

• Risque : Agents/connexions dormants, authentification de l’auteur (maker), agents orphelins avec propriétaires désactivés, identifiants codés en dur.
• Détecter : Des requêtes pour les agents dormants/non modifiés, l’author auth, les identifiants codés en dur, les propriétaires orphelins.
• Atténuer : Réviser régulièrement l’inventaire, restreindre les identifiants des makers, stocker les secrets dans Azure Key Vault via des variables d’environnement, et mettre en quarantaine/décommissionner les agents obsolètes.

5) Nouveaux outils et risques d’orchestration

• Risque : Outils MCP et orchestration générative sans instructions claires (dérive de comportement / abus par prompt).
• Détecter : MCP configuré, et orchestration sans instructions.
• Atténuer : Limiter les outils MCP via des politiques ; s’appuyer sur les garde-fous intégrés (p. ex., Azure Prompt Shield/contrôles RAI) et publier avec des instructions claires.

Impact pour les administrateurs IT et les équipes sécurité

• Attendez-vous à ce que les agents introduisent des chemins d’accès non traditionnels (connecteurs, outils MCP, actions email) susceptibles de contourner la supervision héritée.
• La vélocité du low-code augmente la probabilité d’erreurs de configuration à grande échelle, surtout à travers plusieurs environnements Power Platform.
• Les problèmes de gouvernance (propriété, dormance, identifiants makers) peuvent créer un risque persistant et difficile à détecter.

Prochaines étapes recommandées

1. Exécuter les AI Agent Community Queries dans Defender Advanced Hunting et établir une baseline des résultats par environnement.
2. Imposer l’authentification au niveau de l’environnement et examiner toute exception.
3. Mettre en place/valider Managed Environments, sharing limits, et les Data/Connector policies.
4. Rechercher l’author authentication, les secrets codés en dur et les agents orphelins/dormants ; corriger et décommissionner si nécessaire.
5. Documenter des recommandations de build sécurisé pour les makers (bonnes pratiques HTTP, gestion des secrets, qualité des instructions) et les intégrer à l’onboarding interne.