Sécurité & gouvernance·Sécurité IA

MCP en entreprise : comment connecter des agents IA sans exposer ses données ?

MCP facilite la connexion des agents IA aux outils et données, mais ne sécurise pas automatiquement ces accès. Voici l'architecture, les contrôles et les preuves à exiger avant un déploiement.

Sophie Guisan9 août 202613 min

Le Model Context Protocol, ou MCP, permet à un client IA de découvrir et d'utiliser des outils ou des ressources selon une interface commune. Cette interopérabilité accélère les intégrations, mais elle ne protège pas automatiquement les données. En entreprise, un déploiement sûr sépare l'agent, la politique d'accès, les serveurs MCP et les systèmes métier. Chaque action doit être liée à une identité, limitée à un périmètre, vérifiée avant exécution et traçable après coup.

Réponse en bref

Ne connectez jamais directement un agent généraliste à un catalogue d'outils doté de droits larges. Placez une frontière de politique entre le client et les systèmes : identité de l'utilisateur et de l'agent, jetons destinés au bon serveur, scopes minimaux, outils séparés par niveau de risque, approbation des écritures sensibles, filtrage réseau et journaux corrélés. Les sorties des outils et les documents restent des entrées non fiables, car ils peuvent contenir des instructions malveillantes.

La règle d'architecture est simple : MCP décrit comment appeler une capacité. L'entreprise décide qui peut l'appeler, avec quelles données, dans quel contexte et avec quelle preuve.

Architecture MCP d'entreprise avec identité, politique, serveurs par domaine de confiance, systèmes métier et journalisation

Architecture de référence Nexxom. Les serveurs MCP sont séparés par domaine de confiance et aucune action sensible ne contourne la politique ni la journalisation.

Qu'est-ce que MCP et que ne sécurise-t-il pas ?

MCP est un protocole ouvert qui standardise la relation entre un client, des serveurs, des outils et des ressources. Un agent peut ainsi découvrir une capacité, comprendre ses paramètres et l'appeler sans intégration propriétaire différente pour chaque système. La spécification publiée le 28 juillet 2026 rend notamment le transport sans session protocolaire, transporte l'identité et les capacités du client dans les métadonnées et ajoute des en-têtes permettant aux passerelles de router ou mesurer les appels.

Ces mécanismes améliorent l'interopérabilité et certains contrôles techniques. Ils ne déterminent pas la classification des données, les rôles métier, la légitimité d'une action ou le niveau d'autonomie acceptable. MCP ne remplace pas non plus un gestionnaire d'identités, un coffre de secrets, une passerelle réseau, une politique de prévention des fuites ni un système de gestion des incidents.

Couche	Ce que MCP apporte	Ce que l'entreprise doit ajouter
Découverte	Description structurée des outils et ressources	Registre approuvé, propriétaire, version et niveau de risque
Appel	Format commun pour transmettre des arguments et recevoir un résultat	Validation de schéma, politique métier, quotas et traitement des erreurs
Autorisation	Cadre OAuth pour les transports HTTP distants	Identités, consentement, scopes, délégation et révocation adaptés au contexte
Transport	Échange standard entre client et serveur	TLS, filtrage réseau, proxy de sortie, segmentation et surveillance
Traçabilité	Métadonnées et événements techniques disponibles	Corrélation utilisateur, agent, outil, décision de politique et résultat métier

La première erreur de conception consiste donc à considérer un serveur MCP comme un simple connecteur. C'est une nouvelle surface d'accès aux systèmes métier, parfois capable de lire, modifier ou déclencher des opérations.

Les cinq frontières de confiance d'une architecture MCP

1. L'utilisateur et l'agent ne sont pas la même identité

L'utilisateur délègue une tâche. L'agent ou le client exécute des appels. Le serveur MCP expose des capacités. Le système métier applique finalement une opération. Les journaux doivent distinguer ces rôles et conserver le lien de délégation.

Le concept paper du NIST NCCoE sur l'identité et l'autorisation des agents met en avant l'identification des agents, la délégation, la journalisation et la provenance des flux. Cette séparation évite qu'un compte technique partagé efface la responsabilité de l'utilisateur ou de l'application qui a initié l'action.

2. La politique précède l'appel d'outil

Une décision du modèle ne constitue pas une autorisation. Avant l'appel, une couche déterministe doit vérifier le rôle, le tenant, la classification des données, le niveau de risque, la destination et l'éventuelle approbation. Un outil d'écriture ne doit pas devenir accessible simplement parce que le modèle a produit son nom et des arguments valides.

La politique peut renvoyer quatre résultats : autoriser, refuser, demander une approbation ou réduire le périmètre. Elle doit être versionnée, testée et indépendante du prompt principal.

3. Chaque serveur MCP forme un domaine de confiance

Regrouper tous les outils dans un serveur unique augmente l'impact d'une compromission et complique les droits. Séparez au minimum les données publiques, les données internes, les informations sensibles et les actions d'écriture. Les outils RH, finance, support ou infrastructure ne devraient pas partager automatiquement les mêmes secrets ni le même processus.

Cette séparation permet d'appliquer des identités, journaux, réseaux et procédures d'incident distincts. Elle simplifie aussi la révocation d'un serveur sans interrompre tout l'écosystème.

4. Le système métier reste l'autorité finale

Le serveur MCP ne doit pas contourner les contrôles du système cible. L'API métier continue de valider l'identité, les droits, le schéma, les limites et la cohérence de l'opération. Si le serveur utilise un compte de service, ses permissions doivent être aussi étroites que possible et ne jamais offrir un accès administratif par défaut.

Pour une action sensible, la meilleure conception expose souvent deux outils : proposer une opération et exécuter une opération approuvée. Le premier produit un objet vérifiable. Le second exige une preuve d'approbation et refuse toute modification de paramètres après cette approbation.

5. Les journaux forment une frontière de détection

La sécurité ne s'arrête pas au refus. Il faut détecter les comportements inattendus : changement soudain d'outil, volume inhabituel, série de refus, élévation de scope, destination nouvelle ou sortie contenant des données sensibles. Les journaux de l'agent, de la politique, du serveur MCP et du système métier doivent partager un identifiant de corrélation.

OpenAI décrit dans Running Codex safely at OpenAI l'intérêt de relier demandes, décisions d'approbation, usages MCP et décisions réseau, puis d'exporter cette télémétrie vers les systèmes de conformité et de sécurité. Cette pratique est transposable à toute plateforme agentique.

Les principaux risques et leurs contrôles

Risque	Scénario	Contrôle préventif	Preuve à conserver
Injection de prompt indirecte	Un document ou résultat d'outil demande à l'agent d'exfiltrer des données ou d'appeler un autre outil	Traiter le contenu comme non fiable, séparer données et instructions, limiter les outils, approuver les actions sensibles	Source du contenu, plan proposé, règle appliquée et décision d'approbation
Droits excessifs	Un agent de lecture possède aussi une capacité de suppression ou d'administration	Scopes minimaux, outils séparés, élévation progressive et durée courte des droits	Scope demandé, accordé, refusé, durée et identité
Token passthrough	Un serveur transmet un jeton reçu à une API qui n'en est pas la cible	Valider émetteur, audience et ressource, interdire le transfert de jetons, utiliser une délégation contrôlée	Claims validés, ressource cible et résultat de validation
Confused deputy	Un client malveillant exploite le serveur MCP ou un consentement existant pour agir au nom d'un utilisateur	Consentement par client, correspondance stricte des redirections, état lié à la transaction	`client_id`, URI de redirection, consentement et corrélation de transaction
SSRF	Une URL de découverte OAuth ou une redirection cible un service interne ou une métadonnée cloud	HTTPS, blocage des plages privées, validation de chaque redirection, DNS sûr et proxy de sortie	URL demandée, résolution, décision réseau et redirections
Serveur local compromis	Un package ou une commande de démarrage exécute du code avec les droits du client	Registre approuvé, commande visible, consentement, sandbox et droits fichiers/réseau limités	Artefact, version, commande exacte, signature et autorisation
Détournement d'état	Une poignée de tâche est devinée ou réutilisée par un autre utilisateur	Poignée aléatoire, courte durée, liaison serveur à l'identité authentifiée	Propriétaire, création, expiration et tentative rejetée
Fuite dans les journaux	Arguments, résultats ou secrets sont enregistrés en clair	Schémas de redaction, hachage des identifiants sensibles, accès restreint et rétention définie	Politique de journalisation, champs masqués et accès aux journaux

Les bonnes pratiques de sécurité MCP pour la version 2026-07-28 documentent notamment le confused deputy, le token passthrough, le SSRF, les serveurs locaux et le détournement des poignées d'état. Elles doivent être lues avec les pratiques OAuth applicables.

Comment sécuriser l'identité et les jetons ?

Utiliser l'autorisation pour les serveurs distants sensibles

La documentation MCP recommande l'autorisation lorsque le serveur accède à des données propres à l'utilisateur, doit attribuer les actions, exige un consentement ou s'insère dans un environnement à contrôle strict. Pour un transport HTTP distant, le serveur MCP agit comme ressource protégée et le client utilise le flux d'autorisation.

Le serveur doit valider que le jeton lui est destiné. Il vérifie notamment l'émetteur, l'audience ou la ressource, l'expiration et les scopes. La spécification interdit d'accepter ou de faire transiter des jetons émis pour d'autres ressources. Le RFC 9700 de l'IETF complète ce cadre avec les meilleures pratiques OAuth, dont PKCE, la correspondance stricte des URI de redirection et la prévention du rejeu.

Commencer avec le minimum et élever à la demande

Un client généraliste ne devrait pas recevoir tout le catalogue de droits lors de sa première connexion. Commencez avec des capacités de découverte ou de lecture à faible risque. Lorsqu'une opération exige un droit supplémentaire, le serveur renvoie un défi précis et le processus demande une nouvelle autorisation.

La documentation MCP 2026-07-28 décrit ce modèle progressif de moindre privilège. L'élévation doit être visible, contextualisée et enregistrée. Une portée admin générique est rarement adaptée à un agent.

Séparer les secrets de la conversation

Les jetons, clés et secrets ne doivent pas être injectés dans le prompt ni renvoyés par les outils. Ils restent dans un coffre ou un composant d'identité et sont utilisés au dernier moment par le serveur autorisé. Les erreurs ne doivent jamais inclure le secret complet.

Comment limiter l'exposition des données ?

Classifier les outils, pas seulement les bases

Pour chaque outil, documentez les catégories de données lues, transformées ou écrites. Un outil search_customers peut sembler inoffensif, mais exposer des données personnelles à travers ses résultats. La classification doit couvrir les paramètres, les réponses, les pièces jointes et les journaux.

Réduire les résultats à ce qui est nécessaire

Un agent n'a pas besoin d'une table complète pour répondre à une question précise. Les outils doivent filtrer côté serveur, limiter le nombre de champs, paginer et masquer les valeurs non nécessaires. L'agent ne doit pas être chargé de supprimer lui-même les colonnes sensibles après réception.

Empêcher les chaînes d'exfiltration

Le risque apparaît souvent entre deux outils : lire un document interne, puis envoyer son contenu vers une messagerie ou une URL. Une politique doit examiner la combinaison source, destination, classification et intention. Les outils d'écriture externe exigent un contrôle plus strict que les outils internes en lecture.

OpenAI avertit que les serveurs MCP non fiables augmentent notamment le risque d'injection de prompt et recommande de les examiner avant publication. Pour les serveurs privés, un tunnel MCP sécurisé évite de rendre directement le service accessible sur Internet, sans supprimer le besoin d'autorisation.

Quel contrat imposer à chaque outil MCP ?

Un outil publiable dans le registre d'entreprise devrait avoir au minimum :

Champ	Question à résoudre
Propriétaire	Quelle équipe répond du code, des données et des incidents ?
Finalité	Quel objectif métier précis autorise cet outil ?
Entrées	Quels paramètres, formats, longueurs et valeurs sont acceptés ?
Sorties	Quelles données et classifications peuvent être renvoyées ?
Effets	L'outil lit-il, propose-t-il, modifie-t-il ou supprime-t-il ?
Autorisation	Quelles identités, ressources, scopes et conditions sont exigés ?
Approbation	Quelle action demande une validation humaine et comment est-elle liée aux paramètres ?
Limites	Quels quotas, délais, budgets et conditions d'arrêt s'appliquent ?
Journalisation	Quels événements sont enregistrés, masqués et corrélés ?
Cycle de vie	Quelle version est approuvée et comment la révocation fonctionne-t-elle ?

La description destinée au modèle ne suffit pas. Ces propriétés doivent être exécutables ou contrôlées par le serveur et la passerelle.

Une checklist avant la mise en production

Gouvernance

Inventorier les clients, serveurs, outils, propriétaires, versions et systèmes cibles.
Classer chaque outil par type de données, effet et impact maximal.
Définir qui approuve un serveur, un changement d'outil et une élévation de droit.
Prévoir la révocation d'un serveur, d'un jeton et d'une version compromise.

Identité et autorisation

Séparer utilisateur, client, agent, serveur MCP et compte du système métier.
Valider émetteur, audience, ressource, expiration et scopes à chaque appel.
Interdire le token passthrough et les comptes administrateurs partagés.
Utiliser des droits courts, minimaux et progressifs.

Données et actions

Filtrer les données côté outil avant de les renvoyer au modèle.
Séparer lecture, proposition et exécution.
Lier l'approbation humaine aux paramètres exacts de l'action.
Bloquer les destinations et combinaisons de données non autorisées.

Réseau et exécution

Autoriser explicitement les domaines, protocoles et redirections.
Bloquer les adresses privées et métadonnées cloud dans les flux de découverte non fiables.
Isoler les serveurs locaux et afficher la commande exacte avant exécution.
Appliquer des quotas, délais, limites d'appels et mécanismes de coupure.

Observation et incident

Corréler utilisateur, agent, client, outil, version, règle, approbation et résultat.
Masquer secrets et données sensibles selon un schéma documenté.
Détecter les élévations, refus répétés, volumes anormaux et destinations nouvelles.
Tester la révocation, la coupure, l'enquête et la restauration avant l'ouverture.

Les erreurs d'architecture les plus fréquentes

Publier un serveur MCP uniquement parce que son code est disponible publiquement.
Donner à un agent tous les scopes pour éviter des demandes d'autorisation.
Utiliser un compte de service unique pour plusieurs tenants et domaines métiers.
Confondre validation des paramètres et autorisation de l'action.
Faire confiance au contenu d'un outil parce qu'il provient d'une base interne.
Transmettre un jeton utilisateur à une API sans vérifier sa cible.
Journaliser les prompts, résultats et jetons complets par défaut.
Connecter lecture et exfiltration externe sans règle sur le flux de données.
Tester les réponses de l'agent sans tester les outils, refus, erreurs et approbations.

Pour replacer ces choix dans un cadre plus large, consultez notre analyse des principaux risques OWASP des applications LLM et notre méthode pour sélectionner un processus agentique.

Questions fréquentes

MCP chiffre-t-il automatiquement les données ?

MCP définit des interactions et des transports, mais la protection dépend de l'implémentation et de l'infrastructure. Les serveurs distants doivent utiliser un transport sécurisé, et les données doivent rester chiffrées selon les politiques de l'organisation pendant le transport et le stockage.

Un serveur MCP interne est-il forcément fiable ?

Non. Il peut contenir une vulnérabilité, des dépendances compromises, une description d'outil trompeuse ou des droits excessifs. L'origine interne réduit certains risques, mais ne remplace pas la revue, l'isolation, les tests et la surveillance.

Peut-on utiliser un seul serveur MCP pour toute l'entreprise ?

C'est rarement une bonne frontière. La séparation par domaine de confiance limite l'impact, simplifie les autorisations et clarifie les propriétaires. Une passerelle commune peut centraliser certaines politiques sans fusionner tous les secrets et outils.

Comment gérer les actions d'écriture ?

Exposez des outils étroits, validez les paramètres côté serveur et demandez une approbation pour les effets sensibles. L'approbation doit porter sur l'action exacte, sa destination et ses données. Toute modification ultérieure invalide cette approbation.

Faut-il enregistrer tout le raisonnement de l'agent ?

Non. Conservez les événements nécessaires à l'audit : demande, identité, outil, arguments utiles et masqués, décision de politique, approbation, résultat et erreur. Évitez de collecter des données sensibles ou un raisonnement interne non nécessaire.

Conclusion

MCP réduit le coût d'intégration, pas le risque par défaut. Une architecture sûre traite chaque serveur comme une nouvelle frontière d'accès, chaque outil comme une capacité métier et chaque sortie comme une donnée potentiellement non fiable. Les droits sont minimaux et progressifs, les écritures sensibles sont approuvées, les destinations réseau sont contrôlées et tous les événements utiles partagent une corrélation.

Le bon objectif n'est pas de connecter le plus grand nombre d'outils. Il est de donner à chaque agent le plus petit ensemble de capacités capable d'accomplir une tâche, avec une preuve exploitable de ce qui a été demandé, autorisé et exécuté. Nexxom peut concevoir ce registre, cette politique et cette architecture autour de vos systèmes réels.

Sources primaires

Sources et spécification vérifiées le 9 août 2026. MCP et ses mécanismes d'autorisation évoluent. Vérifiez la version du client, du serveur et des SDK avant toute décision d'architecture.

IAMCPagents IAsécuritéOAuthgouvernance