Sécuriser les agents Copilot et les serveurs MCP en entreprise : guide pratique

Pourquoi un agent IA change la frontière de sécurité

Un agent Copilot ne se limite pas à générer du texte. Avec l’orchestration générative et un serveur Model Context Protocol, il peut lire des ressources, choisir un outil et déclencher une action. La frontière de confiance englobe alors l’utilisateur, l’agent, le modèle, les sources de connaissances, le client MCP, le serveur MCP, ses API en aval et les identités utilisées à chaque étape.

Dans Copilot Studio, les outils et ressources publiés par un serveur MCP deviennent disponibles à l’agent et les changements du serveur sont reflétés dynamiquement. Cette souplesse est utile, mais elle transforme une modification de description, de schéma ou d’autorisation côté MCP en changement de production. Les instructions de l’agent ne constituent donc pas à elles seules un contrôle de sécurité.

Commencer par une matrice de risques et de décisions

Classez chaque outil avant de le connecter. Une recherche documentaire en lecture seule n’a pas le même impact qu’un outil capable de créer un compte, envoyer un courriel, modifier un pare-feu ou supprimer une sauvegarde. Le contrôle doit être proportionnel à l’impact réel, pas au nom rassurant donné à l’agent.

1 — Donner une identité distincte à chaque agent et à chaque utilisateur

Évitez le compte de service partagé qui rend toutes les actions indiscernables. Pour une action effectuée au nom d’une personne, utilisez une authentification utilisateur et conservez son identité jusqu’au système cible. Pour une tâche autonome, utilisez une identité de charge de travail ou d’agent distincte, avec ses propres permissions et son propre cycle de vie.

Microsoft Entra Agent ID étend les mécanismes d’identité et de gouvernance aux agents. Conditional Access peut évaluer les demandes d’accès d’utilisateurs et d’agents avant l’émission d’un jeton. Ces fonctions, leurs licences et leur disponibilité peuvent évoluer : validez-les dans votre tenant avant de bâtir une dépendance de production.

• Un propriétaire métier et un propriétaire technique par agent.
• Une identité distincte par environnement : développement, test et production.
• Aucun compte Global Administrator ou rôle permanent très privilégié.
• Certificat, identité managée ou secret stocké dans un coffre; jamais dans une instruction ou une variable publique.
• Processus de désactivation lorsque l’agent, son propriétaire ou son usage disparaît.

2 — Préférer OAuth et l’autorisation par utilisateur aux clés partagées

Copilot Studio accepte notamment aucune authentification, une clé API ou OAuth 2.0 pour un serveur MCP. Une clé partagée peut convenir à un laboratoire très limité, mais elle ne représente pas l’utilisateur et complique la révocation, l’attribution et le moindre privilège. Pour les données ou actions d’entreprise, privilégiez OAuth avec des portées précises.

La spécification d’autorisation MCP 2025-11-25 exige OAuth 2.1 pour les serveurs d’autorisation, la découverte des métadonnées de ressource protégée, PKCE pour les clients et le paramètre resource afin de lier le jeton au serveur MCP visé. Le serveur doit valider l’émetteur, l’audience, l’expiration, les portées et, selon l’architecture, l’identité de l’utilisateur ou de l’agent.

{
  "resource": "https://mcp.example.ca/mcp",
  "authorization_servers": [
    "https://login.microsoftonline.com/<tenant-id>/v2.0"
  ],
  "scopes_supported": [
    "mcp.tools.read",
    "mcp.tools.execute-approved"
  ]
}

3 — Interdire le token passthrough et réduire les portées

Le token passthrough consiste à accepter un jeton destiné à une autre ressource puis à le transmettre tel quel à une API en aval. La documentation de sécurité MCP le qualifie d’anti-pattern et la spécification l’interdit. Le serveur MCP doit accepter uniquement un jeton émis pour sa propre audience. S’il appelle une autre API, il doit obtenir un jeton séparé destiné à cette API.

Commencez par une portée de lecture à faible risque. Demandez une élévation ciblée seulement lorsque l’utilisateur tente une opération privilégiée. Évitez les portées génériques comme full-access, admin:* ou un joker qui donnent à un jeton volé un rayon d’action disproportionné.

4 — Concevoir des outils étroits, déterministes et validés côté serveur

Un outil sécuritaire accomplit une tâche précise avec un schéma d’entrée strict. Préférez create_ticket à execute_api_request, ou get_device_status à run_powershell. Plus l’outil est générique, plus le modèle peut assembler une action imprévue ou contourner une intention métier.

Validez tous les arguments côté serveur même si Copilot Studio possède déjà un schéma. Appliquez des listes d’autorisation pour les domaines, commandes, destinataires, types d’objets et plages de valeurs. Refusez les champs inconnus, imposez des limites de taille, normalisez les chemins et effectuez de nouveau l’autorisation sur chaque appel.

• Séparer les outils de lecture et d’écriture.
• Rendre les opérations répétées idempotentes avec une clé de requête.
• Limiter la pagination, la taille des résultats et la durée d’exécution.
• Retourner des erreurs structurées sans pile, secret ou donnée interne.
• Versionner les noms, descriptions, schémas et portées des outils.

5 — Exiger une confirmation humaine avant les actions à impact

Dans Copilot Studio, l’option Ask the end user before running existe pour les outils et elle est désactivée par défaut. Activez-la pour les envois, publications, changements de configuration, transactions et suppressions. La confirmation doit présenter l’action finale, la cible, les données transmises et l’impact attendu; un bouton générique Continuer n’apporte qu’une protection limitée.

Pour les opérations critiques, ajoutez une approbation hors bande ou un second rôle. L’agent peut préparer le changement, mais un humain autorisé doit le valider dans ServiceNow, Power Automate Approvals ou le système métier avant l’exécution.

6 — Appliquer les politiques DLP et séparer les environnements

Dans le centre d’administration Power Platform, les connecteurs peuvent être classés Business, Non-business ou Blocked. Copilot Studio applique ces politiques en temps réel. Les administrateurs peuvent exiger l’authentification, bloquer certaines sources de connaissances, les requêtes HTTP, les connecteurs utilisés comme outils, les canaux de publication et les déclencheurs autonomes.

Microsoft précise que bloquer les connecteurs Power Platform bloque aussi les outils des serveurs MCP connectés, puisque cette connectivité dépend des connecteurs. Utilisez donc des environnements dédiés et des politiques adaptées : développement restrictif, test représentatif et production avec uniquement les connecteurs et points de terminaison approuvés.

• Bloquer Chat without Microsoft Entra ID authentication pour les agents internes.
• Utiliser le filtrage de points de terminaison pour les sites, SharePoint et appels HTTP autorisés.
• Séparer les connecteurs métier des connecteurs personnels ou publics.
• Limiter les déclencheurs autonomes tant que le scénario n’a pas été testé en production contrôlée.
• Appliquer les étiquettes de sensibilité et les politiques Purview aux données compatibles.

7 — Isoler le serveur MCP et contrôler ses sorties réseau

Traitez un serveur MCP comme une API privilégiée. Placez-le derrière une passerelle ou un reverse proxy, imposez TLS, limitez les débits et n’exposez que le chemin nécessaire. Le processus ne devrait pas fonctionner comme root, écrire dans son image ou accéder au socket Docker.

Les clients et serveurs MCP qui récupèrent des URL doivent se protéger contre le SSRF. La recommandation MCP est de bloquer les réseaux privés, loopback, link-local et les métadonnées cloud sauf besoin explicitement autorisé, de valider chaque redirection et d’envisager un proxy de sortie. Une simple validation de chaîne ou de nom DNS n’est pas suffisante.

services:
  mcp:
    image: registry.example.ca/agents/mcp-server:1.4.2
    read_only: true
    user: '10001:10001'
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true
    pids_limit: 128
    mem_limit: 512m
    cpus: 1.0
    tmpfs:
      - /tmp:rw,noexec,nosuid,size=64m
    secrets:
      - mcp_client_secret

secrets:
  mcp_client_secret:
    file: /secure/path/mcp_client_secret

8 — Considérer les serveurs MCP locaux comme du code exécutable

Un serveur local lancé par stdio s’exécute sur le poste de l’utilisateur et peut avoir accès à ses fichiers, variables d’environnement et identifiants. N’installez pas un paquet MCP uniquement parce qu’il apparaît dans un dépôt ou qu’un agent le recommande. Vérifiez l’éditeur, le code, les dépendances, la provenance de l’image et les mises à jour.

Épinglez les versions et les condensats d’images, générez un SBOM, analysez les vulnérabilités et signez vos artefacts. Pour un usage d’entreprise, préférez un service distant administré ou une exécution locale fortement isolée plutôt qu’une commande arbitraire ajoutée dans la configuration de chaque poste.

9 — Journaliser les décisions sans copier les secrets

Chaque appel d’outil doit pouvoir être attribué à un agent, une version, un utilisateur ou une identité autonome et une décision d’autorisation. Conservez un identifiant de corrélation entre Copilot, la passerelle MCP et l’API en aval. Ne journalisez pas les jetons, clés, mots de passe ni le contenu intégral des prompts par défaut.

Microsoft Purview enregistre les activités Copilot Studio et les rend disponibles dans Audit; Microsoft 365 fournit aussi des journaux pour les interactions Copilot et les activités administratives. Ajustez séparément la conservation et l’accès aux transcriptions, car elles peuvent contenir des renseignements personnels ou opérationnels.

{
  "timestamp": "2026-08-23T13:10:00Z",
  "correlation_id": "7f0d...",
  "agent_id": "helpdesk-prod",
  "agent_version": "2026.08.3",
  "principal_id_hash": "sha256:...",
  "tool": "create_service_request",
  "authorization_decision": "allowed",
  "scope": "mcp.tools.draft",
  "result": "success",
  "latency_ms": 284
}

10 — Gouverner le cycle de vie dans les centres d’administration

Le Microsoft 365 admin center permet d’activer, désactiver, attribuer, bloquer ou retirer des agents, et l’Agent Registry fournit une vue centralisée. Utilisez des groupes restreints pour les pilotes, examinez les permissions et les accès aux données, puis élargissez uniquement après validation.

Une publication n’est pas la fin du contrôle. Révisez périodiquement les propriétaires, utilisateurs, outils, portées OAuth, secrets, dépendances, politiques DLP, journaux et coûts. Retirez immédiatement un outil déprécié ou un serveur dont la provenance n’est plus vérifiable.

Plan de déploiement recommandé en quatre phases

Références officielles et lectures connexes

En août 2026, les capacités d’agents, d’Entra Agent ID et de gouvernance continuent d’évoluer rapidement. Vérifiez les prérequis, licences et statuts de préversion dans votre tenant avant une mise en œuvre de production.

• Microsoft Learn — Étendre un agent Copilot Studio avec MCP ↗
• Microsoft Learn — Politiques de données Copilot Studio ↗
• Microsoft Learn — Gérer les agents dans Microsoft 365 ↗
• Microsoft Learn — Configurer les outils et leur confirmation ↗
• Microsoft Learn — Auditer les activités Copilot Studio ↗
• Microsoft Learn — Conditional Access pour les agents ↗
• MCP — Spécification d’autorisation 2025-11-25 ↗
• MCP — Bonnes pratiques de sécurité ↗
• Article connexe — 10 requêtes KQL Defender Advanced Hunting →
• Article connexe — Audit de sécurité Active Directory →