Protection des conversations IA chez Microsoft avec le protocole de contexte de modèle : sécurité et gouvernance
Lorsque nous avons donné à nos agents Microsoft 365 Copilot une méthode simple pour se connecter aux outils et aux données grâce au Modèle de Contexte de Protocole (MCP), le travail a parlé de lui-même.
Les réponses sont devenues plus précises. La livraison s’est accélérée. De nouveaux modèles de développement ont émergé au sein des équipes travaillant avec les agents Copilot.
Cependant, cette facilité de communication s’accompagne d’une responsabilité : protéger la conversation.
Les questions de sécurité
Des questions se sont posées, telles que : qui est autorisé à parler ? Que peuvent-ils dire ? Et que ne devrait-on jamais laisser sortir ?
Microsoft Digital, l’organisation informatique de l’entreprise, et l’équipe du Chief Information Security Officer (CISO), notre organisation de sécurité interne, s’appuient sur ces questions pour façonner notre stratégie et nos outils autour du MCP en interne chez Microsoft.
« Avec le MCP, le problème n’est pas la conception inhérente ; c’est que chaque mise en œuvre de serveur incorrecte devient une vulnérabilité potentielle. Même un serveur mal configuré peut donner à l’IA les clés de vos données », déclare Swetha Kumar, ingénieur en assurance sécurité chez Microsoft CISO.
Une approche simple et sécurisée
Notre approche est intentionnellement simple :
- Commencer par la sécurité par défaut.
- Utiliser des serveurs de confiance.
- Maintenir un catalogue vivant pour toujours savoir quelles voix sont présentes.
- Façonner la communication des agents en exigeant un consentement avant d’apporter des modifications.
Nous minimisons ce qui est partagé en dehors de nos murs, surveillons les déviations et agissons lorsque quelque chose semble suspect. Notre objectif est une gouvernance pratique qui permet aux développeurs d’avancer rapidement tout en protégeant nos données.
Comprendre le MCP et la nécessité de la sécurité
Le MCP est une norme simple qui permet aux systèmes d’IA de « communiquer » avec les bons outils et données sans travail d’intégration personnalisé. Pensez-y comme à un USB-C pour l’IA. Au lieu de construire une nouvelle connexion à chaque fois, les équipes se branchent sur un modèle commun.
Cette standardisation apporte rapidité et flexibilité, mais elle modifie également l’équation de sécurité.
Avant le MCP, chaque intégration était une conversation isolée. « Maintenant, un modèle peut déverrouiller de nombreux systèmes », déclare Kumar. « C’est un avantage et un risque. Lorsque l’IA peut accéder à plus de systèmes avec moins d’efforts, nous devons être précis sur qui est autorisé à parler, ce qu’ils peuvent dire et combien est partagé. »
Évaluation de la sécurité du MCP à travers quatre couches
Chaque session MCP crée un graphique de conversation. Un agent découvre un serveur, ingère ses descriptions d’outils, ajoute des identifiants et du contexte, puis commence à envoyer des requêtes. Chaque étape – métadonnées, identité, contenu et code – introduit un risque potentiel.
Nous évaluons ces risques à travers quatre couches afin de détecter rapidement les échecs, contenir la portée des dommages et garder les conversations dans des limites sécurisées.
Couches d’applications et d’agents
C’est ici que l’intention de l’utilisateur rencontre l’exécution. Les agents analysent les invites, découvrent des outils, sélectionnent des actions et demandent des modifications.
Ce qui peut mal tourner :
- Empoisonnement d’outil ou shadowing.
- Échanges silencieux.
- Pas de bac à sable.
Couche de la plateforme IA
Cette couche englobe les modèles IA et les environnements d’exécution qui interprètent les invites et appellent les outils.
Ce qui peut mal tourner :
- Dérive de la chaîne d’approvisionnement du modèle.
- Injection de prompt via le texte de l’outil.
Couche de données
Cette couche couvre les données commerciales, les fichiers et les secrets que la conversation peut toucher.
Ce qui peut mal tourner :
- Partage excessif de contexte.
- Identifiants sur-étendus.
Couche d’infrastructure
Cette couche inclut l’environnement de calcul, le réseau et les environnements d’exécution.
Ce qui peut mal tourner :
- Serveurs locaux avec trop de portée.
- Endpoints cloud sans passerelle.
- Egress ouvert.
Établissement d’une stratégie sécurisée par défaut
Nous commençons par fermer la porte d’entrée. Nous recommandons que chaque serveur MCP distant soit derrière notre passerelle API, nous donnant un seul endroit pour authentifier, autoriser, valider, limiter le taux et journaliser.
Tout ce que nous faisons commence par rendre le serveur MCP sécurisé par défaut et cela commence par l’enregistrement dans le centre API pour une découverte plus facile. Nous ne faisons confiance qu’aux serveurs MCP vérifiés et attestés.
Gouverner les agents dans des scénarios à faible et à haut code
Les créateurs avancent rapidement – c’est le but. Une équipe de support client avait besoin d’une action Copilot pour extraire l’historique des cas, alors ils ont ouvert Copilot Studio, sélectionné un connecteur MCP approuvé et expédié une première version avant le déjeuner.
La gouvernance se manifeste dans le flux, et non comme un obstacle.
Conclusion
Ce programme a transformé notre façon de construire. Les révisions avancent plus rapidement car chaque serveur suit le même chemin. Les dérives sont détectées tôt et la réutilisation augmente car les équipes peuvent découvrir des serveurs de confiance au lieu de créer de nouveaux.
À l’avenir, nous nous concentrons sur une plus grande consolidation et automatisation. Nous visons à un état idéal où un processus d’enregistrement est créé lors de la détection d’un serveur inconnu sur un endpoint.
Les conversations IA font désormais partie de notre méthode de construction quotidienne. Le MCP standardise la manière dont les agents communiquent avec les outils et les données, garantissant que seules les voix nécessaires restent dans la pièce.
